Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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...


share|improve this question
Please add some relevant detail about "domain" in this context, as well as appropriate tags to help us determine what system(s) you're talking about. – John Gardeniers Feb 8 '11 at 0:49
This doesn't sound like a Server Fault question. I'm not sure that it's a Stack Overflow question, though, either. You're talking about designing an authentication protocol and, frankly, looking for gratis advice on how to do that securely is probably a bad idea. – Evan Anderson Feb 8 '11 at 1:14

This is awfully abstract, so this will be an abstract answer.

You have two problems here. Authentication and Authorization, which are often abbreviated authn (authentication) and authz (authorization). Authentication is verifying the user is who they say they are, Authorization is allowing them to do stuff based on who they are. AuthN is first, followed by AuthZ.

Seeing as you're a registered user of ServerFault, you've already encountered one method to handle multiple domain AuthN with a single domain AuthZ. It's called OpenID, and is designed to solve the very problem you describe. Users authenticate with an OpenID provider (such as google or yahoo) and relying parties (ServerFault) accept the user as authenticated and provide authorization based on that. ServerFault isn't in the business of dealing with passwords.

The trick here is to separate authn from authz. If you can convince your environment to allow something like that, your job gets a lot easier. You can even use OpenID, since relying parties can restrict the providers they trust.

share|improve this answer

From the vagueness of the question, I can only venture a guess as to what technology is needed. I'd take a look at setting up an AD LDS database potentially along with AD FS (overviews linked). This will allow you to use LDAP for authorization and any number of authentication methods (including active directory or Kerberos- which you may already be using).

Clearly this answer is focused on a windows/microsoft development stack- since there isn't any OS tags is tought to know if it's appropriate.

share|improve this answer
This answer makes no sense at all - AD LDS and AD FS are systems for managing MS LDAP repositories - and the original question is asking about SSO over HTTP. "Clearly this answer is focused on a windows/microsoft development stack- since there isn't any OS tags" - are you saying Muicrosoft users are too stupid to ask questions correctly? – symcbean Feb 8 '11 at 11:21
SSO requires at it's core some repository of authentication and authorization. SSO doesn't have any specified method of presenting either so if you wanted to authenticate a user with their local logged in credentials, you've let windows handle the authentication piece and if you wanted your website to pass along the credentials to lookup membership in a LDS repository to determine authorization. – Jim B Feb 9 '11 at 16:24

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

eh? You mean you want to audit all data access? Or you just want to analyse usage? They are quite different - the former must be tightly coupled to authentication - but this comes at the cost of a lot of processing.

The architecture of the authentication system is what I'd expect from a first year CS student.

how do you authenticate across domains

There are lots of documents out there describing how to implement SSO for web sessions using cookies.

What you are suggesting leaves the system WIDE open for replay attacks and by my reading of it relies on all apps being fed the same cookies (implies that the apps are all on the same vhost, or you are trying to use third-party cookies - which is a very bad idea).

if the user visits and they look at the session cookie

So you're using third party cookies - not only is this a gaping security hole, it's not portable across all browsers - even specific browsers will vary by configuration.

(If you're trying to analyse/audit usage, why are you trying to create a SSO system?)

The surrogate identifier used for the session (usually the session cookie) must be a random value - there are some reasons for using reversible encryption, but its very easy to get this wrong and thereby expose your keys - and then your security is toast. And to avoid fixation problems these must be (re-)generated independently for each app at the time the session is authenticated and overwritten when the session terminates - that implies that your apps need to post back to some central repository when a session is (re)generated (NB I'm talking about a server to server message here - NOT via the client). The authentication server should send the status of the authentication to the app via the url query parameters along with a serial number for the operation - e.g. in a redirect (use a salted hash to authenticate the info - with the salt as a shared secret). Again the app should post back (server to server) that the user has authenticated and the serial number (to provide extra protection against replays) and check the authentication server is happy before releasing the new session identifier to the client.

The cookie should be HTTP only - and for preference flagged as SSL only. And it should be restricted to not just the canonical domain but also the path of the app.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.