CODEWITHSUNDEEP
javasecuritydistributed
Qedrix
Qedrix

Reputation: 473

Security in distributed web applications system

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.

Upvotes: 1

Views: 825

Answers (2)

Aashish Bhandari
Aashish Bhandari

Reputation: 11

This arrangement will also work: You can redirect all the requests to server A, B and C firstly to only server A for authentication as it has all your user related data. Now once the request has been authenticated (by which ever method you prefer), and in your business logic you need to make an INTERNAL call between servers. For that you can make use of internal users which at the time of deployment are created on each of the servers and their authorization token is stored in a wallet. Fetch the auth token for this internal user from the wallet and initiate the call, the other server will authorize the user. Note: If ever you need that who is the actual user performing this operation then that information can not be derived from Auth Token as the token is of Internal User. In this case you can pass the current logged in user name in http authorization header.

Upvotes: 0

Borealid
Borealid

Reputation: 98509

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.

Upvotes: 2

Related Questions