AOL supports simple federation with SAMLv2

In addition to the work AOL is doing to support OpenID, we've also been working with SAMLv2 to provide a simple federation profile for our partners. This allows users to federate an account at a partner to an account at AOL so that SSO is enabled from the partner to AOL or vise-versa.

This implementation uses the “SAMLv2 Lightweight Web Browser SSO Profile” and “SAMLv2.0 HTTP POST SimpleSign Binding”. Since the current use cases are fairly restricted we simplified the process even more such that only source-first SSO, using an unsolicited <Response> message is supported.

The actual federation of identifiers is done during the registration process using existing AOL protocols. SAML is then used for the SSO Assertion between the partners. The flow goes something like this...

1. User goes to browser and loads site A
2. User authenticates at site A using the account credentials associated with site A
3. User clicks on link to partner site B
4. Site A generates the SSO Assertion for site B using site B's pre-determined federation identifier
5. Site A uses the http POST method to post the SSO Assertion to site B
6. Site B validates and verifies the SSO Assertion
7. User is “signed-on” to site B with site B's federated identifier

Using the Simple-Sign binding significantly simplified the development effort as XMLDSIG is one of the more complicated parts of SAML. As more tools for XMLDSIG become available this will be less and less of a barrier to adoption.

Tags: SAML, AOL, SSO

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

Do we really want SSO?

With the recent flurry of announcements around OpenID the same SSO issues are once again being raised. Kevin Farham documents some of these in his piece on OpenID. Kevin's friend's issues are not around OpenID but rather the whole concept of Single-Sign-On (SSO).

This begs the question, "Do users really want SSO?" Unfortunately, the perception might be scarier than the reality.

"You mean, if someone knows my password they can access all my web sites?"

Well... yes and no (depending on the implementation). However, the reality is that many users have the same password at all/most their sites and so the "hacker" can already get access to all their sites without SSO.

With a good Identity Provider (IdP) and strong authentication, the user should be more secure even though a single authentication event allows access to many sites. In fact, for many users, they expect this within a "proprietary" or "closed" environment ( AOL, Google, Yahoo, MSN, etc). It's extending this SSO concept beyond the "proprietary" environment that "scares" them.

Of course part of the issue is that this kind of "cross-domain" SSO doesn't really exist in the general consumer space. The unknown always breads fear; it's human nature. To overcome this "fear", we need SSO to be common place (known not unknown), and show how SSO is "just-as-secure" as the "money under the mattress" solution.

Tags: SSO, Identity, OpenID