0

I need to design a system that handles multiple types of resources, each having their own business logic and different types of actions available for those resources. The requirements are a natural fit to have a separate service for each type of resource (not necessarily microservice architecture, at least not at the beginning, but a modular approach with the possibility of splitting into microservices down the line).

Individual users should have specific permissions on individual resources. For example:

  • types of resources are A, B, C, D, E
  • for simplicity individual resources are marked as <type>-<ID>, e.g. A-123, B-456
  • each type has specific privileges related to it, based on specific actions available for that resource (P-A1, P-A2, P-A3, P-B1, P-B2 etc.)

Individual users have specific privileges for a specific resource:

  • Steve has privileges P-A1 and P-A2 for resource A-123, but only privilege P-A3 for resource A-456
  • Ellie has privilege P-B2 for resources B-222, B-333 and B-444 and privilege P-C3 for resource C-111
  • Dave ("C-admin") has privileges P-C1 and P-C4 for all C-type resources

These specific privileges might be subject to change as the business logic and rules gets updated in the future.

Would it be better to have a centralized authorization service that would keep track of all the mappings of all users to individual resources and their privileges (in which case it would need to know of all the resource types and all individual privileges, so when any other service updates this one needs to update too),

or

for each individual service/module to implement its own authorization and keep track of which user has which privileges (in which case it would need to be implemented in each service individually, duplicating code)?

2
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    Commented Mar 23 at 18:11
  • 1
    How do the resource owners view the administration of these permissions? If you're unsure whether to split something up then consider the viewpoint of whoever will be responsible for day-to-day permission management. Are there different business owners for each resource who might need to make these changes separately? or is there just a single person/team who controls users and permissions for the whole organisation? Commented Mar 24 at 15:08

1 Answer 1

2

This answer is intended to explain some of the logic in making the decision and to question so of the assumptions.

A concept of microservices is to attempt to separate the data to the specific microservice when possible.

Example in an eCommerce system: Product catalog is separate from Customers

What your are describing sounds something like a roles or rights microservice that supports the other microservices as part of the identity management.

Your question about duplicating code is a red flag that helps point that perhaps the requirement in question (rights/roles) should be split out into its own microservice.

If this is an inhouse system for your company only or a single customer (assuming you're a custom software company) then consider if microservices is more than "buzzword of the week". Meaning it might be better to have less separate microservices and a larger api.

If this is something that is expected to auto-scale and is truely microservices, more serious consideration needs to be given to rights and roles.

What I mean by this is, are you expecting to do a database call on each request to get the rights information? Or are you saving it back to the client in an encrypted way that is cached for x seconds or minutes?

2
  • Agreed, those needn't necessarily be microservices. Still, there might be a chance in the future if this thing grows. It's an in-house solution but it's a big house. My biggest concern is in keeping the modules as decoupled as possible. The permissions should be persisted in a DB as they are something to be maintained (and also updated occasionally). Perhaps a good fit would be something like an Access Control List (ACL)? Commented Mar 23 at 14:05
  • You are in the position of balancing current needs with POSSIBLE future needs. If there isn't an extremely clear need and path to a more complex requirement, perhaps go with a simple solution. The business need should be the driver of the code, not the other way around. Role based rights, User based rights, Attribute based - that is business driven and tested and account for edge cases. You are thinking about the appropriate things, but without DDD (domain driven design) you are left to guess at the answer. Once you have clarity from the business use case then the design will be clear.
    – DogBoy37
    Commented Mar 23 at 20:39

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.