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

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.

开发者_Go百科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?

---

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.

---

Unfortunately, this kind of Single Sign On (SSO) approach is hard... Just about anything you do will require that you send some information between the domains that can then be misappropriated by a determined hacker to hijack a user's session. A quick search of the Google reveals a few articles around SSO. If you take a look at the StackExchange family of sites, you still have to log into each one individually, even if you're using OpenID or something of that sort.

There are a few presentations out and about on how to make this happen, but 9 times out of 10 it's simply not worth the trouble.

You can do this using Client variables stored in a database, and pass the CFID and Tokens around between the applications, but this is (again) a way that a nefarious user could intercept a valid user's request.