How do you handle authentication across domains?
- by William Ratcliff
I'm trying to save users of our services from having to have multiple accounts/passwords. I'm in a large organization and there's one group that handles part of user authentication for users who are from outside the facility (primarily for administrative functions). They store a secure cookie to establish a session and communicate only via HTTPS via the browser. Sessions expire either through:
1) explicit logout of the user
2) Inactivity
3) Browser closes
My team is trying to write a web application to help users analyze data that they've taken (or are currently taking) while at our facility. We need to determine if a user is
1) authenticated
2) Some identifier for that user so we can store state for them (what analysis they are working on, etc.)
So, the problem is how do you authenticate across domains (the authentication server for the other application lives in a border region between public and private--we will live in the public region).
We have come up with some scenarios and I'd like advice about what is best practice, or if there is one we haven't considered.
Let's start with the case where the user is authenticated with the authentication server.
1) The authentication server leaves a public cookie in the browser with their primary key for a user. If this is deemed sensitive, they encrypt it on their server and we have the key to decrypt it on our server. When the user visits our site, we check for this public cookie. We extract the user_id and use a public api for the authentication server to request if the user is logged in. If they are, they send us a response with:
response={
userid :we can then map this to our own user ids. If necessary, we can request additional
information such as email-address/display name once (to notify them if long running jobs are done, or to share results with other people, like with google_docs).
account_is_active:Make sure that the account is still valid
session_is_active: Is their session still active? If we query this for a valid user,
this will have a side effect that we will reset the last_time_session_activated value and thus prolong their session with the authentication server
last_time_session_activated: let us know how much time they have left
ip_address_session_started_from:make sure the person at our site is coming from the same
ip as they started the session at
}
Given this response, we either accept them as authenticated and move on with our app, or redirect them to the login page for the authentication server (question: if we give an encrypted portion of the response (signed by us) with the page to redirect them to, do we open any gaping security holes in the authentication server)?
The flaw that we've found with this is that if the user visits evilsite.com and they look at the session cookie and send a query to the public api of the authentication server, they can keep the session alive and if our original user leaves the machine without logging out, then the next user will be able to access their session (this was possible before, but having the session alive eternally makes this worse).
2)
The authentication server redirects all requests made to our domain to us and we send responses back through them to the user. Essentially, they act as a proxy. The advantage of this is that we can handshake with the authentication server, so it's safe to be trusted with the email address/name of the user and they don't have to reenter it
So, if the user tries to go to: authentication_site/mysite_page1 they are redirected to mysite.
Which would you choose, or is there a better way? The goal is to minimize the "Yet Another Password/Yet another username" problem...
Thanks!!!!
