| The last few days has got me thinking about single sign on again. I'd appreciate some feedback about all this. Here's an overview. Summary A simple scheme to provide distributed login and profile management. A typical use case might be a user logging in to a weblog or discussion site to leave comments. The user does this by referring the new site to their own home site where their login and profile is maintained. Explanation idp.com is an Identity Provider. It maintains a master copy of a profile. It provides authentication to service providers. It manages global login. It can distribute profile changes to service providers. sp.com is a Service Provider. It requests login authentication and profiles from idp.com. It receives profile updates from idp.com. It receives logout messages from idp.com It can tell idp.com to do a global logout. Any participating site should be able to take either role. Entry and function points idp.com - Remote login for sp.com. sp.com redirects to idp.com for a login page and authentication. On success the user is redirected back to sp.com - check Login. sp.com asks idp.com if user #23 is still logged in. No UI. - Get FOAF with UI. sp.com asks idp.com for a copy of a user's FOAF profile. The user gets some UI to authorise this. - Get FOAF auto. sp.com asks for a copy of user #23's FOAF profile to update a local account - Logout globally. The user at idp.com, or sp.com tells idp.com, that user#23 has requested a global logout. idp.com informs all SP's that have used remote login for #23 that the user is logged out. sp.com - Global logout. idp.com tells sp.com that #23 should be logged out - Account update. idp.com tells sp.com to fetch a new copy of a FOAF profile for #23 to refresh it's local details. Federation On the fly In some scenarios, all this is setup on the fly. idp.com knows nothing about sp.com until the first time the user requests a login or profile. The upside is that no prior approval is needed. The downside is that Mike Malware will game the system. We're beginning to see things like trackback spam, so this will happen. In theory, idp.com can maintain a blacklist of SP sites. Equally, sp.com can keep a blacklist of IDP sites. But this is auditing after the fact. Prior Approval idp.com and sp.com need to do a handshake before anything works. This has to have human involvement and approval. It's expected that big sites would form themselves into rings of trust like this. This in turn needs some admin function to maintain the ring. This is not black and white. There are blends where some functions are allowed on the fly, while others require prior approval. Discovery One of the problems I've hit with this as an API is working out the locations of the entry points. Almost all of it can be done on the fly with a very few named parameters. We can use things like Auto-discovery from home pages for some of it, or ask the user on the fly. But some of it looks like it needs to be pre-defined. Previously Josh had suggested there's only a few options. 1/ convention -- "everyone does this specifically at 'http://source.com/login.php'" 2/ registry -- "go to http://registry.com/foaf-login?site=source.com" 3/ discovery -- "go to http://source.com/meta?type=whereToLogin" to get the URL of where the user should login [which is just convention + a level of indirection]. 4/ use the user. :) ] The tricky entry points are - IPD.com : Check Login Status - IDP.com : Get FOAF Auto - IDP.com : Logout Globaly - SP.com : Global Logout - SP.com : Profile Update There's something interesting happening around sxip.com here. I don't yet know what. |
[ << Scott Stratten's Ryze success story - Applies equally to Ecademy ] [ Preserving content >> ]
[ 02-Aug-04 10:29am ]
