We are currently architecturing our next application. For each deployment, we will have different "organizational" level:

We will have several endpoints, either to read either to edit data for each division/factory. The idea is to assign a user with a permission to any level of this tree:
- UserA can be Reader of Division 1 and Admin of Division 2(which would cascade the rights to their factory)
- UserB could be just reader of Factory 3
- UserC could be reader of the Root-organization(which will cascade) but admin of factory 3
Now, let's admit we are trying to read/write
GET : http://service-url/api/factories/4
--> UserA/UserC should be allowed but not UserB POST: http://service-url/api/factories/4
--> UserA/UserC should be allowed but not UserB
GET : http://service-url/api/factories/3
--> UserA/UserB/UserC should be allowed POST: http://service-url/api/factories/3
--> UserA/UserC should be allowed but not UserB
I've started to check how to do this, I've seen that I can add additional claims in my token. I could even compute every inherited rights at the creation of the token and having something like:
new Claim("roles", "division2:admin,factory3:read")
I've then searched how I can validate that the current user has the rights to execute the service URL, but the closest thing I could find was to do a policy:
builder.Services.AddAuthorization(authOpt =>{
authOpt.AddPolicy("IsRessourceAdmin", policyBuilder =>{
policyBuilder.RequireAuthenticatedUser();
policyBuilder.requireClaim("roles", ...);
}
});
but:
- I don't think I've access to the ":id" currently being modified
- I'm not sure we can do "contains" or custom logic to validate the claim?
So it possible to validate my scenario? It feels kind of a standard scenario, where the role is assigned to a given ressource for a given user, but I can't find a solution for it.
