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

The question is: How to authenticate user on a web page/application which consists of multiple systems/platforms on the backend?

I can imagine it this way:

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.

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. Backend 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. Thanks for your time and answers/comments.

'rendered on the page in hidden fields' this seems like a bad idea.
–
this.joshSep 12 '11 at 20:47

@this.josh: yeah what I really meant is to store these informations somewhere on the client, doesn't have to be hidden fields, it can be a cookie...
–
yojimbo87Sep 12 '11 at 20:51

A fundamental question is whether the two systems are serving pages from the same domain (e.g., www.example.com/a and www.example.com/b); from two related domains (e.g., a.example.com and b.example.com); or two unrelated domains (e.g., a.com and b.com). This affects what solutions are or are not viable.
–
D.W.Sep 23 '11 at 16:53

3 Answers
3

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

Deploy solution like Siteminder, Novell, Tivoli etc

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

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

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

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.

I also need to cover the case when user is authenticated from multiple browsers for example, or when the real-time connection is lost and needs to be reinitiated (I can think of one problem which may happen here - I will be passing expired token to the second system so the authentication would fail).
–
yojimbo87Sep 12 '11 at 15:37

1

Design your schema so authentication tokens are in their own table and joined to the user table by user id. Primary key (user_id, token). Then you can have multiple valid sessions. You may also want to add an expiry timestamp that is checked by your app and have a cron job to delete expired tokens.
–
Jeff Ferland♦Sep 12 '11 at 15:40

Other solution which came to my mind: when the page is loaded, send AJAX request for token to the first system and in the success callback of this AJAX call pass token to the second system connection request. This way there is no need for storing token or user ID in the hidden fields.
–
yojimbo87Sep 12 '11 at 16:00

1

EDIT: nevermind; You don't want to be authenticating like that. There shouldn't be anything like this on the client side. I know the right way to do this, but I don't know the specifics. I will research and get back to you.
–
user606723Sep 12 '11 at 17:11

How will you prevent replay attacks? How will you invalidate a session on logout? Deal with a disconnected session? It is possible to do this with client-side work, but you've made a much much larger headache for yourself if you go down that route.
–
Jeff Ferland♦Sep 12 '11 at 17:22

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.