How to organize communication in an asp.net web application using separate authorization server, web api, ui?

Question

The requirements

• we have 3 modules ui, api, IdentityServer (IS) (client, resource, IS in terms of IdentityServer)
• all the modules should be separated from each other (separate dbs for IS and api)
• api is stateless (all the needed auth info got from tokens)
• the api will have resources like \projects, \users, etc.
• another entry point may be added in the future like another-ui which will communicate with the IS and api and will have its own claims

The problems

The main problem is that the resources of api like \projects\12345, \users\, \projects\123456\users, etc. may also be needed as claims in IS. For example, api module reads the access token of authorized user and see the claim projects that equals ["222", "12345"], so the resource \projects\12345 or \projects\123456\users are allowed for that user. Users are identities in IS and resources in api at the same time. Projects are claims in IS and resources in api at the same time.

I thought of book-keeping these entities that are represented in both modules through the ids (guids). But ids won`t solve all the problems.

Some of them are:

• creation of a new project with its id should grant that user the rights to use it in the future, so we need save the claim for that user in some way. The modules are separated, so should we call the IS api to create that claim for that user and then proceed with project creation. How the communication between the two (IS and api) should be organized? Do we need to register the api as another client in IS?
• How should updates of users in IS like changing the email, phone (the values one may log in with) will update the api. I thought of showing warnings that the auth email (got from token) does not match the info email.

Could you, please, explain how modern systems coupe with the per resource access?

Thank you for your time.

Answer 1

First you need to make sure what a claim is.

Claim is not a permission or a role, it's what the user is. Based on what the user is, then you can assume the permissions.

https://learn.microsoft.com/en-us/aspnet/core/security/authorization/claims?view=aspnetcore-3.0

A claim is a name value pair that represents what the subject is, not what the subject can do.

So starting from that, you can get the claims and do the following.

Let's say that a user is the owner of a project. When the new project is created, the project api can update the identity server and add a claim to the user saying he is the owner.

In your apis the owner of a project has a set of permissions and based in those, access to specific resources

In the DDD Domain driven design world, a little bit of data duplication does not matter. So duplicating the possible claims that your application needs in terms of roles (again, not ids but a mapping of one or more claims to specific roles) is not a bad practice.

When you update some kind of claim from your api, you should do so in a transactional way. Think first if you need the email to be saved in both. You will get the user data from the claims anyway on every request. Is it even something you need as a claim? If not have it in your api only.

Communication between apis is organized in many ways. If you need transactions or eventual consistency is something you should also consider. Communicating with events or queues is the microservices way to go, with patterns like the SAGA being the coordinator.