Home/ Questions/Q 917885
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T18:16:58+00:00

I have a set of three web application systems – A, B & C

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0