1

I'm building a microservice-based application (services according to DDD) and am about to implement authorization service. There are API gateways and UI applications that access backend servers, and they all need to query the authorization service.

Consider an ebay-like app with staff, sellers, and buyers. In my system there are users, and each user can have multiple roles, e.g. be both a seller and a buyer. A seller can have multiple users associated with it (in case of multiple employees.) Each employee would have its own user id, but be associated with the same role (the seller id or buyer id.) Staff also have sub-roles: seller managers, buyer managers, and admins.

I am planning on a 3-tiered, permission-based authorization scheme:

  1. If UI application: is the user logged in, and does the user id have permission to view this page?
  2. If API gateway: is the API key valid? (No other checks here)
  3. Actions (backend services) -- does the user id have permission to access this command or query on the backend server? (Application-level auth in DDD terms)
  4. Scopes -- Command: can the user modify this subset of data? Query: return the subset of data allowed for this user id.

Although I'd like feedback on all three, my question is more about the 3rd. Consider the following scenarios:

  1. An endpoint for retrieving all the sellers in the database. A user with a "staff" role and sub-role "admin" can view a list of all sellers. A staff with sub-role "seller manager" can view a list of all the sellers he manages.
  2. Same as above, but modifying a seller. The seller manager can only modify sellers he manages.
  3. An endpoint for retrieving seller information by seller ID. Admins have access to all IDs. Seller managers have access to all seller ids they manage. Sellers have access to only their own seller ID.

My questions:

  1. In the above scenario, what is the best way to the API endpoint? Should I have a single endpoint for returning all sellers, for example? Or should I have separate endpoints based on the sub-role types? For scenario 3, should I have separate endpoints for each of "seller", "seller manager", and "admin"? There would be duplication but perhaps more clarity.
  2. How should scoping be done? I can have each permission in the authorization service have a is_scoped boolean. E.g. "list_sellers" permission, 'scoped' = true. If scoped, the domain service will somehow detect this and limit the results. But how should this be accomplished?

Any thoughts and suggestions would be appreciated!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.