0

Current set-up:

  • App2 is an existing web app created to enable users to do transactions. Has login. Accessed globally.
  • App1 is a purely informational app with no login. Accessed globally.

Proposed changes:

  • App1 will now have user login and some new functions
  • Part of its new functions is to have some of the transactional back end of App2

Plan

  • Create web service in App2 to expose functions that would be accessed by App1.

Dilemma

  • The web service exposed by App2 should only be used by logged in users from App1.

Settings

  • App1 and App2 are deployed on the same app server (and will likely have this setup for a long time)
  • App1 and App2 has a different set of users from different databases.

Question:

  1. whats the best way to solve the dilemma?
  2. Would it be practical just to copy App2's back end in App1 instead?
  3. Would having the two apps as Single Sign also be a practical choice? (e.g. just provide a direct page link in App1 to App2 while under SSO. )

that is all. thanks. Any advise would be appreciated.

lecarpetron dookmarion
  • 519
  • 2
  • 7
  • 18

1 Answers1

1

The solution to this problem is part of any token based authentication solution.

After your users authenticate against App1, you allow them to retrieve a token to access the API in App2. This token must be signed (to guard against tampering) and contains a relying party identifier or audience URI.

The API you expose in App2, checks whether the token is valid and is intended for use to call it (has correct relying party identifier or audience URI).

Community
  • 1
  • 1
MvdD
  • 22,082
  • 8
  • 65
  • 93
  • You mean the same concept for CSRF prevention? since two different apps will reference the same token, would it be ok if this token is saved temporarily in the db? is this possible to do without using a 3rd party like OAuth? – lecarpetron dookmarion Jul 05 '15 at 02:30
  • I'm talking about bearer token, not CSRF tokens. Your STS would issue a token specifically for the API you want to call. One of the claims inside the token would indicate who the token is for (audience or relying party). You can do this with any STS, no specific need for OAuth. You also don't need to store anything in a db as the token contains all the claims you need. – MvdD Jul 05 '15 at 18:33
  • So the concept is, before the web service api is called, the client asks for a token then submits this along with the msg request. In the token are the allowed usernames allowed to access the api? Did i get that correctly? – lecarpetron dookmarion Jul 06 '15 at 13:50
  • yes, a token is issued for every user, so it only contains the user name of the user using the service. It also contains other information like the time range in which the token is valid, who the token was issued by and who the token was intended for. – MvdD Jul 06 '15 at 17:16
  • The token is generated on the client end? – lecarpetron dookmarion Jul 09 '15 at 06:09
  • No, tokens are issued and signed by a Security Token Service at the server side. – MvdD Jul 09 '15 at 15:17
  • Wait im confused. How will the security token service distinguish the valid user from a hacker? – lecarpetron dookmarion Jul 12 '15 at 06:11
  • The user authenticates with the STS and then the STS generates a token which it signs. The service consuming the token has the public key of the signing key pair and therefore trusts those tokens to be from a valid user. – MvdD Jul 12 '15 at 18:09
  • ok tell me if i understood it correctly. App1 requests token from STS. STS generates key-pair. Public key given to App1. App1 accesses web service of App2 using token with public key. App2 receives it. App2 contacts STS to verify if public key matches its private key. – lecarpetron dookmarion Jul 15 '15 at 13:58
  • Typically App2 would be configured to have the public key or the key-pair with which the STS signs the tokens. App2 does not need to contact the STS to verify the token. See digital signatures: https://en.wikipedia.org/wiki/Digital_signature – MvdD Jul 15 '15 at 22:12
  • Why cant just the web service consumer send the username and password when accessing the web service? Im just thinking of the simplest way. STS would be a little complicated. Would that suffice? – lecarpetron dookmarion Jul 27 '15 at 12:12
  • You can, it's called basic scheme authentication. But there are several reasons why it's not a good idea. See my answer here: http://stackoverflow.com/a/27138900/18044 – MvdD Jul 27 '15 at 17:01