I’ve been thinking about OpenID a lot lately. Probably since around October of 2009. On my current engagement, my customer uses OpenID to enable Single Signon (SSO) for their partner applications. There is an implicit trust between them because of their business relationship, so they include links to their partners’ applications from their own applications as a convenience. The problem (before OpenID) was that each time their users accessed their partner’s application through one of these links the user was forced to sign in. A SSO solution was necessary, and OpenID was the solution. Through OpenID, my customer’s application acts as the OpenID provider (OP) and the partner applications are the relying parties (RPs). It works like a dream.
Now, I didn’t architect the OpenID solution. My colleague Oscar Pearce did, and did a great job of implementing it. He has since moved on to other things, and in October 2009 my customer asked me to help another one of their partners to OpenID-enable their application. My journey into OpenID land thus began.
At first I didn’t really understand OpenID (and to be honest, didn’t really like it). But it began to grow on me as I began to get what it was all about (funny how that happens). Slowly it started to gel, and I realized there are two main pieces to understand when using OpenID in this type of architecture (i.e., as a SSO solution):
- The Relying Party (RP) code and surrounding issues
- How to write the OpenID Server for the OpenID Provider (OP)
I love to write. It’s what I do. So I began thinking of ways to share this knowledge with the IT community. I pitched the idea to Jenni Aloi at IBM Developer Works, she liked it, and Part I (the RP stuff) is now available for your reading pleasure. You can find the article here.
I’m working on Part II (the OP stuff) now. Stay tuned. And please let me know what you think. I really like OpenID. It’s gaining momentum as an identity management solution. Check out My OpenID to see one of the largest OPs on the planet, or OpenID.net for the specs, etc.