Can we restrict users in identity server4 to specific applications?

Question

I am trying to implement IdentityServer 4 for enterprise scenario.

I understand that users are registered against Identity server.

My question is how to give permissions to users against applications, like as users are needed to assign to a particular application, if not assigned application should return unauthorized.

If a user needs to access multiple applications then multiple assignments are needed.

I am looking a way for Identity server to invalidate the submitted token if the user doesn't have access to the application in a single go, even though the challenged token might be valid if it is submitted by other application which the user has access to

Answer 1

Identity Server absolutely handles authorizations on the most basic level. It creates authorization codes and access_tokens that are essential in an applications authorization. Without them you cannot get authorized. Thus for others to claim Identity Server does not do authorizations is flat out wrong.

I came in here a week ago looking for a solution for this very same problem. I want to restrict users to specific applications by not granting them access tokens if they fail to meet certain parameters, in my case a UserClient table. Lucky for you I have a solution. Identity Server 4 implements a few, what they call, CustomValidators that occur at the time of authorization or token creation. They are

   internal class DefaultCustomAuthorizeRequestValidator : ICustomAuthorizeRequestValidator
   internal class DefaultCustomTokenRequestValidator : ICustomTokenRequestValidator
   public class DefaultCustomTokenValidator : ICustomTokenValidator

There name really says it when they get called. Each one contains a single method

   public Task ValidateAsync(CustomAuthorizeRequestValidationContext context)
   { 
        return Task.CompletedTask;
   }

Notice something? That's is right! It does nothing. Almost as if they are meant to be replaced. (It is).

This is the area that you can add your custom logic to reject the request. CustomAuthorizeRequestValidationContext contains ClientId and User claim information. It also contains a boolean value called IsError. Simply set that to true and whamy! Access denied. You can also set error messages etc. Here is an example that implements the ICustomAuthorizeRequestValidator inface that will restrict a user based on there user Id

  public Task ValidateAsync(CustomAuthorizeRequestValidationContext context)
    {
        var sub = context.Result.ValidatedRequest.Subject.FindFirst("sub");
        if (sub != null && sub.Value != "88421113")
        {
            context.Result.IsError = true;
            context.Result.Error = "Unauthorized";
            context.Result.ErrorDescription = "You are not authorized for this client";
        }

        return Task.CompletedTask;
    }

Feel free to inject a dbcontext or two to read off of your userclient table. I check the sub claim to be null because this will get hit several times before actual login occurs.

From what I noticed all three behave similar in terms of use, but different in terms of outcome. Setting an error ICustomAuthorizeRequestValidator will prevent the redirect to your client and instead direct you to the Identity Server error screen. The other two will redirect back to the client and generally throw some throw some sort of HttpResponse error. Therefore replacing the ICustomAuthorizeRequestValidator seems to work best.

So simply created a class that implements ICustomAuthorizeRequestValidator. Then add that into your identity services like so

services.AddIdentityServer().AddCustomAuthorizeRequestValidator<MyCustomValidator>()

and you are done done.

Answer 2

For users, IdentityServer is authentication only. Authorization should be handled by your application.

Authentication = Verifying who a user is

Authorization = Verify what a user can do

Update

I wrote an article on this topic to clarify how OAuth 2.0 does is not user-level authorization. Hope it helps! https://www.scottbrady91.com/OAuth/OAuth-is-Not-User-Authorization

Answer 3

You can add a claim in your IdentityServer4's claims table called "role" and in your application, add some UI to authorize a person via email or similar, and then set his/her role in the claims db. And you can also delete the authorized user from your application, which should un-assign a role to that particular person. Thus he/she although is successfully authenticated, can't use your application because you have authorized then. Hope this approach helps you!