Bi-Directional Federation and SAML part 3

Paul continues our "discussion" on Bi-Directional federation

I'm sure he would have preferred to actually get in and invoke 'editorial privileges' to modify my post but Conor has settled for a response.

If only that were the case... :-)

Paul then goes on to quote my explanation about what a NameID is and to question my interpretation with:

The other interpretation is that, when playing their initial roles, the SP and IDP made the following commitment to each other:

SP: Dear IDP, when I communicate with you I will use the 'abc' identifier (in the NameID) that you created for me.
IDP: Dear SP, when I communicate with you I will use the 'def' identifier (in the SPProvidedID) that you created for me.

I'm not sure where the "Dear"s came from, but NameIDs are always chosen by an IdP when the IdP creates an assertion. To be totally clear, in any given transaction there is exactly one IdP and exactly one SP. The IdP generates the assertion and sends it to the SP. The IdP chooses the identifier to use. This identifier becomes the value of the <NameID> element. If the entity that is the SP in this transaction had previously asked, the IdP will also include an identifier that the SP provided previously (in the SPProvidedID attribute on the <NameID>).

If the format attribute of the <NameID> element has the value "urn:oasis:tc:SAML:2.0:nameid-format:persistent", the entity acting as the IdP is also agreeing that should it generate a subsequent assertion for the same principal, the assertion will have the same identifier (so the identifier has some level of persistence).

Now, the identifier chosen by the IdP may not be from the IdP itself. It may use an identifier created by another party. That is why there is a NameQualifier attribute. This attribute is there so that when the IdP is using an identifier created by another party (such as another IdP), the IdP using the identifier can identify the other party.

I assert that this exact case is what is happening in a bi-directional federation where both IdPs have chose to use the same identifier for the user. Regardless of direction, the identifier will be placed into the value of the <NameID> element and in both cases the NameQualifier will be the IdP that originally created the identifier (although in the case where the IdP that created the identifier is also the party issuing the assertion, they MAY omit the qualifier since the context (they issued the assertion) is enough to figure out it is their assertion).

Anyway, Paul goes on with:

Conor will argue that the initial commitment is more along the lines of:

SP: Dear IDP, when I (acting as an SP) communicate with you I will use the 'abc' identifier (in the NameID) that you created for me. When however I (acting as an IDP) might communicate with you, I will use the 'def' identifier (in the NameID) that I created for you.
IDP: Dear SP, when I (acting as an IDP) communicate with you I will use the 'def' identifier (in the SPProvidedID) that you created for me. When however I (acting as an SP) might communicate with you, I will use the 'abc' identifier that I created for you.

The problem here is that this makes it seem like these statements are being made as part of the protocols (or due to some message) and that isn't the case. I point back to what I said before about the single transaction, one IdP, one SP, how identifiers work. There's no "I'll do this when that and I'll do this other thing when that other thing".

Paul later says (referring to a section of the SAML Spec I quoted):

As I read them, these two paragraphs from the SAML spec require that the Former-SP-Now-Acting-As-An-IDP, if they use an identifier initially created by the Former-IDP-Now-Acting-As-An-SP, to use the NameQualifier attribute. So, the example from my first response was incorrect, it should have been

<saml2:NameID Format="persistent" SPProvidedID="def" NameQualifier="IDP.com">
     abc
</saml2:NameID>

So the question of the hour is: which example?

If we're talking about the single identifier case, that is the example I had in my original post that we've been going on and on about other that the fact that it somehow now has a second identifier (which doesn't fit the use case as we were talking about a single identifier case (both parties chose to use the same identifier)).

So, perhaps, this long article by Paul is just a way of him saying to me, "You're right"... (I do like to hear that :-)).

Tags : identity / identity federation / federation / saml / saml 2.0 / liberty / liberty alliance