Steven started a discussion about Passport and its licensing. I think it reveals some frustration in the web development world that there is no widely available single sign-on solution for developpers to use on their web site.
I use a bunch of community sites, like slashdot, kuro5hin, shouldexist or gotmono, and register the same nickname on all of them and mostly the same passwords. But I still need to sign into them individually. Also, changing my password is really a pain.
Registering your personal data or profile information is also a problem, but it is really difficult to handle in a SSO system because of privacy and consent issues: which sites does you want to share each piece of information with?
Background
Kerberos
Kerberos is one of the key protocols when it comes to authentication over the network. It is mostly centralized, but supports multiple authentication suppliers, via the concept of realms.
The essence of the protocol and its justification are very well explained in "Designing an Authentication System: a Dialogue in Four Scenes".
Passport
You can find information about Passport by downloading the sdk from MSDN (search "passport sdk") and in this description and threat model of Passport.
Passport uses a model similar to Kerberos, where the authentication system establishs trust relationships (by exchanging keys offline, with the trusted parties) then generates encrypted authentication tokens. The tokens are encrypted with keys only known to the authentication system and the participating websites, and they contain a proof that the user was authentified by the authentication system within a certain time.
These tokens are implemented as cookies, so that they travel along with the requests to the participating website. The website accepts them for a limited time and then redirects the browser back to the authentication system for fresh cookies to be generated.
Passport has some limitations:
- 10000$ licensing fee,
- keys need to be distributed,
- cookies can be stolen/copied/replayed until they become too old,
- only one user can be logged at a given moment, you can't be logged in with Passport A at site X and Passport B at site Y,
- even though the user profile may be shared with the participating website, there is no guarantee that the data actually is shared, since it depends on the user's consent,
- tickets can expire in the middle of a multi-step process, which means that POST data may be lost because of a re-authentication,
- it is centralized and Microsoft owned, you can't have multiple authentication systems (say Microsoft and AOL) collaborate to appear like one larger authentication system (authenticate users from both realms to participating websites in both realms),
SSO Security
What would a minimalistic SSO system look like?
I think that a simplified Passport-like system could be a viable SSO solution for many community sites.
In order to keep the system simple and robust, only two interfaces would be provided: a web interface and a SOAP interface. The SOAP interface should be designed to support the authenticated use of webservices.
User IDs
As any SSO, some kind of identifier is needed. But as users can't possibly remember "0193BF00A6C31" as their username. Using both a large number and a username as identifiers makes it easy for the participating sites (the large number has a fixed length and no "weird" characters) and the username is easy for the user to remember. Both need to be unique within the SSO. Unlike in Passport, there is no reason for the username to be an email address: lots of users probably have multiple email addresses and have their main email address change every couple years (when changing job or ISP).
Registration data
No superfluous data should be collected from the user. If a participating site needs the user's birthdate, it can collect the information directly from the user. Although this means that the user still has to duplicate some of the registration effort accross sites, it will help the SSO stay minimal.
In order to make updates of this personal information manageable, the SSO will record a date for the last profile change. The web authentication interface can then offer a "My personal information recently changed" checkbox, that will update the profile timestamp. This will trigger participating websites to offer you to update your account information, when you access their website, because they can detect that the profile timestamp has changed.
The profile timestamp could also be a version number, instead of a date.
A personal email address would also be collected as part of the registration process, and would allow the user to regain access to his account by prooving he owns the email address, in case he forgets his password. This email address should only be used for account maintenance, but shouldn't be communicated to participating sites. Not collecting private information and not sharing the email address should avoid any privacy issues.
Any participatant that needs an extra level of security, to protect money or anything of significant value, will need to either avoid this SSO system or implement its own additional authentication for the parts of the site that require it.
Authentication tickets
Authentication tokens or tickets would only contain the unique user identifier along with timestamps.
Unlike in the Kerberos dialog, the IP of the client can't be used in the ticket, because proxies and firewalls are common practice on the web.
Whether the ticket should contain the user's nickname is open for debate:
- if it is shared, then changing it wouldn't be recommended, as your posts on forums would appear to have come from a different person,
- if it isn't shared, then each forums has to let you pick a nickname, but then there is no guarantee you'll be able to get the same nickname accross participating sites.
I think the first option is better, as most sites today don't allow you to change your nickname anyway.
Security
As mentioned above, this sytem isn't designed to protect valuable resources, it offers only a basic authentication with reasonnable security.
For example, you can get access to the account if you manage to intercept the emails sent when resetting the password. This could be improved a bit by allowing a user to disable this "authentication by email" feature for his account.
This is also why I didn't discuss having SSL required either on the authentication system or the participating site. But using SSL to protect the connections to the authentication system that involve the user's password would be a reasonnable addition to the authentication system.
Login options? force signin, time based freshness,... How can the partner implement a richer UX based on these login options?
Include the RU in the ticket. Have all incoming requests be signed by partner AND do RootURL check.
UX: use a popup instead of a redirect?
Further discussions
How to finance the SSO?
Migration stragegies
In:
Conflicting nicknames
Out:
Internal user IDs should be included from the start.
Extra flexibility
Multi-account
Multi-realm: architecture? trust? nickname conflicts (namespaces are required)
Federation: the network effect should help. Sites who join get some benefits and also benefit others automatically. The question is how to make this secure, easy to implement and easy to use?
Users don't care about a separate identity system, the model used should be more like Visa.
http://weblog.infoworld.com/udell/2003/04/02.html#a654
http://weblog.infoworld.com/udell/2003/02/02.html#a592
http://weblogs.asp.net/eporter/posts/35854.aspx
TypeKey
http://www.typekey.com/faq/
SimpleID
http://esigler.2nw.net/blog/2004/03/11/simpleid
Flickr
http://www.flickr.com/services/