Monday, April 30, 2007

Identity Meta-System SSO

In his entry “OpenID bootstrap to ID-WSF”, Paul describes the results of a very interesting IOS session in Brussels. As he outlines, the bootstrapping possibilities are pretty straight forward. An interesting point of the second option is that the RP would need to know how to obtain the appropriate security token in order to invoke the Discovery Service (DS) as defined in the publicly available DS-EPR. In the OpenID case, the OpenID “assertion” would need to be exchanged for the appropriate token used to invoke the Liberty DS service (in most cases a SAMLv2 assertion).

It's this token exchange mechanism that I find intriguing. Does it work both ways? Can I exchange a SAMLv2 Assertion for an OpenID “assertion”? This seems doable if the user is using a single IdP that “speaks” all the identity protocols. With this kind of a deployment model, the IdP can use browser cookies and other mechanisms to maintain the authentication session of the user. An example flow could be...
  1. User visits RP-A which only supports SAMLv2
  2. User's browser has a stored cookie identifying the SAML IdP to use (existing SAML IdP discovery mechanism)
  3. RP-A re-directs the user's browser to the IdP to authenticate via the AuthnRequest
  4. User authentications and the IdP sets authentication state cookies in the user's browser
  5. The IdP re-directs the user's browser back to RP-A passing the AuthnResponse
  6. User is not authenticated at RP-A
  7. User now loads RP-B which only supports OpenID
  8. User's browser has a stored cookie identifying the last OpenID used with RP-B
  9. RP-B invokes a check_immediate with the OP resolved via OpenID discovery (in this case the same IdP)
  10. The check_immediate re-directs the user's browser such that the IdP can validate the user's authenticated session
  11. The IdP now verifies that there is a previously established federation between the OpenID and SAML identifier
  12. If the federation exists, then the IdP can return the OpenID authenticated response
This would allow seamless SSO between different front-channel identity systems, though it is dependent on “identifier federation” at the IdP. However, if the IdP's are not the same, it should still be possible, but more complicated, as the user's identity would need to be federated across the involved IdP's.

Tags: Identity, OpenID, SAML, SSO, metasystem

No comments: