Single Sign On with multiple domains


#1

Hi, can anyone provide a way to do this with rails:

I have 3 sites on different domain names.

I want a unified sign on. so that, if your logged on from one site,
your automatically logged on another site, allowing seamless navigation
between different sites as a logged in user.

I understand with cookies, you can do this for subdomains. But what
about multiple different domains?

Thanks.


#2

a couple of options:
One:
You can always use a 3rd party cookie with the proper privacy statement
setup

Two:
Have cookie on each of your domains that looks for the “user cookie”
which
might the person’s username/id/whatever and some bit are used validate
the
state of the user. Then on each of your domains, your pages would look
for
the presence of this cookie, if it exists, pulls out the data and checks
against your “authentication server” - this can happen at whatever
frequency
you want (each page view or once per “session”). If all is well with
the
data, then the auth server sends a message back to your app that says
“yep,
I’m cool with this user” and you go on business as usual. If there’s a
problem then present the user with the log in form that ultimately
hammers
against your central auth server.

These are of course broad stroke options, the devil is in the details,
but
those details are pretty normal for most login situations/systems. The
only
“extra” is the process that checks for the “go / no go” on user
credentials
being kosher or not. Traditional methods bang against a local server,
in
the Auth server way, you’d still bang against a server, it just happens
not
to be local. What the response from the auth server is, is up to you
(that’s the cool part). Now, how to keep it “cracker” proof gets more
complicated…you’d likely only want to authenticate people coming from
your
own domains, so that will be something your Auth server needs to be
aware
of…and to keep up with “busta-busta-2000” you might want to keep a
unique
“key” on the requesting server passing along some hash and checked on
the
Auth server to make sure the “referring” server is actually yours (and
no,
I’m not referring to using a plain old MD5 hash - but some encryption,
where
each server has the “secret” salt).

hm, me thinks of a commercial opportunity here - alas foiled! Passport
has
beaten me to it - back to the drawing board for my riches.

or you might take a look at this to see if it will meet a need:
http://www.ja-sig.org/products/cas/

I’m not sure if there is a Ruby version of a CAS system out there.

hth,

JY


#3

Wow, i’ll have to absorb this one later.

I found this article regarding multi-domain single-signon with ruby
rails.
I’m kinda new, not sure if this will solve what I am looking for:

http://poocs.net/articles/2005/10/02/multi-domain-single-signon

Wonder how is 43things.com doing it with 43places.com with their unified
login.

Thanks!

Joe ManFoo wrote:

a couple of options:
One:
You can always use a 3rd party cookie with the proper privacy statement
setup

Two:
Have cookie on each of your domains that looks for the “user cookie”
which
might the person’s username/id/whatever and some bit are used validate
the
state of the user. Then on each of your domains, your pages would look
for
the presence of this cookie, if it exists, pulls out the data and checks
against your “authentication server” - this can happen at whatever
frequency
you want (each page view or once per “session”). If all is well with
the
data, then the auth server sends a message back to your app that says
“yep,
I’m cool with this user” and you go on business as usual. If there’s a
problem then present the user with the log in form that ultimately
hammers
against your central auth server.

These are of course broad stroke options, the devil is in the details,
but
those details are pretty normal for most login situations/systems. The
only
“extra” is the process that checks for the “go / no go” on user
credentials
being kosher or not. Traditional methods bang against a local server,
in
the Auth server way, you’d still bang against a server, it just happens
not
to be local. What the response from the auth server is, is up to you
(that’s the cool part). Now, how to keep it “cracker” proof gets more
complicated…you’d likely only want to authenticate people coming from
your
own domains, so that will be something your Auth server needs to be
aware
of…and to keep up with “busta-busta-2000” you might want to keep a
unique
“key” on the requesting server passing along some hash and checked on
the
Auth server to make sure the “referring” server is actually yours (and
no,
I’m not referring to using a plain old MD5 hash - but some encryption,
where
each server has the “secret” salt).

hm, me thinks of a commercial opportunity here - alas foiled! Passport
has
beaten me to it - back to the drawing board for my riches.

or you might take a look at this to see if it will meet a need:
http://www.ja-sig.org/products/cas/

I’m not sure if there is a Ruby version of a CAS system out there.

hth,

JY