a couple of options:
You can always use a 3rd party cookie with the proper privacy statement
Have cookie on each of your domains that looks for the “user cookie”
might the person’s username/id/whatever and some bit are used validate
state of the user. Then on each of your domains, your pages would look
the presence of this cookie, if it exists, pulls out the data and checks
against your “authentication server” - this can happen at whatever
you want (each page view or once per “session”). If all is well with
data, then the auth server sends a message back to your app that says
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
against your central auth server.
These are of course broad stroke options, the devil is in the details,
those details are pretty normal for most login situations/systems. The
“extra” is the process that checks for the “go / no go” on user
being kosher or not. Traditional methods bang against a local server,
the Auth server way, you’d still bang against a server, it just happens
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
own domains, so that will be something your Auth server needs to be
of…and to keep up with “busta-busta-2000” you might want to keep a
“key” on the requesting server passing along some hash and checked on
Auth server to make sure the “referring” server is actually yours (and
I’m not referring to using a plain old MD5 hash - but some encryption,
each server has the “secret” salt).
hm, me thinks of a commercial opportunity here - alas foiled! Passport
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:
I’m not sure if there is a Ruby version of a CAS system out there.