views:

277

answers:

3

Hi all,

I want to implement a discrete remote authentication server that handles login for many sites. Somewhat similar to OpenID.

Basically, I have site-1 and site-2 and they're both reliant on the same user database, which is on a separate auth-site. So, auth-site handles user authentication for them, and during this process, makes information on the authenticating user available to the requesting system.

Each site can be on a completely separate domain name, on completely separate machines.

This is all via HTTP(S), there can be no direct database access.

There's one last quirk: once an user has logged in to site-1, when accessing any other site reliant on auth-site, the site must treat the user as already authenticated.

This whole business must be entirely fuss-free to the end-user. It should work like a simple everyday login form.

As a concrete example, say we're talking about stackoverflow.com and serverfault.com, and they both authenticate via authentic-overflow-server-stack.com. Again, once logged in to either site, I can go to the other and do my business without logging in again.

What I'd like to know are the general interaction mechanism between the sites behind this scenario.

In my particular setup, I'm using Rails, but I'm not looking for code[1], just general best practice and guidance, so feel free to answer in pseudo-code or any generally readable language. OTOH, bear in mind that I'll have decent MVC, REST, and meta-programming in my toolkit.


[1]: unless you happen to know an existing tiny neat free MIT/BSD-licensed app/plugin/generator that handles this.

+1  A: 

It sounds like you want to actually use the OpenID protocol itself. There's no reason you can't restrict the authentication provider to only your own server, and do some shortcuts that make the authentication process transparent. Also, the OpenID protocol supports what you describe about logging into one implies logging in to all services.

Greg Hewgill
Yes, it does look like that, and I'd love to. But there's an existing user database, and a general client bias against relying on a third-party system. Also, these will be paid accounts, and while I don't it that matters technically, it does impact on the intenseness of client bias.
kch
This could have the added benefit that the users could use this to login to other OpenID aware websites.
Brad Gilbert
+2  A: 

It sounds like (especially with the emphasis on fuss-free), you want something like what the Wikimedia Foundation is doing. Basically, you log on to en.wikipedia.org, then that server communicates with other servers (e.g. en.wikinews.org) and gets authentication tokens. Finally, those tokens are embedded into images, e.g. http://en.wikinews.org/wiki/Special:AutoLogin?token=xxxxxxxxxxxxxxx , and when your browser visits that url (img src) it gets a authentication cookie for Wikinews. Of course, the source code is available for your reivew at http://www.mediawiki.org/wiki/Extension:CentralAuth .

OpenID is also a good choice, but it does require that the user "consciously" visit two domains. An example of one entity with two domains doing this is Canonical. E.g., if you go to https://help.ubuntu.com/community/UserPreferences they will redirect you to Launchpad (https://login.launchpad.net/+openid) for authentication.

Note that Wikipedia is doing this over http, but you can do it all https to ensure the img src tokens aren't intercepted.

Matthew Flaschen
+1  A: 

Looks like CAS is good enough for me, and has ruby implementations, along with dozens of other lesser languages, e.g. one that rhymes with femoral bone rage.

kch