1

Hi I have following structure :

Client App (layer 1) Business logic Services ( Layer 2)

Business Logic layer consists of many microservices . Access token can be created and passed from APP layer to business logic layer. Business logic layer could validate the access token and allow access to required operations.

But Scenario is : user A logged in can access Resource 1 but not Resource 2 ( here resource means Individual records in database ) . How would I manage this situation ? These checks to resource is quite expensive and ideally would be beneficial to be done once from a performance standpoint.

However, Should each of my business layer microservices cross check always if user can access resource each time they are invoked ? Or Should there be a separate access token created when user tries to open each resource and then pass to business logic layer so that it can trust and allow?

0

2 Answers 2

0

When you deal with db records, you dont use access tokens. You should somehow relate the user with the records they have access to. It could be by using the user-id in your resource-table or a different table to associate user-ids with resource-ids. Instead of user-id it could be a user-role, if this is how you decide who has access to what.

Then, after you make the association on db level, you can make the db-queries for the given (authenticated) id or role etc

8
  • In my use case the user access to records are determined by another service and I need to consider this as context to perform an edit on that record in my DB. In monolith, this was managed as a session object so any further downstream calls could be handled with the session information.
    – TechNjBat
    Commented Sep 20, 2023 at 13:56
  • this is not clear at all. i think you need to understand what you re trying to do. now u mention sessions and monoliths. are you just trying to pass the session down to the calls? cause from what i can imagine you dont hit any db directly apparently. if you want to pass the session around through rest requests you can. stackoverflow.com/questions/44820297/… Commented Sep 20, 2023 at 15:58
  • So if i cannot maintain an association at a DB level due to the 2 different data stores how could i tackle this situation differently ? Today , i pull the data from data store 1 and persist in session before updating the records to data store 2. This way Yes my monolith is responsible to authorize . With microservices approach i am trying to simulate the behavior with Access Tokens ( By sort of adding each item unique identifier to the token ) when user tries to open each item. This way microservices can just trust token and push the data to the data store 2.
    – TechNjBat
    Commented Sep 22, 2023 at 20:05
  • first of all, when u migrate, you dont have to copy the exact solution but use the new technology's properties, strengths etc. but if you want to stick with it, as i said before, you can use a session-id in rest requests. this way you use the same session-id to track and authenticate calls of a user A down to store 1 and then store 2 Commented Sep 25, 2023 at 13:16
  • Any relevant advantages of using session Id and session store instead of storing the data in Token
    – TechNjBat
    Commented Sep 25, 2023 at 13:32
0

If resource 1 and 2 are general classifications, then it's advisable to implement access control in the token.

For example, you can assign roles to users, or ownership to resources - these are known as access matrix columns and rows. Then, sign the token using cryptographic algorithms such as HMAC or ECDSA (public-key algos have higher overhead than symmetric key ones, this needs to be considered).

There's a lot of information on Information Security SE you can check those out. Recommended search keywords: access-control, role-based, token signature, message authentication code, hash.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.