SAML IDP not working with Gluu Server (3.1.3) Docker Edition

By: Naveen Kumar Gopi user 07 Jul 2018 at 1:44 a.m. CDT

8 Responses
Naveen Kumar Gopi gravatar
We have installed the Gluu (3.1.3) Docker Edition and trying to integrate our GSuite domain with the SAML IDP of Gluu Docker Edition. We have done all the configuration steps as mentioned in https://gluu.org/docs/ce/3.1.3/integration/saas/google/ but the SAML IDP returns 503 error. https://gluu_domain/idp/shibboleth https://gluu_domain/idp/profile/SAML2/Redirect/SSO Both the above endpoints are returning 503 Service Unavailable error. However, when we integrated GSuite with Gluu 3.1.2 (Non docker version) by following the same steps, the SAML endpoints worked fine and we were able to successfully integrate with GSuite. Can you please let us know if SAML IDP is supported in Gluu Docker edition and whether we have to do any additional setup to make the SAML IDP work in Gluu DE? Error seen in idp-process.log of Gluu Docker Edition: ``` 2018-07-07 05:08:47,575 - ERROR [org.springframework.web.context.ContextLoader:351] - Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.metrics.RegisterMetricSets$child#0' defined in URL [file:/opt/shibboleth-idp/conf/admin/metrics.xml]: Cannot resolve reference to bean 'shibboleth.metrics.AttributeResolverGaugeSet' while setting bean property 'arguments' with key [7]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.metrics.AttributeResolverGaugeSet' defined in URL [file:/opt/shibboleth-idp/system/conf/general-admin-system.xml]: Invocation of init method failed; nested exception is net.shibboleth.utilities.java.support.component.ComponentInitializationException: Injected service was null or not an AttributeResolver ```
Ubuntu 16.04
closed

Answers

By Michael Schwartz Account Admin 07 Jul 2018 at 9:54 a.m. CDT

Copy
Michael Schwartz gravatar
Interesting... I wonder if it's because of this filesystem resource `file:/opt/shibboleth-idp/conf/admin/metrics.xml`

By Isman Firmansyah staff 09 Jul 2018 at 9:34 a.m. CDT

Copy
Isman Firmansyah gravatar
Hi Naveen, Are you deploying the Docker version using [this example](https://github.com/GluuFederation/gluu-docker/blob/3.1.3/examples/single-host/docker-compose.yml)? Note that in Gluu Server CE, oxShibboleth and oxTrust reads config from a same directory `/opt/shibboleth-idp` in host filesystem. But in docker edition, each oxTrust and oxShibboleth container is isolated from each other, they have their own filesystem. To load IDP/SP config, oxShibboleth container requires special way to share filesystem. In our [singlehost example](https://github.com/GluuFederation/gluu-docker/tree/3.1.3/examples/single-host), we're using docker's mounted volumes. [Here](https://github.com/GluuFederation/docker-oxshibboleth#design-decisions) is how we designed oxShibboleth container to work with files that generated by oxTrust. Best regards

By Naveen Kumar Gopi user 11 Jul 2018 at 12:48 a.m. CDT

Copy
Naveen Kumar Gopi gravatar
Thank you for the responses. Hi Isman, Yes, we have deployed the docker version as a single host setup. I do see that the changes we have done to the below files in oxTrust container is getting reflected in both the "/opt/shared-shibboleth-idp" folder as well as the "/opt/shibboleth-idp" folder of oxShibboleth container Modified files in oxTrust: relying-party.xml.vm, saml-nameid.xml, attribute-resolver.xml.vm Yet we are getting the same error in the idp-process.log while restarting the oxShibboleth container. Kindly let us know if we are missing any setup in the docker version. Thanks, Naveen

By Isman Firmansyah staff 11 Jul 2018 at 12:16 p.m. CDT

Copy
Isman Firmansyah gravatar
Hi Naveen, Let me try to reproduce the issue to see what's missing.

By Isman Firmansyah staff 29 Jul 2018 at 12:53 a.m. CDT

Copy
Isman Firmansyah gravatar
Hi Naveen, After testing few times, the error you've seen after restarting oxShibboleth is caused by hostname and certificate CN mismatch (you can see the errors in `idp-warn.log`). As example, in oxShibboleth `ldap.properties`, `ldapURL` is pointed to this URL: ``` idp.authn.LDAP.ldapURL = ldaps://ldap:1636 ``` but `openldap.crt` includes `CN=<hostname>`. This cert mismatch will prevent oxShibboleth to connet to LDAP, hence context initialization will also fail. We're working on how to fix this issue (including how to update the cert).

By Naveen Kumar Gopi user 30 Jul 2018 at 12:30 a.m. CDT

Copy
Naveen Kumar Gopi gravatar
Hi Isman, Thanks for sharing your findings. Kindly let us know once the solution for this issue is found. Regards, Naveen

By Isman Firmansyah staff 15 Aug 2018 at 10:11 a.m. CDT

Copy
Isman Firmansyah gravatar
Hi Naveen, You can check latest update of https://github.com/GluuFederation/gluu-docker/blob/3.1.3/examples/single-host/docker-compose.yml#L74 to make sure LDAP cert is regenerated. The docs is here https://gluu.org/docs/ce/3.1.3/docker/technical/#opendj. Note, you will also need to pull updates for `gluufederation/oxshibboleth:latest` and `gluufederation/opendj:latest` images.

By William Lowe user 27 Aug 2018 at 7:04 p.m. CDT

Copy
William Lowe gravatar
Hi Naveen, Closing this ticket for now. Feel free to share your results here. Thanks, Will

Post an answer