Identityserver4.admin: Permission base authorization

[raminassar]

First this is a request and open for discussion.

I went through an article by Jon Smith (https://www.thereformedprogrammer.net/a-better-way-to-handle-authorization-in-asp-net-core/) about permission base authorization, I think this will be useful to be added by extending ASP.NET Identity in your project while most of the developer nowadays are looking for more flexibility on how to manage the roles and permissions in their application.

[skoruba]

Thanks for tip, I will check it. I did the authorization simple as much as possible - with one super admin role - which is able to do everything. It is up to you how you will extend it. Maybe I will extend it in the future. 🙂

[raminassar]

One question, I noticed dev branch is way ahead of your master branch.
I noticed another branch "windows-auth" which is very useful, I would like to clone but wondering about the stability.
When you are planing to do the merge & update the templates?

[raminassar]

Any answer?

[skoruba]

Sorry for delay, next month, according to my free time. It needs some time to polish everything and create new release.

[raminassar]

Shall I wait then before using the template in a new project or it will be an easy upgrade?!

[skoruba]

You can use fork right now. 👍🏼🙂 because fork will be easier to update before final release for sure.

[danielmeza]

There is two simple way to do this one is create a convention based on Claims something like

1. Define a claim convention name:
   Name: permission.{permision-name}
   Value: true

2. Then make a scope called permissions to link the claims that start with permission.*, this way the application can request the scope and the apis can make it mandatory.

3. Create a permission provider how configure the permission at code

4. Create a _Scoped_ Permission Checker to check permissions and Permission Source how consume the profile endpoint to get user permission at runtime and avoid to put permission on the token to reduce token payload.

5. Create a custom Policy or AuthorizationFilter that use the permission checker to handle asp.net core authorization this way we can use it with Attributes, aslo create extensions methods for check permisions claims based on conventions from the policy

6. Create a extensions methods on the UserManager and RoleManager or PermissionManager to handle permission logic, this include methods like or:

   • Gram permissions to user
   • Remove permission to user
   • Flush Role permissions to user
7. Add admin ui to easy manage the user permission

Check this for inspiration we can remove for now the multi-tenancy support in order to keep it simply

@skoruba check this out and let me know your opinion 😃 👍

[mavado83]

An IdentityServer should not contain Permission logic. See this article from the creator of IdentityServer:
https://leastprivilege.com/2016/12/16/identity-vs-permissions/

I did also need permission based authorization. So I created a configuration where I can bind a permission to a role in my application. Using attributes I can now decorate controllers to gain access to a resource or not. Using the IAuthorizationRequirement and DefaultAuthorizationPolicyProvider extension points the permissions are checked.

[danielmeza]

@mavado83 The creator sale a solutions called PolicyServer and AdminUI, say that, this project should not also exists. This project is for cover the gap between the IdentityServer OIDC implementation and the administration of all the resource involved in the OIDC, so IdentityServer will remain clean wile this project can fill the gap between.
Your solution is great, but It will be awesome if we provide that build in and just put things together in a great solution.

[mavado83]

@danielmeza I do think this project is a great addition. But I don't think that permissions should be part of the identityserver/asp.net core identity combination. If we can add a separate project were permission based authorization is added as an example it would be great.

[danielmeza]

We can decoupled the authorization strategy, this way we can choose between Role base, Permission or just claim, note that all authorization we provide are just a set of standardized handle of Claim since OIDC only know about Claims.

Its let to the end user decide witch strategy will chose, since permission are full integrated with roles they both can coexist, we just need to apply convention over claims.
This is related to #472 where we need to define convention over how Claims will be flushed, at leas roles are that just claims flushed to the token by some convention.