I'm developing a web application for a company that also has two other web applications. All are Java web server apps. They are all on different servers (each is load-balanced too, so each site is technically on diff. servers from itself too), with diff. IP's and diff. web addresses. They want me to find a way to allow a user to go to any ONE of the websites, log in, and be logged in to all three sites. So if they go to "someweb.com" and log in and then point their browser to "someotherweb.com", they'll already be logged in.
I have some experience with this. Here's one way to do it:
Assume Site A is the primary site and manages the login. Site B is a secondary site.
A user can go to Site A and click a link to go to Site B. Or the user can go to Site B directly.
If a user is on Site B and does something that requires authentication, Site B checks to see if the user is logged in locally. If the user is logged in, the user is allowed to proceed.
If the user is not logged in to Site B, the client browser is redirected to Site A. Site A checks to see if the user is logged in there, if so, a packet containing encrypted profile information is built and attached to a client-side redirect back to Site B. Site B reads and validates the packet and the user can continue.
If the user is not logged in on Site A, Site A displays a login page, authenticates the user, builds the encrypted profile packet, appends it to a client-side redirect back to site B, etc.
I've found that passing the data, encrypted, through the client to be sufficiently secure and solves an issue regarding session management. (Site A and B store the session ids in cookies which are not readable by the other site. So it's not possible to do server-to-server HTTP requests to an existing session on the other site.)
The key (no pun intended) is choosing a secure encryption algorithm and implementing it correctly including key management and rotation.
To make this more secure you can include a timestamp in the plaintext data to eliminate replay attacks (resubmitting the same encypted data in a later session.) Site B can validate the timestamp is less than, say, 1 minute old.
Also, you can hash the plaintext data and append the hash to the plaintext before encrypting. Site B can recalculate the hash to detect any tampering with or corruption of the data.
I hope you were able to follow that. Let me know if you have any questions.
Joined: Feb 25, 2003
Thanks! I'm going to read your suggestion more thoroughly and try it out. if I have any questions I'll post them here...well, i do have one:
You say a packet is "attached to a client-side redirect back to Site B". What exactly do you mean by "attached"? Do you mean it's posted to Site B? Put into the HTTP Header? put in a query string? Or something else?
Joined: Aug 24, 2005
I was referring to the query string. Depending on the amount of data you are sending, it should fit comfortably in the query string.