By: sachin wagh user 09 Sep 2021 at 5:08 a.m. CDT

6 Responses
sachin wagh gravatar
Hello, We are trying to set up SSO with G-suite where our Gluu instance will act as an IdP. From G-suite (now Google Workspace) login page once user enters email, user is successfully redirected to our gluu login page. **The authentication seems to be successful on gluu and user is redirected back to the G-suite page. However, user is shown "Invalid Email" error and cannot access G-suite.** Our Gluu version is 4.1.1. We have followed steps mentioned in this doc page: **Additional info:** 1. In Google's SSO settings, "Use a domain specific issuer" was enabled. 2. The user we are trying to login with exists in Gluu as well as on Google. 3. The email ids associated with both are matching. 4. The SAML Response signing certificate (included in the response itself) is proper and the same is already configured in Google settings. 6. The time settings on Gluu is correct (the times mentioned in SAML response were matching the time when we were trying to login). Please let us know if we have missed something in configuration steps or what could we try next to fix this. Thanks.

By Michael Schwartz Account Admin 09 Sep 2021 at 2:42 p.m. CDT

Michael Schwartz gravatar
Alex, any thoughts?

By Aliaksandr Samuseu staff 09 Sep 2021 at 2:55 p.m. CDT

Aliaksandr Samuseu gravatar
Hi. @Michael.Schwartz , it needs nameid of specific type ("urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"), so may be something is off with configuration, and GSuite doesn't get it? Let me give it a try, I wonder if this doc is still up to date..

By Aliaksandr Samuseu staff 09 Sep 2021 at 2:57 p.m. CDT

Aliaksandr Samuseu gravatar
Sachin, could you please also record a network trace for us, and share it as a HAR file? You can use steps listed [here]( - please use Firefox for that task, Chrome's HARs are flawed. Also don't forget to set "Persist log" and "Disable cache" checkboxes in the console to save everything, not just the recently loaded page. Share the HAR file using any file sharing service you wish, or mail it to me at ``

By sachin wagh user 13 Sep 2021 at 5:18 a.m. CDT

sachin wagh gravatar
Hello Alex, Have recorded network trace using Firefox and sent the HAR file to your email.

By sachin wagh user 26 Sep 2021 at 10:16 a.m. CDT

sachin wagh gravatar
We are stil trying to fix this issue. Posting some observations and additional information : ** Gluu is always returning NameID in transient format and never in email or emailAddress format.** **Configuration** 1. In the "Single sign-on (SSO) with third-party identity providers (IDPs)" section in Google Admin for our domain, specified our Gluu URLs and enabled "Use a domain specific issuer" 2. In Gluu, in the Trust Relationship for Google: Used the following metadata: `<EntityDescriptor entityID="" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:email</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat> <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="" > </AssertionConsumerService> </SPSSODescriptor> </EntityDescriptor>` Released attributes Email (and also first name, last name, display name and username for testing) Enabled Configure Relying Party. In its configuration: Selected Profile Configurations: SAML2SSO, SAML2Logout and SAML2AttributeQuery In SAML2SSO, included NameIDFormats: SAML:1.1:nameid-format:emailAddress, SAML:2.0:nameid-format:persistent, SAML:2.0:nameid-format:transient 3.Gluu documentation says to make changes in /opt/gluu/jetty/identity/conf/shibboleth3/idp/saml-nameid.xml.vm. There is no file present in that directory 4.Found similar named file at /opt/shibboleth-idp/conf/saml-nameid.xml 5.Made the changes recommended in the documentation (uncommenting the two bean tags, SAML2AttributeSourcedGenerator and SAML1AttributeSourcedGenerator). NOTE: On restarting the idp and identity services, the file get restored to their original state. Must be getting copied from somewhere. NOTE: Tried specifying email for SAML2.0 and emailAddress for SAML1.1 NOTE: Also tried making changes to in the same directory. But even this file gets restored to original state after restarting services ``` #Default NameID Formats to use when nothing else is called for. #Don't change these just to change the Format used for a single SP! #idp.nameid.saml2.default = urn:oasis:names:tc:SAML:2.0:nameid-format:transient #idp.nameid.saml1.default = urn:mace:shibboleth:1.0:nameIdentifier idp.nameid.saml2.default = urn:oasis:names:tc:SAML:2.0:nameid-format:email idp.nameid.saml1.default = urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ``` saml-nameid.xml: ``` <bean parent="shibboleth.SAML2AttributeSourcedGenerator" p:omitQualifiers="true" p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:email" p:attributeSourceIds="#{ {'mail'} }" /> <bean parent="shibboleth.SAML1AttributeSourcedGenerator" p:omitQualifiers="true" p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" p:attributeSourceIds="#{ {'mail'} }" /> ```

By Aliaksandr Samuseu staff 30 Sep 2021 at 3:57 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Sachin. Yes, your assessment is correct (sorry for the huge delay with my response..) > Gluu is always returning NameID in transient format and never in email or emailAddress format You should be able to configure release of nameid of the required format from web UI ("SAML" > "Configure custom NameID" page) - have you tried that? [This doc]( may help. In 4.x you shouldn't need to modify the `` at all, and you shouldn't need to modify `saml-nameid.xml` manually as well, the web UI control should do all the job. Please revert the changes you could have done there, and try the web UI approach first. When you'll the required nameID in web UI, a corresponding new XML element should appear in `saml-nameid.xml` file (you can copy the original file prior to that, and run `diff` against two files, to make sure it happened). After that, pleaes share the current contents of this file with us, so we could confirm it worked as expected. If it won't do, for some reason, we'll have to resort to template editing. In 4.x templates are not lying around unpacked as older docs may tell you. Instead, they are packed into a JAR inside `idp.war`, so will require some extra steps to deploy. But hopefully it won't be needed. We really need to revisit that doc, I don't think it properly describes procedure for current version, sorry about that.