View Issue Details

IDProjectCategoryView StatusLast Update
0005153SOGoBackend Mailpublic2020-09-08 18:14
Reporterfrancesco.carzaniga Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
PlatformSolaris ZoneOSDebianOS Version10
Product Version4.3.2 
Summary0005153: SAML2 login mapping
Description

I am trying to setup SOGo with SAML2 authentication (via Keycloak), but I'm experiencing some weird behaviour.

SOGo configuration is as follows:
SOGoAuthenticationType = saml2;
SOGoSAML2PrivateKeyLocation = /certs/saml_sogo.key;
SOGoSAML2CertificateLocation = /certs/saml_sogo.pem;
SOGoSAML2IdpMetadataLocation = /etc/sogo/keycloak.xml;
SOGoSAML2IdpPublicKeyLocation = /certs/saml_sso.pub;
SOGoSAML2IdpCertificateLocation = /certs/saml_sso.pem;
SOGoSAML2LogoutEnabled = YES;
SOGoSAML2LogoutURL = https://mail.domain.com;
and Keycloak is configured using the metadata provided by SOGo.

When I try to login to SOGo it correctly redirects to the SSO page with a request, to which Keycloak responds nicely, for example:
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://mail.domain.com/SOGo/saml2-signon-post&quot; ID="ID_86685f47-8cfe-458b-a046-286dc178d859" InResponseTo="_4F3828DFD1CB6FFB2A20091B9199DB1E" IssueInstant="2020-09-08T18:52:08.151Z" Version="2.0">
<saml:Issuer>https://sso.domaincom/auth/realms/realm&lt;/saml:Issuer>
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#&quot;>
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#&quot;/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256&quot;/>
<dsig:Reference URI="#ID_86685f47-8cfe-458b-a046-286dc178d859">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature&quot;/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#&quot;/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256&quot;/>
<dsig:DigestValue>....</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>....</dsig:SignatureValue>
<dsig:KeyInfo>
<dsig:KeyName>....</dsig:KeyName>
<dsig:X509Data>
<dsig:X509Certificate>....</dsig:X509Certificate>
</dsig:X509Data>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>....</dsig:Modulus>
<dsig:Exponent>....</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</dsig:KeyInfo>
</dsig:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="ID_ddb6a884-3930-4c71-98d7-f5609cd29a30" IssueInstant="2020-09-08T18:52:08.151Z" Version="2.0">
<saml:Issuer>https://sso.domain.com/auth/realms/realm&lt;/saml:Issuer>
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#&quot;>
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#&quot;/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256&quot;/>
<dsig:Reference URI="#ID_ddb6a884-3930-4c71-98d7-f5609cd29a30">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature&quot;/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#&quot;/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256&quot;/>
<dsig:DigestValue>....</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>....</dsig:SignatureValue>
<dsig:KeyInfo>
<dsig:KeyName>....</dsig:KeyName>
<dsig:X509Data>
<dsig:X509Certificate>....</dsig:X509Certificate>
</dsig:X509Data>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>....</dsig:Modulus>
<dsig:Exponent>....</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</dsig:KeyInfo>
</dsig:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">G-820ec535-fa2a-43ad-89de-6b18814acc85</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="_4F3828DFD1CB6FFB2A20091B9199DB1E" NotOnOrAfter="2020-09-08T18:57:06.151Z" Recipient="https://mail.domain.com/SOGo/saml2-signon-post&quot;/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2020-09-08T18:52:06.151Z" NotOnOrAfter="2020-09-08T18:53:06.151Z">
<saml:AudienceRestriction>
<saml:Audience>https://mail.domain.com/SOGo/saml2-metadata&lt;/saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2020-09-08T18:52:08.151Z" SessionIndex="cafd0a71-8d1e-4be7-beaa-2fcd179152c0::fe23effb-ef22-4588-a8af-586b2e2ec57e" SessionNotOnOrAfter="2020-09-09T04:52:08.151Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute FriendlyName="email" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:type="xs:string">user@domain.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="username" Name="username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:type="xs:string">user</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

As far as I can tell, this is all perfectly compliant.

The interesting part comes when I try to map a login attribute. Normally I used login to SOGo using the full email address (SOGoForceExternalLoginWithEmail = YES) with LDAP, so I tried to set
SOGoSAML2LoginAttribute = mail;
but I would receive
NAME:NSInvalidArgumentException REASON:Tried to add nil value for key 'login' to dictionary INFO:{}
in sogo.log, so I thought there was some problem with my mappings in Keycloak. Turns out this is not the case, since when I use
SOGoSAML2LoginAttribute = username;
I get
(process:2822): GLib-GObject-CRITICAL **: 23:12:01.378: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Sep 08 23:12:01 sogod [2822]: [IP] "GET /SOGo//[username] HTTP/1.0" 302 0/0 0.011 - - 0
which means that it can see the SAML attribute, which however is of course wrong and cannot be mapped to my users since it lacking the domain.

I tried a few different combinations of parameters, and it seems that the problems occurs when I try to map login to a string that contains a '@', which would make sense consider that in the source code for SAML2 a string with '@' is treated differently and is sent to SOGOUserManager.

However I need necessarily to have a '@' in the login attribute, so this breaks SAML2.

Steps To Reproduce
  1. Enable SAML2.
  2. Set SOGoSAML2LoginAttribute to a SAML attribute containing a '@'.
  3. Get NAME:NSInvalidArgumentException REASON:Tried to add nil value for key 'login' to dictionary INFO:{} and a 5** response from the server.
Additional Information

I had commented out SOGoUserSource to disable LDAP, but then I thought that maybe SOGoUserManager needed it to map it to the user uid so I enabled it again. This makes no difference.

Tagsldap, saml

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2020-09-08 18:14 francesco.carzaniga New Issue
2020-09-08 18:14 francesco.carzaniga Tag Attached: ldap
2020-09-08 18:14 francesco.carzaniga Tag Attached: saml