Friday, September 29, 2006

Bi-Directional Federation and SAML part 2

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 : / / / / / /

No comments: