Bi-Directional Identity Federation

Recently a friend asked me about Bi-Directional Identity federation and how it could be done with SAML 2.0. The now familiar off-the-shelf uni-directional identity federation involves an Identity Provider (IdP) issuing an identifier for a user and agreeing to only transmit that identifier to the Service Provider (SP) if the same user returns to the SP (in an SSO transaction from the IdP) at some point in the future.

Bi-directional federation takes that one step further allowing the SP to act as an IdP in some future transaction and assert the user's identity to the former IdP now acting as a SP.

The issues at play in this situation are mostly about policies. Has the user allowed their identity at the SP to be asserted to the IdP? Is there some special agreement that the user consents to during the first federation that explicitly states this is allowed? Does the IdP accept identities asserted by the SP?

From a technical point of view, it's much clearer. Federation (in this case) is about the agreement of two parties to use a handle (identifier) for the user. In the case of the user federating from the IdP to the SP, the IdP issues the handle and passes it to the SP. The SP may accept and use that handle, or it may ask the IdP to provide it (the SP) with an additional handle created by the SP (the SPProvidedID in SAML-speak). These identifiers are carried in the <saml2:NameID> element within the <saml2:Subject> of an assertion. An example NameID with both IDs:

<saml2:NameID Format="urn:oasis:tc:SAML:2.0:nameid-format:persistent"
              SPProvidedID="uuid:SP923-230328-0324780-23023">
    uuid:IDP99-93830023-02392390-902380
</saml2:NameID>

For Bi-directional federation, nothing else needs to be done. The exchange of handles that has already taken place can be used for each direction. In the case where there's only one handle (the IdP created handle) the SP can now use that same handle when asserting the identity to the IdP (although the SP would need to specify the NameQualfier attribute since the SP was not the issuer of the NameID). For example:

<saml2:NameID Format="urn:oasis:tc:SAML:2.0:nameid-format:persistent"
              NameQualifier="http://idps-r-us.com" >
    uuid:IDP99-93830023-02392390-902380
</saml2:NameID>

In the case where the SP has registered its SPProvidedID at the IDP, I would recommend that the IDs are placed in inverse positions when the user's identity is asserted in the opposite direction, so the example NameID above would change to be the following when the identity was asserted from the SP to the IdP:

<saml2:NameID Format="urn:oasis:tc:SAML:2.0:nameid-format:persistent"
              SPProvidedID="uuid:IDP99-93830023-02392390-902380">
    uuid:SP923-230328-0324780-23023
</saml2:NameID>

Note that the ID issued by the entity that was acting as the IdP during the original federation operation is now placed in the SPProvidedID attribute as, in the current transaction, they are acting as the SP.

With that minor understanding, the remaining SAML 2.0 profiles, including Browser SSO, all work out-of the box bi-directionally. There are no changes to the protocols necessary to support Bi-Directional federation.

As with much of the work in the Identity world, it isn't a hard technical problem, but more of a business and policy problem (which can take much more time and energy to solve).

Tags : identity / federation / saml / saml2 / idp