SAML TR added without custom RP configuration doesn't work

[aliaksander-samuseu]

Environment: CentOS 6.7, Gluu CE 3.0.1-1-3

Preconditions: Gluu was installed with full set of modules

Steps to reproduce:

1. Log in to web UI as admin user
2. Move to "SAML -> Trust Relationships" page and click "Add TR" button there
3. Fill in all fields on the page required to create some simple valid TR there using "Url" method (may work for "File" too). Make sure metadata you'll use is valid/reachable, i.e. under normal circumstances it must pass validation successfully in Gluu and result in active TR. Do not activate "Configure Relying Party" feature! Release uid, transientid and email attributes.
4. Click the "Update" button to finalize the creation and wait until it passes validation and becomes active.
5. Restart IdP service to make sure it reload updated configuration from disk: # service idp restart
6. Try to access SP you configured.

Result: After user is redirected to IdP it responds with "Application is not registered" error page. In idp-process.log messages like this appears (note the "No metadata returned" part):

2017-02-17 22:56:36,569 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler:  No metadata returned 
for https://sphost-shib.site:8443/shibboleth in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SA
ML:2.0:protocol
2017-02-17 22:56:36,587 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: P
rofile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for relying party configuration shibboleth.UnverifiedRelyingParty
2017-02-17 22:56:36,594 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: InvalidP
rofileConfiguration

grepping for SP's hostname shows, that in case when TR is created without custom RP settings entry for this SP is not added to /opt/shibboleth-idp/conf/metadata-providers.xml

Without it:

# grep -i -r -e 'sphost-shib' /opt/shibboleth-idp/conf/
/opt/shibboleth-idp/conf/attribute-filter.xml:        <PolicyRequirementRule xsi:type="Requester" value="https://sphost-shib.site:8443/shibboleth" />

With it:

# grep -i -r -e 'sphost-shib' /opt/shibboleth-idp/conf/
/opt/shibboleth-idp/conf/metadata-providers.xml:                      metadataURL="https://sphost-shib.site:8443/Shibboleth.sso/Metadata"
/opt/shibboleth-idp/conf/relying-party.xml:        <bean parent="RelyingPartyByName" id="DB5D9A62F10F706C0002180CF85A0006460D81EB" c:relyingPartyIds="https://sphost-shib.site:8443/shibboleth">
/opt/shibboleth-idp/conf/attribute-filter.xml:        <PolicyRequirementRule xsi:type="Requester" value="https://sphost-shib.site:8443/shibboleth" />

You can view full screen capture here

Expected result: If custom RP properties are not specified TR is still functional, has corresponding entry in /opt/shibboleth-idp/conf/metadata-providers.xml: file and default RP configuration provided in /opt/shibboleth-idp/conf/relying-party.xml is used for it.

[aliaksander-samuseu]

@yurem As you can see from screen capture, if you configure custom RP settings afterwards, TR starts to work. Interesting fact: if you then uncheck this checkbox thus removing custom settings again, and restart IdP service, TR will stop to work. Grepping will show that /opt/shibboleth-idp/conf/metadata-providers.xml file again doesn't have entry for this SP, i.e. it is removed after you disable this feature.

[aliaksander-samuseu]

@dmogn

A bit of update: it's been confirmed that it also doesn't work for TR of type "Federation", and in this case even adding Custom RP config to it doesn't fix the issue.

[aliaksander-samuseu]

@dmogn @yurem

What is status of this? Atm we can't configure Federation TRs which release attributes at all in 3.0 via web UI

[dmogn]

@aliaksander-samuseu Thanks for the note. Federation case is caused because of "race condition" in URL metadata downloading & processing. It's only a part of the problem. Status: in process

[dmogn]

Federal case: UI calls save(); create second thread for metadata downloading and process metadata for isFederal() checking in first thread. But metadata in second thread isn't downloaded yet... From here: https://github.com/GluuFederation/oxTrust/issues/505

[willow9886]

@dmogn is this issue fixed?

[dmogn]

@willow9886 Yes. Fixed. I'll merge today.

[dmogn]

[20:53:18] Alex Samuseu: Here is a problem in the latest 3.1 build. When I create SAML TR of type federation, it passes metadata validation, but nevertheless is shown as TR of type "site" in the list, and I can't use it to create other TRs based on it as before. [21:03:55] Alex Samuseu: Fixed it for this one TR by editing "gluuIsFederation" attribute in ldap, but it's still a bug

[aliaksander-samuseu]

@shekhar16 @dmogn

Reopening it as it's been designated for 3.0.2 and I still can reproduce it in my release deb pakage. Fed metadata's element is not added to /opt/shibboleth-idp/conf/metadata-providers.xml file at all, and regular TR's is added only if it's created with custom relying party configuration added to it. If it was again fixed for 3.1.x branch, was it also back-ported to 3.0.x?

[nynymike]

Closing this as won't fix. In 3.0 it is required to click on Configure Relying Party