Bi-directional federation in SAML

Conor proposes a model by which the federated identifier(s) established in one "direction" can be made to serve double duty in the other direction.

For instance, if an IDP and SP agree to use 'abc' whenever they communicate in order to refer to a particular user (either in an IDP Response or some SP message), then that same identifier could be used were the two to switch roles. So, if the SP (acting as an IDP) were to issue an Assertion for the user in question, the SP would use 'abc' in its NameID rather than some other identifier that the two providers might feel the need to establish for this direction).

Seems to make sense.

But if, instead of there being a single federated identifier 'abc' for the user between the two providers, as will happen if the SP avails itself of its right to specify 'def' as the identifier (called the SPProvidedID) it desires the IDP use when referring to the user, then things don't seem as clear.

Conor recommends that, in this case, when the SP switches roles and creates an Assertion for the user to be delivered to the IDP, the SP also effectively switch identifiers, and use that identifier it previously specified as the SPProvidedID as the primary identifier. So, the NameID of the reverse direction Assertion would look like

<saml2:NameID Format="persistent" SPProvidedID="abc">
     def
</saml2:NameID>

This model can be justified because the 'abc' identifier was initially generated by the IDP (but now consuming it playing the role of an SP). So, placing it in the SPProvidedID attribute makes sense. In this model, providers use the identifiers appropriate to whatever current role they are playing, rather than whatever role they might have been playing when the id was established.

Problem is, I think the alternative option, in which providers, once they've agreed upon an identifier(s) to use, use that identifier regardless of the roles they may find themselves playing in the future. In this case, because the two providers initially agreed that, when communicating from the SP to the IDP, the 'abc' identifier is the right one to use, the SP would do just that in its Assertion to the IDP. Consequently, the NameID would be the mirror image of the above

<saml2:NameID Format="persistent" SPProvidedID="def">
     abc
</saml2:NameID>

There is I think justification for this model in trying to stay consistent with the case where there is only the single 'abc' identifier. For this case, to be consistent with the model where the choice (and location) of an identifier is determined by the current role of the provider using it, then the NameID in the reverse direction would necessarily appear as:

<saml2:NameID Format="persistent" SPProvidedID="abc">
     null
</saml2:NameID>

As it was the IDP that originally created the 'abc' identifier, then (when acting as an SP) that identifier needs to appear in the SPProvidedID attribute of the reverse Assertion (phew, say that 5 times fast). And, because the SP had never generated its own identifier to give to the IDP, it has to insert 'null' as the value of the NameID element. But, the above is different than what Conor proposes for this simple single identifier case.

Conor appears to acknowledge the choice, as he writes:

With that minor understanding, the remaining SAML 2.0 profiles, including Browser SSO, all work out-of the box bi-directionally.