Was just presented with a unique (to me) requirement which is to implement a single sign on across multiple domains within the same page via a cookie. Huh? Let me elaborate, in simple terms it means that there is a base site, lets call it foo.com, and then there is a partner site, lets call it bar.com. On foo.com’s main page we want to be able to iFrame in bar.com with the credentials of the current user logged in to foo.com transparently sent over and in turn logged in to bar.com as well.
In order to achieve this, the first thing that needs to happen is the two sites need to have a sub domain in common. The easiest way to accomplish this is to set up an alias on the parent site (foo.com) to bar.com. The alias would be something like bar.foo.com which points to bar.com. This is required because if they do not have a domain in common there is no way for them to share cookies.
The next thing that needs to
happen is both sites have to agree on a way of authenticating a
user. In our case we used a cookie that consisted of the user id
followed by a hash of the user id which looked something like
12345,jfk83jf835jfiie43.
Your probably wondering how this simple cookie can facility a single sign on across two different sites? Let me explain, first lets talk about the how the values of the cookie are generated. The first value, namely, the user id, is self explanatory. The second part of the cookie, the hash, has a little bit more to it. In order to effectively use the hash, the two sites need to have a “shared secret” aka “The Salt” that only they know.
In order to generate the hash, you append the salt to the user id, and then run it through a one way hashing function. The result is a unique key that can only be generated by the two parties who know the salt (or generated by anyone who knows the salt, so make sure the salt stays very secure). Since it is a one way function, it would be very difficult for someone to reverse engineer it.
Now that we have the id and the hash explained, lets talk about how bar.com can use this to authenticate the user. When a user on Foo.com first logs in, the shared cookie is created by foo.com, and when they hit a page in the iFrame which is pointing to bar.com, bar.com checks the cookie. If it is there, it has the user id and hash of the remote user.
Step one for bar.com is to take the user id, hash it (based on the agreed upon salt), and first verify that it matches the hash that is supplied as the second part of the cookie. If it matches, it is safe for bar.com to assume the user id in the cookie is the user id of the remote user, thus bar.com can log the user in.
This method is not the most secure method of doing a single sign on as a hacker can easily do a man in the middle attack and thus obtain the cookie, and hash, and then with the user id and hash in hand, can easily log in to bar.com as the remote user.
There are a few precautions you can take if you choose to use this method like adding values to the salt like, date, time, request id, that would make the request unique not only to a user, but to a specific time of day or a specific request. Another approach you can take to make this more secure is to simply use SSL across the wire.
Keep in mind we used this method as a simple way of verifying user identity, we were not concerned with either site getting hacked as we had other security mechanisms in place.
So, please take this approach with a grain of salt.