I have been thinking about how OpenID and OAuth could be used in a
federated single Sign On environment.
This is a scenario I am thinking through:
A User is a member of Site A - the master site. Site A wants to
provide services to the User by providing seamless access to a series
of Third party sites Sites B, C D and E.
Minimal information may need to be shared between the sub-sites.
I think that the OpenID spec allows for shared secrets. I wrote about
this here:
http://ekive.blogspot.com/2008/05/openid-and-single-sign-on-across-sites.html
Based on information I found on the OpenID.net wiki.
What I am thinking is that a user authenticates on Site A once and
Site A performs a behind the scenes handshake with the sub-sites when
a user first selects a service from the sub-site. The behind the scene
handshake is via OpenID.
In this federated approach it might even be that Site A generates it's
own OpenID for the user. eg. User....@siteA.domain
The master Site and Sub-site might also agree an OAuth transaction
that passes high-level profile information between the sites. eg. User
A is a member of these groups {group list,...}
The objective of all this is to allow a user to enter at any point in
the federated system and be checked that they are a valid member.
If the user is deactivated from the master Site A then the shared
secret handshake should fail and cause the user to be challenged to
login again.
I am still thinking through all the implications of this but wanted to
put it out to the community because it seems like an ideal scenario
that if addressed could make a great case for enterprise adoption of
OpenID and OAuth. Since it would not only allow lightweight internal
SSO but would also create a simplified method for federating SSO
between business partners.
Thoughts?