conflicting metadata, force NameIDFormat?

[Baron Fujimoto]

We're trying to integrate our IdP (3.2.1) with a new SP (SAP Concur). The SP says they require a NameID to be an email address, and the metadata they've provided includes the expected element:

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

We've done this for other SPs, where it works as expected, but here instead of returning a nameid-format:emailAddress, we were returning the default nameid-format:transient. Troubleshooting eventually determined that there was a conflict with the InCommon aggregate metadata; if the InC metadata is not loaded, then the Concur SP configuration returns nameid-format:emailAddress as desired. Inspection of the InC metadata yielded that the SP is apparently an InC member and has an entry with the same entityID (https://us.api.concursolutions.com/saml) in the InC metadata, but that InC entry does not contain a NameIDFormat element. We see the following in the SAML response:

StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"

I am assuming that the IdP is using the InC entry based on the entityID for the SP and ignoring the subsequent metadata provided seaparately for them. Questions re this assumption:

- Is a matching metadata selected based on the SP entityID?
- Is a the selected metadata chosen on a first match basis? If so, this dependent on the order in which the metadata is loaded in the metadata-providers.xml conf file?

If the assumption above is correct, what's the recommended way to resolve this? IMO, it seems the SP should include the NameIDFormat in the InC metadata and we just use that, else others may encounter similar problems. I don't know if they'll actually do so though due do their internal institutional inertia, concern about potentially breaking other legacy integrations with other IdPs, or whatever. So we may have to find a kludge for this on our end.

If the metadata selection is load order dependent, should their metadata be loaded before InC's? This is unappealing though since it seems "fragile" and prone to being overlooked by configuration maintainers. Or is this an accepted approach?

It also seems like this may be resolved by overriding a default profile configuration by specifying a nameIDFormatPrecedence for the relying party, but this also seems to be order dependent. If this this order dependent sequencing is routine, doe sthat suggest something like the InC entries should be last so that more specific matches should be picked up first?

<https://wiki.shibboleth.net/confluence/display/IDP30/RelyingPartyConfiguration>

Or is there something else we're overlooking? What are the best practices for this sort of thing?

-- 
UH Information Technology Services : Identity & Access Mgmt, Middleware
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum