Hi **Cory**, The documentation has been updated to fix that issue. Please check the updated doc [here](https://github.com/GluuFederation/docs-ce-prod/blob/3.1.2/3.1.2/source/integration/saas/testShib2.md). Basically the changes are related to **Trust relationship configuration**. You have to released some attributes and also configure Relying Party with **SAML2 SSO Profile** Thanks, Gasmyr.

Gasmyr, I have made the aforementioned changes, however I'm still unable to access the SSO page when accessing from the setup SP. I'm not seeing anything in identity logs, is there anywhere else I should be looking? Cory

Please provide the following log file. `/opt/shibboleth-idp/logs/idp-process.log` Also make sure to restart the `idp service`. I my case i also restart the gluu service. Thanks, Gasmyr

After refreshing the idp and identity services, I am able to hit the TestShib2 validation successfully, so I assume I had some changes stored that needed to be loaded. However on another stored SP I cannot. From idp-process.log: ``` 2018-04-09 11:36:05,223 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler: No metadata returned for https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/metadata.php/default-sp in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol 2018-04-09 11:36:05,229 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/metadata.php/default-sp) 2018-04-09 11:36:05,232 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: InvalidProfileConfiguration ```

Do you mean that it works for some SP and didn't for another? From the log you can see this : > No metadata returned for https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/metadata.php/default-sp in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol. The configuration for that SP is no valid. Seems like you are missing something. Can you share the screenshot for the configuration of that SP?

Yes. The "TestShib2" sp/federation now validates successfully and SAML flow is successful. However this other one doesn't, even though it gives a success message in validating the metadata xml in the GUI. We've got a suspicion this SP's xml metadata has misconfigured uri's. ``` <?xml version="1.0"?> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://ucportal.cspirevoice.com/samlauth/module.php/saml/sp/metadata.php/default-sp"> <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/saml2-logout.php/default-sp"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/saml2-acs.php/default-sp" index="0"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/saml1-acs.php/default-sp" index="1"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/saml2-acs.php/default-sp" index="2"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/saml1-acs.php/default-sp/artifact" index="3"/> </md:SPSSODescriptor> </md:EntityDescriptor>```

yeah, Seems like there is a typo in the entityID in your metadata file. 1. **https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/metadata.php/default-sp** 1. **https://ucportal.cspirevoice.com/samlauth/module.php/saml/sp/metadata.php/default-sp** You have to choose the right value for **entityId** in the metadata.

From the log you can see this **No metadata returned for `https://ucportal2.cspirevoice.com/samlauth/module.php/saml/sp/metadata.php/default-sp` in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol**. And from your metadata you a different value is provide: **entityID="`https://ucportal.cspirevoice.com/samlauth/module.php/saml/sp/metadata.php/default-sp`"** Thanks, Gasmyr.

Gasmyr, We reached out and got this XML corrected and it seemed to have fixed that issue, but now we get an unrecoverable 503 from /idp/shibboleth. Getting issue: ``` 2018-04-09 16:02:18,740 - 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 at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:359) Caused by: 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 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578) Caused by: net.shibboleth.utilities.java.support.component.ComponentInitializationException: Injected service was null or not an AttributeResolver at net.shibboleth.idp.attribute.resolver.impl.AttributeResolverServiceGaugeSet.doInitialize(AttributeResolverServiceGaugeSet.java:104) ``` which is usually recoverable by restarting idp service, but now is not the case. Can you help?

Hi **Cory**, Which Ldap implementation have you choose during Gluu setup? That information can help us in the troubleshooting process.

I'm using the OpenDJ LDAP implementation. I've previously had a similar error where I simply had to change a cert location parameter in shibboleth's properties file, but it's doesn't seem to fix this issue.

Hello Cory, Please edit the following line in `/opt/shibboleth-idp/conf/ldap.properties`. From: `idp.authn.LDAP.trustCertificates = /etc/certs/openldap.crt` to `idp.authn.LDAP.trustCertificates = /etc/certs/opendj.crt` Then restart **identity ** and **idp** services. Thanks, Gasmyr.

Hi **Cory**, Still need assistance ? Thanks, Gasmyr.

Yes, we seem to have found the issue. On restart, this item is found in "attribute-resolver.xml": ``` <resolver:AttributeDefinition xsi:type="ad:Simple" id="" sourceAttributeID="mail"> <resolver:Dependency ref="siteLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress" /> </resolver:AttributeDefinition> ``` Upon removing it, /idp/shibboleth returns to normal. However, upon restart of GLUU, this is placed back into the original file as if nothing happened. Have you guys seen this before?

Hi **Cory**, That bug has been fixed in Gluu server v3.1.3 A workaround will be that each time the Gluu service is restart, you changes that value and restart just the identity and idp service. Thanks, Gasmyr