Security in distributed web applications system

Question

I have a set of three web application systems - A, B & C that are used to service my application. The A system has the core business logic and also stores user/account data for the entire application. The systems B & C are required to provide additional functionality to the application.

I was thinking of a security mechanism where a user U log's in to the main system A and the system creates a security token for the current session which will be required to authenticate a request from the user U to the other systems B & C. The moment the user logs into the system A, it internally generates the token and sends the token x-y-z to the sub systems B & C. Now whenever, user U sends a request to the sub-systems B & C with a valid token, the user will be allowed access to the resources. But then, I am not sure if this is the best approach or even a correct one.

So, I am a bit confused about the complete workflow and any help in this regard will be highly appreciated.

I develop in Java and therefore any module that manages it already will save a lot of my development time. Please guide me.

Answer 1

This model you are describing is a form of trust escrow, where multiple clients trust a third party to handle user authentication.

See the Kerberos distributed security system.

The Kerberos protocol and its web-application implementation, Stanford WebAuth, have a few advantages over what you describe:

• There is no need to send the token from A to B+C when a user logs in. Instead, A (the "KDC" in Kerberos terms) shares a secret with B (a "Kerberized server") and one with C only at the initial setup of the trust relationship.
• The token cannot be intercepted as it is never sent in the clear from A to the user.

If you do not need full-fledged Kerberos authentication, which can be complex to implement, I'd encourage a model like this:

• User Joe authenticates to A, preferably using a challenge-response protocol which doesn't involve sending Joe's password to A
• A cryptographically signs Joe's username, the current time, and some randomly-generated garbage
• B and C accept users within the specified time frame who can present packages signed by A containing their username and the appropriate time

This is a basic authentication-token protocol. It's flawed in several ways, but is still better than sending the user password around.