OpenID != SSO
OpenID is not “Single Sign On” (as most people interpret the phrase) despite what wikipedia may say.
To illustrate: A friend of mine recently twittered, asking about using OpenID as a single-sign-on solution to a collection of non-profit websites he’s building:
OpenID evangelists: convince me it’s a no-brainer to create single sign on for my distributed non-profit. One requirement is free accounts
He’s looking for a way to allow his users to log in one site and then use many other sites without having to log in again. That’s what most people think of when you say “single sign on.”
With OpenID, “SSO” has become ambiguous (to me at least). It has taken on a new meaning, in addition to the old: SSO as “Single Action Sign On” vs. SSO as “Single Set of Credentials Sign-On”
In enterprise-y projects, “SSO” usually means that you can log into your expense tracking system and automagically you’re logged into the CRM system as well. This is the traditional use of “SSO” as “single-action sign on.”
In webapps, this trick is done through a variety of means, usually something like setting a cookie header with a shared domain name (cookie sent from a sub-domain, sets the cookie on the domain). Ex: HTTP response from expenses.mydomain.com sets an authentication cookie on mydomain.com, and now when I visit crm.mydomain.com, this auth cookie goes with the request and crm.mydomain.com knows I’m logged in.
Because your OpenID url may be anything, there is no shared domain through which authentication cookies may pass. Because of this, OpenID can’t help you log in to multiple sites with a single authentication request. OpenID is more like single-set-of-credentials-to-log-in. Just because I’m logged into LiveJournal does not mean that blogspot.com already knows I’m logged in. I still have to give my username (here, a URL for my OpenID, rather than a simple username like ‘banksean’). I may not have to enter my password again, but I do have to enter my ID. This isn’t exactly what most people think of when they hear “Single Sign On”
To recap:
- SSO (as commonly understood): I can log with my username and password at one site and access others without logging in again during a session (single-action-sign-on)
- OpenID: I can log in with my username (OpenID URL) and password at one site and only have to enter my username (no password) to access other sites (single-set-of-credentials-sign-on)
That’s a gross oversimplification (for example, you may choose to only allow the relying party to authenticate this one request and not future requests, in which case you’ll be asked to authenticate with your password again during the same session.)
I wonder how one could turn OpenID into a Single-Action Sign On protocol and how that would work.
Related: Yay! because OpenID support on Blogger has graduated from draft.
“I wonder how one could turn OpenID into a Single-Action Sign On protocol and how that would work.”
Top-of-my-head: Use an iframe to load an openID sign-on form on your own site. Once you’ve logged into openID, the openID server A) sets a cookie and B) sends your site a message saying “banksean is logged in.” Server-to-server xmlrpc or something like that. Then your site sets a cookie.
Now, with the iframe, I’m guessing that the openID server gets to check whether it has previously set a cookie when the iframe gets loaded. So on the second visit, you’re loading the iframe, the openID server says “Oh, we’ve already set a cookie for banksean, no need to trouble him to sign in” and it sends a message to your site saying “banksean is logged in.”
Adam Rice
14 Dec 07 at 6:48 pm
Yes that may work for a *particular* OpenID provider (I believe that’s actually how some existing non-distributed SSO systems work), but which one? There are potentially an infinite number of URLs from which you would have to load such an iframe.
Perhaps there could be a “meta-provider” that checks a bunch of different providers from a single iframe source, but that seems awfully inefficient (and wouldn’t scale past a couple of providers).
banksean
14 Dec 07 at 7:01 pm
Yeah, that’s a problem. Although what you describe is pretty much how DNS works, right?
Adam Rice
14 Dec 07 at 7:27 pm
Hi Sean,
We’ve been working on this precise problem and have created a piece of technology that allows people to do exactly what’s being described in the comments - use either a generated or their own OpenID as a SSO across multiple-sites without constantly re-entering it.
If you’re able to then I’d be very interested in speaking with your friend who runs the charity sites you were recommending as we are looking for sites who are interested in beta-testing the OpenID SSO we have developed - peter (at) clickpass dot com.
http://petenixey.myopenid.com/
15 Dec 07 at 1:35 am
Interesting question. I’d like to hear comments from some OpenID experts on this topic.
I think “Single-Action Sign On” may be faked quite easily, though not very elegant and with an initial registration step, by relying parties. Suppose your site saves two cookies when a user first joins: first a session cookie that expires on closing the browser or after some time; second an “OpenID cookie” that permanently saves the user’s OpenID. Now, when a user comes back after some days and is not logged in (i.e. the session cookie expired) at your site you look at the OpenID cookie and start the authentication process without asking the user. If the user is logged in into his or her OpenID provider, the process remains transparent.
Another problem is to think of is a “single-sign-out” as an OpenID provider may not delete or invalidate other sites’ session cookies.
I’m not familiar with other SSO techniques but isn’t Kerberos something that offers such a service? Is a combination of OpenID and Kerberos possible/useful?
Fabian
15 Dec 07 at 11:03 am
There’s just no way to implement single-action SSO without some sort of shared datastore. As was mentioned in the article, this works fine within organizations because services all exist within the same domain, so they can pass cookies between each other. On the Internet, this isn’t allowed for security reasons.
As a hypothetical workaround, somebody could create a browser plugin that reports the current user’s OpenID to the website to the relying party, at which point the relying party would automatically start the login process.
The problem here is that OpenID is designed, by necessity, to work in an untrusted environment. Most providers will ask for permission before replying to an authentication request (and rightfully so), even if the user is logged in. It would be very disconcerting for a user to get this message without some sort of action to begin the login process. They’d also need an opportunity to examine the site first so they know whether they want to trust it.
Beyond this, there’s no guarantee that a user *wants* to be logged in to all sites simultaneously. An important characteristic about OpenID is that users are not necessarily tied to a single identifier. For example, a user might want to log into their bank with an ID containing their real name, but log onto an online forum under an a pseudonym. Single-action SSO doesn’t leave room to ask users which ID they want to use.
@Fabian: Kerberos does offer SSO, but isn’t really compatible with OpenID. The reason it’s able to provide SSO is because all applications have access to the user’s Kerberos session (via an API), so the user’s Kerberos client is just acting as a global datastore anyway.
tjohns
15 Dec 07 at 11:37 am
I think tjohns mentions the key point here: browser intergration. OpenID probably isn’t designed for “single-sign-in-action”. But the end user experience will massively improve when browsers will start to auto-discover OpenID logins. Additionally a user might create whitelists (which are already pretty common to have for cookies) that say “always use xyz.myopenid.com for site foobar.org”. Then the browser could send a standardized cookie or an HTTP-Header with each request to foobar.org and the RP may begin with the authentication procedure.
Fabian
15 Dec 07 at 12:03 pm
@tjohns: good point that the user may not *want* to be logged into other sites automatically. In fact this could be easily abused if it was implemented. A site could grab your OpenID automatically (without your expressed consent), which is obviously a privacy problem.
Having a browser-maintained whitelist, or at least having the relying party set a cookie to remember the last OpenID used both sound like good ideas.
banksean
15 Dec 07 at 2:14 pm
One nice feature is that, with OpenID, websites can pretty much indefinitely track your identity (explicitly not tracking your “signed-in” status). This way you can still sign in and out using “SSO”, and once you’ve IDd yourself to any particular site it will respect your privs. This adds a very small once-per-site burden while thereafter providing all of the traditional SSO benefits.
Richard
18 Feb 08 at 5:14 pm
I have been reading up about OpenID and SSO.
There is an interesting page posted at: http://wiki.openid.net//Introduction
Read down through the page to the “Don’t Procrastinate… Associate!” section. If you read through the section to the last paragraph it seems to define an OpenID handshake that allows us to achieve SSO.
If I am reading it right the protocol could use a Diffie-Hellman protected shared secret that can be used behind the scenes to determine if an id is still valid. Presumably if an account had been deactivate the shared secret would be invalid which would force a re-authentication.
Can someone with more detailed OpenID knowledge confirm or correct my thinking.
Mark Scrimshire
20 May 08 at 1:01 pm
I’m pretty sure you can combine kerberos with openid to make your own kerberos-backed openid provider.
Most browsers, (IE, Safari, and Firefox) support the HTTP Auth Negotiate extension allowing authentication via kerberos over HTTP. What you do is you setup your own openid provider, and give it a kerberos HTTP service principal. You then associate your openid url that uses said provider with whatever websites you want to login easily to.
When you go to login to the site, openid will redirect you to the openid provider you setup, which will then authenticate automatically via HTTP Negotiate. You will then be redirected back and logged in!
To enable HTTP Negotiate for your openid provider in Firefox, you have to add the url to the network.negotiate-auth.trusted-uris option in about:config
Tim Olsen
16 Jun 08 at 1:53 pm
The Kerb/OpenID combination is not practical for Internet use. If your intent is to have the Authentication Provider use Kerberos SSO in order to avoid the credential prompt, that would require the user’s machine and the authentication provider have access to a common Kerberos KDC (key distribution center). In Windows-land, this would typically entail having the user’s and the authentication computers “joined” to a particular Kerberos realm (domain) in order that the user’s browser be able to get a service ticket. There are two problems with this: 1) companies typically block Kerberos traffic at their firewalls and 2) Kerberos (esp. Microsoft style) requires that a bunch of service records be provided by DNS; this is not typically done for public addresses.
A more workable idea would be to combine Microsoft ADFS (Active Directory Federation Services) with OpenID. ADFS has some of the same objectives as OpenID, but is much more painful to setup.
Manny Vellon
24 Nov 08 at 10:21 am