+972 52-548-6969
Using technical limits as complexity barriers
In a previous post about authorization in a microservice environment, I wrote that one option is to generate an authorization token and have it hold the relevant claims for the application. I was asked how I would handle a scenario in which the security claim is over individual categories of orders and a user may have too many categories to fit the token.
This is a great question, because it showcase a really important part of such a design. An inherent limit to complexity. The fact that having a user with a thousand individual security claims is hard isn’t a bug in the system, it is a feature.
For many such cases, it really doesn’t make sense to setup security in such a manner. How can you ever audit or reason about such a system? It just doesn’t work this way in the real world. An agent may be authorized to a dozen customers, and her manager will be allowed access to them as well. But attaching each individual customer to the manager doesn’t work. Instead, you would create a group and attach the customers to the group, then allow the manager to access the group. Such a system is much easier to work with and review. It also match a lot more closely how the real world works.
Some of the problems here are derived from the fact that it seems like, when we use a computer, we can build such a system. But in most cases, this is a false premise. Not because of actual technical limitations, but because of management overhead.
Building the system upfront so the things that should be hard are actually hard is going to be a lot better in the long run.
Comments
Well ... the fact that something is hard is irrelevant to some people ...
Pop Catalin, That is a great example. You get to this point, and it is obvious that the problem isn't with the tools, see:
Related to the problem of authorization, i think it's even more relevant to look at where the authorization rules belong - in the example mentioned user access is controlled at the order category level. So we can assume that order category belongs to order handling domain, not to the user service, therefore such security rules should be expressed in the order service and not be a part of the user token. And the user token should only contain information belonging to the user service domain - in this case it would be user's ID, name, groups where he belongs + maybe some static/generic permissions if they belong to the user service.
Rafal, Authorization is one of those cross cutting concerns, it doesn't make sense to try to have a different one for each domain
sometimes. and sometimes it's the business that decides what makes sense and what not. Architect's role then is to make sure implementation is proper, even despite his dislike for what business wants. Some example to think about: document sharing online, where you can share a document with as many users as you want, by adding their names or emails. So, then, should the user token have a list of all documents the user is allowed to see? or maybe it's rather a document where this info belongs?
Rafal, Document sharing online is a great example. If the UI allow you to enter one user at a time, you aren't going to add 10,000 users. That make things a lot simpler for everyone. Because a document shared with 10,000 people probably need a very different semantics than one shared with 5.
Comment preview