Authentication between multiple systems/platforms within the same web application context

Question

Consider the following scenario: Web application is using two separate systems (they can share data/state through DB). First one is used for processing standard web stuff like HTTP requests/responses, HTML content, forms and all things related. Second is used for real-time communication like sending messages and notifications (long poll or WebSocket server).

User can be authenticated through the first system/platform and if the credentials are valid, some web page is sent back to the client. Once this page is loaded, client should be connected with the second system/platform transparently in the background.

The question is: how to authenticate user on a web page/application which consists of multiple systems/platforms on the back-end?

I can imagine it this way:

1. When user is authenticated through the first system/platform, GUID token is generated and stored in a database bound to some user. This token and user ID is also sent in a response back to the client and, for example, rendered on the page in hidden fields.
2. When the page is loaded and connection with the second system/platform is taking place, token and user ID from hidden fields are retrieved and sent as parameters with connection request. Back-end finds user, compares his token in the database and if they match real-time connection could be initiated.

I understand that this approach is vulnerable to sniffing for example, but I'm namely interested in the authentication procedure between two separated systems/platforms.

Answer 1

• Generate a session token upon login.
• Store that session token in the database.
• Check for valid session tokens when authenticating.

Pretty much what you have. Just consider if you want to have more than one valid session at once and how you'll go about expiring sessions.

EDIT for crazy comment thread below

While one can provide tokens to the client that are verified by the 2nd server without communicating with the 1st server, that's ugly and involves a lot of work. Such a scenario does not permit one to invalidate sessions unless the client takes care of it. It also requires a certain time window when tokens are passed, timestamping of tokens, tracking of tokens by the 2nd system, signing or HMACs in the token passing, etc. Unless these two systems can't see each other on the Internet, just avoid that mess entirely.

I gather that both systems can access the same database, but if for some reason they couldn't, having a API exposed to the second system that can remotely verify would be appropriate as well (secret.page?checkUser=token... or such).

Without SSL, there is nothing you can do to prevent session hijacking by means Firesheep / MITM attacks.

Answer 2

My recommendation is a single web app that is used for primary user authentication.

Note: Because of the nature of cookies, this method will only work if the webapps share a common domain. (ie. appone.example.com and apptwo.example.com)
openid does something similar but bypasses the cookie problem, you might want to look intot hat.

How this would work.

1. User points his browser toward App A. App A checks for valid cookie/session/whatever.
   1. It first checks for it's own session/cookie information.
   2. If it can't find it's own cookie, it looks for Auth App's "transfer" cookie.
      1. If it's found, then it create a new session for this app. The user has just logged in.
2. When it finds this is invalid or missing, it forwards the page towards Auth App.
3. Auth App checks for a valid session on it's end.
   1. When it discovers this missing, it brings up a login screen, etc.
4. Once it has a valid session, the Auth App sets a specific "transfer" cookie for that app and redirects the person back to App A.

You should put extra information in this transfer cookie such as-

1. username
2. AuthTime
3. IP address.
4. Random number.

See the following for an example. https://www.login.mtu.edu/docs/public/mtuiso/howitworks2.html

This will be mostly seemless from the user perspective. For example.

1. User point his browser toward app A.
2. App A does it's authentication dance with Auth App. (requiries user to log in, etc.)
3. User clicks a link that forwards to app B.
4. App B does it's authentication dance with Auth App. (This time, Auth app already has a cookie for itself.)
   1. App B forwards to Auth App.
   2. Auth App finds cookie and then right away creates transfer cookie and forwards to App B.
   3. User doesn't even notice this, and finds himself at App B right away.

Answer 3

Four options, first one being with maximum cost(money and performance both) and third being cheapest

1. Deploy solution like Siteminder, Novell, Tivoli etc

2. Maintaining session state in DB. For doing this. Problem with this approach is that it would be difficult to track logouts, session expiry and propogating this informaton between the two applications. As querying the DB before each request would be very expensive

3. Using a Third application just to manage the session states. This application not exposed to end user only restricted within the network with access to only the two applications It stores the states for all users in Application context and the two application send a request to this application

   On login events On logout events On session expiry events before processing any request to check session validity

4. Using a cookie ( with the assumption that both application share the same parent domain)

   Create a cookie which contains username + salt/ecret key and this encrypted Secret key and the encryption keys are with both applications Any request from user will carry this cookie ( Cookie path set to /) So if the cookie contains a username, other application trusts user is logged in on other application