Redirection and session data transfer to another server/domain after login

Question

After some time of searching and reading docs I've decided to ask you guys.

So, scenario is "simple":

User goes to https://Domain1.com, enters his credentials, tries to login.

After successful login, based on user type and other info from DB, Domain1 server should redirect user to another CF server at https://Domain2.com.

So far, no problem, using HTTP 301 and cfheader/cflocation I'm redirecting user to second machine, BUT he has to repeatlogin procedure which is unacceptable by our management.

Is there any good and secure practice which is used to "transfer" client together with session data to another machine or at least automatically log him in with same credentials?

How you'd do it?

Answer 1

There are probably many ways you could handle this. Here are some possible options.

1. The "enterprise" way of handling this would be to use some sort of a single sign-on(SSO) implementation, like Shibboleth, to handle it. This is complicated, but very effective and secure.

2. Before you redirect the user you could generate a token that you store somewhere (server scope, DB) that indicates that the user is logged on. Then when you redirect that user, send that token along (http://domain2.com/HGF394JFJk58fjJ). When the second server receives the request if it sees that a token is present it can send a remote request (cfhttp) back to the first server to findout if that is a valid token. If it is, simply log the user into the second site. Of course you would have to do things to make sure that a token could not be reused/replayed.

3. After the user logs into site 1 you could send a remote request (cfhttp) to site 2 to log the user in. Then on display a page (from site 1) that has an iframe loaded from site 2 to set the session cookies for site 2. This is not as clean and would require you to display at least one page from site 1 before redirecting to site 2. I really don't like this option and suspect it would be error prone and fragile.

Like I said, there are probably other options. Some might even be better (though I doubt better than option 1). I would choose option 1 if you have the resources available to do it.