On Thursday 01 November I gave a brief talk titled “An Introduction to OpenID” at the monthly EdLUG meeting. The slides for the talk are available on Slideshare. It seemed to go well despite my fear of public speaking. A few questions were put to me; some of which I could answer.
The few I couldn’t answer were mainly regarding the specifics of the OpenID authentication process. Perhaps it was nerves, but in hindsight I realise I knew the answer all along. I was asked if OpenID could tie into Kerberos or PAM. This is really down to how one chooses to implement the standard.
The OpenID specifications state that at at some point authentication must be performed with the Identity Provider. However, the details of how this authentication must be performed are purposefully not specified and instead left up to the implementor. So in answer to the questions, yes you can use Kerberos or PAM in the authentication process, but it’s up to you to tie it all together. In fact, traditional username/password combinations need not be used. If one so chooses secure fobs or biometrics could indeed be used; it’s up to you!
You may already have an OpenID from one of the many providers, for example username.myopenid.com. Wouldn’t it be nice if you could use your own domain name instead? Well you can! You may not actually host an identity provider capable of vouching for your ownership of your own domain, but you can always get username.myopenid.com to vouch for you.
This process is called delegation. You use your own domain name as your OpenID, but add some extra markup to the head element of your homepage that tells the relying party that you are delegating the responsibility of authentication to another server. The markup you need is:
This will tell the relying party, that it should instead visit username.myopenid.com. You will then authenticate to this delegate server. Once successful, by implication of having authenticated to the delegate server, you have also proved that you own the domain from which you were directed.
The link tags are used for OpenID 1.x server discovery, and the meta tag for OpenID 2.x server discover. In order to be as compatible with OpenID consumers as possible, you should use both link and meta elements.
We sign up to more and more services online every day. This often involves remembering multiple, often similar (in the case of username1984, user_name_84 etc) usernames and passwords. A solution to this is so called single-sign on, whereby you use only a single identity such as a Microsoft Passport or a Yahoo! username. The problem with this solution is that you can find yourself tied in to one large company’s services.
If you already have a Microsoft Passport, you are unlikely to want to create a Yahoo! account to use their services as this would involve going through a sign up process, replicating friends lists and so on from one provider to the other etc. Besides, I don’t know about anyone else but I don’t like the idea of some large company controlling my identity: storing my username; hashed password and other details. It would be better if I could arbitrarily choose who controlled my identity, or even better, control it myself. This is where OpenID comes in. [Read more]
