views:

45

answers:

3

I'm trying to implement single sign-on for a web portal. I've written some code to send a POST request containing the user's login credentials to an external web app to log the user in. (Don't worry, this is all over SSL)

The HTTP response from the web app contains a cookie for the user's login. Is it possible for the web portal server to then pass that cookie to the user's browser? Or is that impossible since the web app is on a different subdomain? I understand there are some security measures built into cookies.

+1  A: 

There are indeed things like cross-domain policies build into modern browsers.
However once upon a time, I created a single login techlology for my own website.

There is a trick you can do. First, on the main site where the users have their
login information, have them a secret generated key. With this unique secret
key to every user, pass them to the other site like

www.abc.com/secret_key

from this secret key, your other website should be able to pull the needed information
like username, profile picture & stuff like that and should create the session on that
domain. So you would have the session created for the opposite domain.

If you still need to pass something back, I would recommend you to go a way that
incorporates RPC over PHP and post something back to your major domain.

This should solve your problems. If you want I can attach some example code.

Note: The security here is in the secret key. Since it's a unique generated key
for example, a md5 hash, it's hard to replicate this. So there is no such thing
like someone could reprocude the secret_key and then login to your site as someone
else.
You should also note that, the secret_key api should only be able to get the
needed information so that not too much information is gathered on the other side.

Herr Kaleun
The idea is to leave the code on the receiving end untouched, because it would be a lot of work to modify every app to accept a secret key.
Stewart
You can write 1 function, that retrieves user information from a database and creates a session. I think this is not too hard to implent :)
Herr Kaleun
A: 

Why invent the wheel? I think that you can find OpenID implementations for PHP. For the consumer and the provider.

You can restrict your OpenID-logins to your domains only if you don't want them to be used elsewhere.

Epeli
Sometimes inventing the wheel is easier then implenting it :D
Herr Kaleun
+1  A: 

Short answer: NO.

The HTTP server can indeed log into the other service and pass the service's cookie back to the user, but the browser will set that cookie's domain to be the HTTP server's, not the remote service's. There's no way for 'server A' on 'domain A' to make a cookie appear to have originated from 'server B' on 'domain B'. If it were possible, it'd be trivial to steal everyone's authentication cookies for their bank, facebook, myspace, etc...

Marc B
That's what I was afraid of. Thanks. I guess the one good thing is that if the applications are hosted on the same domain, it can be done. Correct?
Stewart
Sure. If the user's on www.example.com and you're logging into service.example.com, you just have to make sure the session cookies are set on the domain (example.com), and not restricted to subdomains (`service.example.com` or `.example.com`
Marc B