Centralized Authentication Services
In response to my editorial from yesterday regarding a centralized authentication framework, David Ellis, a regular contributor to our newsletter provides three authentication frameworks providing standardized trust capabilities.
David writes:
I’m aware of three major authentication frameworks that are trying to standardize exactly the problem you’re describing (allow trusted sources to provide for authentication).
OpenID http://openid.net/ – This one is a web framework for cross-domain authentication of users and is often the standard used by websites to let you log in with your Google/Facebook/etc accounts, but it allows anyone to run such an OpenID server that can provide authentication proof. It also has the advantage for end-users of cutting the website out of the password entry procedure, so you don’t have to worry about another Playstation Network fiasco if every site you visit used it and you use an OpenID provider that you trust (proper hashing and salting of passwords, strong password requirements without length restrictions, etc).
Shibboleth http://shibboleth.internet2.edu/ – This is also a web framework. It predates OpenID is used by many universities, and pioneered the mechanisms OpenID uses. The service is far more complex, though, allowing a hierarchical authentication organization rather than the flat structure of OpenID, and setting up and maintaining a Shibboleth server is supposedly far more difficult (I don’t know. I set up an OpenID one and it was easy, but I’ve never tried to set a Shibboleth one up.) I think this one will eventually die off.
OAuth http://oauth.net/ – Somewhat related to OpenID, OAuth is a more advanced authentication framework that allows desktop applications to participate, as well. It solves the problem in a slighly orthogonal way – resource sharing between two systems a single client uses. The user tries to use a particular service (website or application), tells it what service holds its resources (credentials and any other data that may be relevant), the first service asks for permission from the second, which asks the user if this is truly authorized, and then continues from there. On websites, this behaves very similarly to OpenID, but it’s a bit more complicated for desktop apps. It’s all done via HTTP, though, so the desktop app may just instantiate a browser window to do the authentication step.
Thanks, David, for sharing your knowledge with us all.
If you have further insights to share send them to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
All-At-Once Operations
Written by Itzik Ben-Gan with SolidQ
SQL supports a concept called all-at-onc… (read more)
Featured Script
Using SQL DML to Script HTML Markup
Use SQL DML to script HTML markup, such as, options for an HTML select box and or a comma delimited strings for use as a Java… (read more)