Is the https certificate self-signed?

Yes it is.

Hi, Can you provide that url? We want to reproduce that locally. Also went validation fails, you can provide log file.

We have done a few more things. We generated a SP-metadata file and copied it to the Gluu server so we didn't have to fetch the SP metadata using the URI. So because of big-hammer technology, the URI issue is less important now. Now we're browsing to https://my_url.com:884/Shibboleth.so/Login The idea is to see the redirect and get the Gluu login prompt. We figure that if it works that far, we're probably on the right track. It is failing with the "Web Login Service - Unable to respond" page. The page included "the login service was unable to identify a compatible way to respond..." the sp-metadata file contains is: ``` <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://my_url.com:884/Shibboleth.sso"> <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol"> <md:KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDCDCCAfACCQCubjLFqxNcvTANBgkqhkiG9w0BAQsFADBGMQswCQYDVQQGEwJV (snip) s9tHQU23Ei7H7ein </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://my_url.com:884/Shibboleth.sso/SAML2/POST" index="1"></md:AssertionConsumerService> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://my_url.com:884/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"></md:AssertionConsumerService> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://my_url.com:884/Shibboleth.sso/SAML2/ECP" index="3"></md:AssertionConsumerService> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://my_url.com:884/Shibboleth.sso/SAML/POST" index="4"></md:AssertionConsumerService> </md:SPSSODescriptor> </md:EntityDescriptor> ``` Note the location elements at the bottom all have a port of 884. The idp_process.log file contains the following: ``` 2018-07-12 21:42:04,526 - WARN [net.shibboleth.idp.saml.profile.impl.PopulateBindingAndEndpointContexts:410] - Profile Action PopulateBindi ngAndEndpointContexts: Unable to resolve outbound message endpoint for relying party 'https://my_url.com/Shibboleth.sso': Endpoint Criterion [type=furn:oasis:names:tc:SAML:2.0:metadatalAssertionConsumerService, Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, Location=https://my_url.com/Shibboleth.sso/SAML2/POST, trusted=false] 2018-07-12 21:42:04,527 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: EndpointResolutionFailed ``` Note that the endpoint in the log does not include the 884 port. I think it needs to be there. What can we do?

Are you sure that it's not an SSL issue? If the https certificate is self-signed, you'll need to import it into the Shibboleth java trust store, or there is no way that Shibboleth will download it.

It does not feel like an SSL issue. The URLs being used by Shib IdP and/or Gluu are not correct, per the log file above; the port numbers are missing.

yes, that's very strange. Why aren't you using port 443?

yeah. We have two containers, one for our application web server, and this new SP server. They live on the same VM and share a URL. The devops engineer built the SP container to use non-default ports so we would not have URL conflicts. I don't know if this was a great idea, but it is what I have right now. The ports specified in the metadata file should be used; I don't think that Shib or Gluu should just ignore or strip them as this sounds like a bad approach. Can you confirm or deny that Gluu (or Shib IdP??) trims off the port numbers?

I personally have no idea. We don't see this with SAML ever. You can dig on the shibboleth wiki to see if it's possible. You could also use a custom template if the oxTrust GUI won't support it.

See [https://gluu.org/docs/ce/3.1.3/admin-guide/saml/#modifying-shib-templates](https://gluu.org/docs/ce/3.1.3/admin-guide/saml/#modifying-shib-templates)

Hi Tony, When i try to create a TR with the metadata provide in get an error related to certificate. https://pasteboard.co/Hue51UZ.png ``` <ds:X509Certificate> MIIDCDCCAfACCQCubjLFqxNcvTANBgkqhkiG9w0BAQsFADBGMQswCQYDVQQGEwJV (snip) s9tHQU23Ei7H7ein </ds:X509Certificate> ``` How can we help if you provide data partially?

About this error: ``` Profile Action PopulateBindi ngAndEndpointContexts: Unable to resolve outbound message endpoint for relying party 'https://my_url.com/Shibboleth.sso': Endpoint Criterion [type=furn:oasis:names:tc:SAML:2.0:metadatalAssertionConsumerService, ``` Check this file: https://github.com/korteke/shibboleth-idp-v3/blob/master/idp-saml-impl/src/main/java/net/shibboleth/idp/saml/profile/impl/PopulateBindingAndEndpointContexts.java#L404 You can set idp log(**/opt/shibboleth-idp/conf/logback.xml**) level to debug to get more information about that error.

Thanks gents, we'll look into the templates.