Redirecting and transferring session data to another server / domain after logging in

Question

After some time searching and reading documents, I decided to ask you guys.

So the script is "simple":

The user goes to https://Domain1.com , enters his credentials, tries to log in.

After a successful login, depending on the type of user and other information from the database, Domain1 Server should redirect the user to another CF server at https://Domain2.com .

There are no problems using HTTP 301 and cfheader / cflocation so far. I am redirecting the user to a second computer, but he must repeat the procedure, which is unacceptable to our guide.

Is there a good and safe practice that is used to “transfer” the client along with the session data to another machine, or at least automatically log it with the same credentials?

How do you do this?

Answer 1

There are probably many ways to handle this. Here are a few options.

• A “corporate” way of dealing with this would be to use some kind of single sign-on system (SSO), such as Shibboleth, to process it. It is difficult, but very effective and safe.

• Before redirecting a user, you can generate a token that you store somewhere (server area, database), which indicates that the user is logged in. Then, when you redirect this user, send this token (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 find out if it is a valid token. If so, just register the user on the second site. Of course, you will need to do something to make sure that the token cannot be reused / played back.

• After the user logs into site 1, you can send a remote request (cfhttp) to site 2 to register the user. Then display a page (from site 1) that has an iframe downloaded from site 2 to set a session cookie for site 2. This is not so clean and will require you to display at least one page from site 1 before being redirected to site 2. I really Do not like this option and you suspect that it will be prone to errors and fragile.

As I said, other options are possible. Some may even be better (although I doubt it is better than option 1). I would choose option 1 if you have the resources available for this.

Answer 2

Unfortunately, this Single Sign On (SSO) approach is very difficult ... Almost everything you do will require you to send some information between domains, which can then be assigned by a specific hacker to capture a user session. A quick google search shows several articles on SSO. If you look at the StackExchange site collection, you still have to go into every single file, even if you use OpenID or something like that.

There are several presentations and about how to do this, but 9 times out of 10 it just is not worth the problem.

You can do this using Client variables stored in the database and pass CFIDs and tokens between applications, but this is (again) the way a vile user could intercept a valid user request.