Cross-domain cookie synchronisation

M

Martin Doyle

Hi all, I hope someone can help as I have a rather tricky problem that
I hope someone will be able to help with.

Short Question:

How do I synchronise cookies across domains? I don't have any problem
with creating them on the separate domains, the problem is
updating/deleting existing ones when a new one is created.

Long Question:

BACKGROUND:
I have an authentication system which, at login and performed using
lookups against a database, creates an encrypted session cookie
containing a list of all the websites that that user is allowed to
use. The cookie expires either at midnight or - as it's a session
cookie - when the browser is closed. When users want to view a secured
page, a filter that runs only against those protected pages checks
that they have a valid cookie, else it redirects them to the login
page for that webapp. The data inside the cookie is Base 64 encoded
and then DES encrypted, so it is comparatively secure (and certainly
secure enough for our usage, where every individual transaction is
further authenticated real-time against the database). The benefits of
doing this, rather than constant database hits to authenticate each
time, are that the speed is far greater and that it reduces the load
on the database server. To do this using session variables is not
viable, as we use load balancing without session propagation and so
our entire application is stateless, meaning they can hit whichever
server they require without losing session information if going to a
different one with every request.

CURRENT PROCESS:
This cookie mechanism offers us a wonderful single sign-on across
webapps within the same domain, as all webapps can see the domain
cookie within which is a list of all the allowed roles for that user,
meaning once they've signed in once they can use any other app on that
domain. The problem occurs when we want to use that same cookie across
different domains' webapps. There is a list within that cookie already
of all the webapps they can use, including those on other domains, but
quite obviously those other domains cannot see this cookie.

SUGGESTED ALTERNATIVE:
When the user clicks on a link into the middle of a protected area of
a different domain's webapp, the following process would occur; The
first thing that would happen is the checking of a current login
cookie for that user. When that is not found, instead of immediately
redirecting to login as happens currently, the referrer would be
checked and if it's from one of "our" domains, we would initiate a
cross-domain cookie transfer mechanism. Initially you would be
redirected as a GET request back to the CookieMigrationServlet on the
referring domain with the originally requested URL as a parameter.
That servlet would then attempt to pick up the login cookie and send
its (still encrypted) data along with the original redirect URL as
POST parameters to the CookieMigration servlet on the originally
requested domain (still with me?). This servlet would now create a new
login cookie on that domain and then redirect back to the original
URL. This would now either pass the login-cookie check (if there was a
valid one on the referring domain) or go to the login page (as the
referrer is now the same domain so the process won't start again).

THE PROBLEM:
The problem is not with the above solution (although it still remains
theoretical and not tested in practice), but rather what happens when
a second user logs in. Say Fred logged into Site 1 and then hopped
across to Site 2 in a new window. Fred now closes down the Site 2
window and walks away. John now logs into Site 1 from the same
original window. However, when he clicks on a link to go into the
middle of Site 2, he still has Fred's cookie active and logs in with
the wrong account.

THE HIGH-LEVEL SOLUTION:
Either the cookies on the separate domains must be deleted or
overwritten when the new person logs in. This should happen either all
at once, or just-in-time like the migration.

THE QUESTION:
How do I solve the problem? All help greatly appreciated, as we had a
dozen people (half of whom were developers) sat in a room yesterday
for an hour unable to come up with a solution that didn't involve the
database, which it not particularly desirable. We also don't really
want to check all domains for cookies every single time someone logs
in, as the hit would be too large. Changing the current process
dramatically to use a entirely different single-sign-on approach is
also very undesirable, due to the cost in development time and impact
upon changing all the sites to any new process.


Thanks in advance,

Martin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,014
Latest member
BiancaFix3

Latest Threads

Top