Is it possible to have Identityserver4 and Authorization authentication in the API separately?

Asked

Viewed 215 times

1

I recently asked a question in stackoverflow in English, but I may have expressed myself badly and I did not get the answer I wanted. Link in English.

I have 3 different applications: Identityserver who is my identity provider; Teaching.MVC which is the frontend in Asp.net mvc; and Teaching.Api.. The latter is the Api itself. The authentication process, Claims definition, scopes and everything else is up and running. It turns out: in the Api I need to define Api-specific Claims. For example:

Identityserver: Authenticates the user and provides the access_token to ensure access from Mvc to Api. This token contains the Profile, Email, User Id and everything that refers to the user. This application only has access to the Identities database.

Teaching.: Log in via Identityserver and save the access_token to access the Api. All this process is described in the Identityserver4 documentation.

Teaching.Api.: Here is the key to the question. The Token the api receives contains the user-related Claims: Id, profile, email... But the Api needs to restrict certain users' access to certain features. The Api has access only to the application database, and does not have access to the identity database. So in the Api, through the User Id, I search if it has registered schools. If so, I should assign it to the "Director" Claim. This same user can also be a student, so I search the database if he has "enrollments". If he has, I assign him to Claim "Student". But I have no idea how I do it at the Api level.

Summary: According to the Claims received in the Api by the access-token, I have to generate new Claims, which are specifically from the Api, and save them so that they can be accessed by context and validate the Policies. All this in the Api.

If anyone knows a better way to do this access control, suggestions are always welcome.

asp.net-mvc asp.net asp.net-web-api asp.net-core identity-server

2 answers

1

Looking at the responsibilities and the proposal itself of Identityserver4, as well as the understanding I had, the Teaching.Api application (acts as Resource Provider) is responsible for providing a resource that the Teaching.Mvc application (acts as Client) want to access.

Starting from this understanding, it is not the responsibility of the Teaching.Api generate access Claims for the user, but rather validate the token and then return the resource requested by the application Teaching.Mvc.

One solution would be: when logging into Teaching.Mvc using Identityserver4, in Identityserver4 itself before you generate JWT, check (creating an implementation of Iprofileservice for example) the Claims list (User.Claims object) and perform your desired logic with the values (search if it has registered schools, if it has, I must assign it to Claim "Director", search in the database if the user has "enrollment" and if it has, I assign you to Claim "Student", etc...).

That is, in your Identityserver4 authenticator you will already generate JWT with the desired Claims instead of adding Claims in other applications.

  • Thanks for the reply Renan. Despite being an old problem I had, it is always good to see other perspectives. As Marcelo Dias said, and as I also think, the identity server should have the responsibility to only identify the user and say who it is. Thus, the API should give this user access to what he is entitled to. Because MVC is only a view layer, as well as a mobile app, which can also access the API, it is not up to it to the permissions process, since I should replicate the permissions logic for other possible user interfaces. With the API I centralize.

  • I suggested controlling this logic in a specific application with Identityserver4 because in a scenario where you have 10 API’s instead of you having to implement access rules in each of them, you would only implement in the application with Identityserver4. Then the MVC application goes in the Identityserver4 application, this Identityserver4 application configures the Claims and passes the token to the MVC application which in turn can then access the API. But it is an option/suggestion among others that solves the problem :-)

1

I believe that the identity server should only have the necessary user, any other information that is just from the application you should add in the Claims once the token is validated.

For this you can use the instance of JwtBearerEvents.

Why in this way? Why you can apply your identity server to various other applications that won’t always have the same user data.

Browser other questions tagged asp.net-mvc asp.net asp.net-web-api asp.net-core identity-server

You are not signed in. Login or sign up in order to post.