If there is one thing I hate it is creating a user account a just about every web site I go to these days. "Registration is Free" just pick a username, password, and enter your email address. I understand the reasoning behind forcing users to register. How else are you going to send out marketing emails and track how users browse your site. I'm not saying that registration should end, but there should be an easier way.
What I propose is the barest minimum implementation of something like Microsoft Passport Service. Create a web service whose sole purposes to handle one piece of app security, Authentication.
We all know that Authentication and Authorization are two key elements to any security model. Authentication: are you who you say you are? Typically handled through the use of username and password combinations. Authorization: are you allowed to perform the requested action? Handled very differently depending on which site you visit. I propose that Authentication can be handled without any specific information related to the application and can be completely abstracted.
Picture a web service with these methods:
Guid NewUser( string Username, string Password, string Email); // Verify uniqueness of Username, Email generate new GUID
Guid Login( string Username, string Password );
These two methods are about as simple as Centralized Authentication can get. Now picture plugging this Architecture into your web application. Developers setup the new user registration forms, capture a username, password, email at a bare minimum. The NewUser web method is called, it returns a GUID which the site developer can then use in their user database. Subsequent visits to the site prompt surfers for their username and password, call the Login web method, obtain the GUID then use that to determine the authorization the user has.
For the developer, it's just a matter of consuming the web service. The developer would be writing these very same methods in their own security implemention, .Net IDE makes it a breeze to use a web service instead. For users of your website, they will be singing your praise that your site participates in the Centralized Authentication Service, because they now only need to remember a single username and password.
This example is very simplistic but a working implementation does not need to be much more complicated. Issues that would need to be addressed are:
- Password resets: my thoughts are you would have to use an email confirmation of some sort and a password reset would be initiated by entering an email address
- Encryption/Security: use ws-security extension, SSL, salted-hashes, etc.
- Availability of Central Authenticator: This is the kicker, high availability network, clustering, redundant failover
- Trust: Trust of the Central Authenticator would have to be assured but I don't see this as insurmountable. Agencies like Verisign, GeoTrust, could inspect/certifiy the Central Authenticator
- New Account Creation Abuse: use an email confirmation that must be processed by the new user withing 24 hours or the account is deleted
- Account Expiration: Expire unused accounts after 90 days? If you don't login to any website in three months, you don't need an account.
I'm sure the list could grow but the whole point is to keep the process as simple as possible to help promote acceptance from site developers. I plan on putting together a working prototype sometime in the near future and posting some code.
The theory might not pan out (or everything I said is probably been done 100 times already :) but I wanted to put it down on paper.
posted @ Thursday, January 27, 2005 10:45 AM