Paul writes in response to my article about Bi-Directional Federation article.
He takes a quite long time to get there, but essentially he questions my choice as to the location of the identities within the SAML 2.0 <NameID> element. His main concern is that when each party is using an different identifier, the reverse assertion has the original IdP's identifier in the SPProvidedID attribute, while when they are using a single identifier, that identifier appears as the <NameID> value(not the SPProvidedID attribute).
While I'll admit there's a certain level of consistency to Paul's proposal, I still think that the right way is to put the identifier in the <NameID> value rather than the SPProvidedID. My reasons include:
- The <NameID> carries the value chosen by the "IdP" to represent the user at the "SP". In this case, the Former-SP-Now-Acting-As-An-IdP has chosen to use the identifier that it had received from the Former-IdP-Now-Acting-As-An-SP. Therefore that value belongs in the <NameID> element, not in the SPProvidedID attribute.
- The SAML 2.0 Core Specification does not allow for a null value in a persistent identifier (see section 8.3.7).
- Lines 3326-3332 and 3350-3356 of the SAML 2.0 Core Specification actually discuss the case of an SP using the same identifier provided to it by an IdP when that SP-now-acting-an-IdP issues assertions pointing out that they would need to identify the original issuing party using the NameQualifier attribute.
To me, it's clear that while there may be a bit of an inconsistency in placement of the identifier in the single vs muti-identifier cases, the layout I proposed is compliant with the specifications (and, at least to me, more fitting with how name identifiers work).
Tags : identity / identity federation / federation / saml / saml 2.0 / liberty / liberty alliance
No comments:
Post a Comment