Authenticating (setting cookies) on 2 seperate domains

Question

I'd appreciate any thoughts/insight any of you might have on this...

I have two domains running the same applications e.g. mysite.com and mysite.org and I have a requirement that when a user logs into mysite.com then he should also be logged into mysite.org. Obviously, I can't set the cookie on another domain but I want to come up with a reasonable, secure solution. I think I have a solution (on paper), but I'd just like some feedback on how to improve & secure it.

My sessions table looks like this currently:

id: auto-incrementing; only used for by ActiveRecord
uuid: Universally Unique Identifier used for session lookup
user_id: the user this session belongs to
user_ip_address: the user's IP address
created_at: self-explanatory
updated_at: self-explanatory

My current logic for authenticating on one domain:

1. User tries to access mysite.com/some_protected_info; they are no authenticated so they are redirected to the login page (the referral URL is stored in a cookie)
2. User successfully authenticates on mysite.com; a session is created in the DB; a cookie for the mysite.com is created; user is redirected to the referral URL in the cookie i.e. mysite.com/some_protected_info.

My proposed logic for authenticating on two domains:

1. User tries to access mysite.com/some_protected_info; they are no authenticated so they are redirected to the login page (the referral URL is stored in a cookie)
2. User successfully authenticates on mysite.com; a session is created in the DB; a cookie for the mysite.com is created; user is then redirected to a mysite.org e.g. mysite.org/login/special
3. The login controller's special action looks up the session, sees that it's valid and sets the cookie on the mysite.org and redirects back to another controller action on mysite.com.
4. Given that the user is authenticated on mysite.com (and presumably mysite.org) the user will be redirected back the referral URL (mysite.com/some_protected_info).

Of note: - Both sites are using SSL. - Both sites are using the exact same code (mongrel instances) - the Apache config makes it accessible via different domains i.e. the config.action_controller.session settings on both domains are exactly the same.

Questions:

In (2) should I pass in the UUID via SSL or is that a security concern? Should I generate a new, random, temporary ID to lookup the session?

In (3) should I be passing the referral URL around (mysite.com/some_protected_info) or is it safe just to redirect back to the value of the cookie on mysite.com?

Any gotchas? Special situations that I'm overlooking?

Thank you in advance for your time & thoughts!

Answer 1

This is not a real answer but if you own the two domains you can set your cookies using cookies cross domain policy:

for example you can create a crossdomain.xml on yourdomain.com:

<?xml version="1.0" ?>
<cross-domain-policy>
  <allow-access-from domain="yourdomain.org" />
</cross-domain-policy>

Answer 2

A simple design for a sign-on system that works across domains depends on their being a single point for authentication that other domains can use to verify session information.

Typically the sign-in mechanism is an HTTPS protected page that is capable of verifying credentials and issuing a session ID that can be verified remotely. In practice one domain will forward the visitor to the sign-in page for authentication, then the sign-in process will redirect the visitor back to the original site with some kind of session-ID parameter passed along that can be assigned to a cookie by the original site.

For applications with only moderate security requirements, the session ID value can be encrypted or hashed using a "secret key" known to both the sign-in system and the other domains. This is used to prove that a user's session ID has been issued by the sign-in system and isn't just arbitrary. This is not unlike hashing a password with a salt for verification purposes.

While UUIDs may seem sufficiently unique, the generator may produce predictable numbers, or numbers with insufficient randomness. That is why sending a "signing" value is useful to preclude spoofing.

The idea you have seems fairly solid, but the details matter. It may be worth studying things like OpenID for how they handle session authentication via their protocol.