Cookie based SSO

Question

How can I implement a cookie based single sign on without a sso server? I would to share the user logged in across multiple applications using only a cookie on the browser.

In my mind it's working like this:

• user logs in an application
• the application verifies the credentials and then it setting up a cookie on the browser storing the username (that could be coded with a private key)
• if the user opens another application, it searches the cookie and reads the username on the value (using the key for decode the string)

In this solution a user may see the browser cookie (of a another user) and take the string codified of the username. Then he could adding it on an own cookie (no good!).

There's some secure way to do this? With a timestamp based control or something like this?

Thanks in advance.

Bye

P.S. I know that my english isn't very well.. sorry for this!

Answer 1

This is impossible. Cookies are unique to each domain, and one domain cannot read another domain's cookies.

Answer 2

You can access cookies across subdomains, but I do not think using browser cookies is a great solution. You really don't need a "SSO server" to implement a single sign-on. It is fairly easy to come up with a payload that both applications recognize. I have seen custom SSO solutions that transmit the payload using XML over HTTPS.

Answer 3

Here is a solution (which will hopefully get heavily scrutinized by security gurus on here):

Have each domain store user data in a similar cookie, and when a user want to jump from one domain to another without authenticating themselves on the new domain, provide a "jumplink" with an encrypted token in the query string. The new domain would decrypt the cookie, and figure out who the user is, then issue them a new cookie for that domain. You would want the "jumplink" to have a very short expiration date, so I would not generate them right into the page, but generate links to a "jumplink" generator and re-director.

This might not be necessary, but the receiving page for the "jumplink" could make a web service call back to the originating domain, to verify the authenticity of the encrypted token and the whether it's expired.

I think this solution would be susceptible to man-in-the-middle attacks (not sure if it would be more so than other auth mechanisms which are currently popular), but you could incorporate a client MAC address and IP address into the encrypted token for extra security.

Answer 4

I have done something similar. There is a PHP application where the user logs in, the system contact a web service and then the service checks the user's credentials on the Active Directory. When the user is authenticated, his PHP session is stored in the DB. Another web application can read the PHP session from the cookies and uery a web service in the PHP applicaiton, the PHP application check the session in the database and return the user id. In this way I have a SSO using SOA.

Do not rely on the user id stored in the browser, is a security error, at least encrypt the id.

The best solution would be to put the login form and session storage in the same application, then this application can provide services to other applications.

And use HTTPS for the kind of infomation exchange.

The cookies can be read only if the belongs to the same domain, for instance:

intranet.example.com crm.example.com example.com/erp

Answer 5

There is a simple solution without using an sso server, but not with 1 common cookie, as we know that cookie's are not shared between domains.

When the user authenticates on site-a.com, you set a cookie on site-a.com domain. Then on site-b.com, you link a dynamic javascript from site-a.com, generated by server side script (php, etc) who has access to the created cookie, and then copy the same cookie on site-b.com on the client-side using js. Now both sites have the same cookie, without the need of asking the user to re-login.

You may encrypt/encode the cookie value using a method that both site-a and site-b knows how to decode, so that site-b will be able to validate his cookie copy. Use a common shared secret that without it will be impossible to encode or decode.

You see that on the 1st page load of site-b.com, the cookie is not present, therefore if you see necessary, you may want to do a page reload after setting the cookie.