In December 2018 I wrote the first article in the series called “A better way to handle authorization in ASP.NET Core” which describe an approach to improving how authorization (i.e., what pages/feature the logged in user can access) in ASP.NET Core. These articles were very popular, and many people have used this authorization/data key approaches in their applications.
Back in 2018 I didn’t think I could produce a library for people to use, but I have finally found a way to build an library, and it’s called AuthPermissions.AspNetCore (shorten to AuthP library in these articles). This open-source library implements most of the features described in the “A better way to handle authorization” series, but the library will work with any ASP.NET Core authentication provider and now supports JWT Tokens.
NOTE: At this time this article was written the AuthPermissions.AspNetCore library is/was in preview (1.0.0-preview) and I am looking for feedback before taking the library to full release. Please look at the roadmap discussion page for what is coming. Also, the preview some features won’t work on a web app running multiple instances (called scale-out on Azure).
This first article is focused on the improvements the AuthP library provides to using “Roles” to manage what feature users can access, but the library contains a number of other useful elements. The full list of articles is shown below:
- Finally, a library that improves role authorization in ASP.NET Core (this article).
- Improving security when using JWT Tokens in ASP.NET Core (VIDEO)
- Simplifying the building of a multi-tenant architecture with ASP.NET Core (VIDEO).
- AuthPermissions.AspNetCore now supports Azure Active Directory (VIDEO).
TL;DR; – summary
- The AuthPermissions.AspNetCore library has three main features:
- Implements an improved Role authorization system (explained in this article).
- The AuthPermissions.AspNetCore library can work with
- Any ASP.NET Core authentication provider.
- Either Cookie authentication or JWT Token authentication
- This article focuses on AuthP’s improved “Roles / Permissions” approach, which allows you to change a Role without having to edit your application. Each user has a list or Roles, each Role containing one or more enum Permissions.
- When the user logs in the AuthP library finds all the Permissions in all the Roles that the user has. These Permissions are packed into a string and added as a “Permissions” claim into the Cookie authentication or the JWT Token.
- The AuthP’s HasPermission attribute / method will only allow access if the current user has the required Permission.
- See other articles or the AuthP’s documentation for more information.
- You can see the status of the AuthP library via the Release Notes document in the repo.
Setting the scene – How the AuthP library improves Roles authorization in ASP.NET Core
If you not familiar with ASP.NET’s authentication and authorization features, then I suggest you read the ”Setting the Scene” section in the first article in the “A better way to handle authorization” series.
Back in the ‘old days’ with ASP.NET MVC the main way to authorize what a user can access was by using the Authorize attribute with what are called “Roles” – see the code below, which only lets a user with either the “Staff” or “Manager” Role to access that method/page.
[Authorize(Roles = "Staff,Manager")]
public ActionResult Index()
{
return View(MyData);
}
ASP.NET Core kept the Roles approach but added the more powerful policy-based approach. But I found both approaches to have limitations:
- Limitations of the ASP.NET Core Roles approach
- The main limitation of the ASP.NET Core Roles is that authorization rules are hard coded into your code. So, if you want to change who can access a certain pages/Web APIs, you have to edit the appropriate Authorize attributes and redeploy your applicatios.
- In any reasonably sized application, the Authorize attributes can get long and complicated, e.g. [Authorize(Roles = “Staff, SalesManager , DevManage, Admin, SuperAdmin”)]. These are hard to find and maintain.
- Limitations of the ASP.NET Core Roles policy-based approach
- It very versatile, but I have to write code for each policy, which are all slightly different. And in a real application you might end up writing a lot of policy code.
From my point of view “Roles” are a useful concept for users, typically a user (human or machine) has a Role, or a few Roles, like SalesManager with maybe with an additional FirstAider role. Think of Roles as “Use Cases for users”.
But “Roles” are not a useful concept when defining what ASP.NET Core page/feature the user can access. That’s because for some feature you need fine-grained control, for instance a different access level for display, create, and update of sales information. For this a use what I call “Permissions”, for example you I might have SalesRead, SalesSell, SaleReturn, Permissions where the “Sales person” Role only have the SalesRead, SalesSell Permissions, but the” Sales manage” Role also has the SaleReturn Permission.
The AuthP’s approach says that “users have Roles, and your code uses Permissions to secure each page/WebAPI”. The AuthP’s Roles a number of benefits:
- No more deploying a new version of your application when you want to change what a Role can do – the AuthP’s Role/Permissions mapping is now in a database which admin people can change.
- The Permissions are declarative, just like the [Authorize] attribute (e.g. [HasPermission(MyPermissions.SalesSell)]) which makes it easier to maintain.
- You can have broad Permissions, e.g. NoticeBroadAccess (covering create, read, update, and delete), or fine-grained Permissions like SalesRead, SalesSell, SalesSellWithDiscount, SaleReturn for individual actions/pages.
NOTE: The AuthP’s Roles are different from the ASP.NET Core Roles – that’s why I always refer to “AuthP’s Roles” so that its clear which type of Role I am talking about.
How to use the AuthP’ library with its Roles and Permissions
So, let’s look at the various code you need in your ASP.NET Core application to use the AuthP’s Roles/Permissions system. Starting at the Permissions and working up the parts are:
- Defining your Permissions using an Enum
- Using these Permissions in your Blazor, Razor, MVC or Web API application
- Configuring the AuthP library in ASP.NET Core’s ConfigureServices method.
- Managing the user’s AuthP Roles and what Permissions are in each Role.
1. Defining your Permissions
The Permissions could be strings (just like ASP.NET Roles are), but in the end I found a C# Enum was best for the following reasons:
- Using an Enum means IntelliSense can prompt you as to what Enum names you can use. This stops the possibility of typing an incorrect Permission name.
- Its easier to find where a specific Permission is used using Visual Studio’s “Find all references”.
- You can provide extra information to an Enum entry using attributes. The extra information helps the admin person when looking for a Permission to add to a AuthP’s Role – see the section on defining your Permission Enum.
- I can use the Enum value: In the end I defined an enum with a ushort value (giving 65534 values), which can be stored efficiently in a (Unicode) string. This is important because the Permissions needed to be held in a claim and if you ASP.NET Core’s Cookie Authorization then a cookie has a maximum size of 4096 bytes.
So, let’s look at an example from Example4 in the AuthP’s repo, which is an application that manages a shop stock and sales. I have only shown a small part of Permissions in this example, but it gives you an idea how you can decorate each Permission to provide more info and filtering to the admin user.
public enum Example4Permissions : ushort //Must be ushort to work with AuthP
{
NotSet = 0, //error condition
//Here is an example of very detailed control over the selling things
[Display(GroupName = "Sales", Name = "Read", Description = "Can read any sales")]
SalesRead = 20,
[Display(GroupName = "Sales", Name = "Sell", Description = "Can sell items from stock")]
SalesSell = 21,
[Display(GroupName = "Sales", Name = "Return", Description = "Can return an item to stock")]
SalesReturn = 22,
[Display(GroupName = "Employees", Name = "Read", Description = "Can read company employees")]
EmployeeRead = 30,
//other Permissions left out…
//Useful for setting up a SuperAdmin user
[Display(GroupName = "SuperAdmin", Name = "AccessAll",
Description = "This allows the user to access every feature", AutoGenerateFilter = true)]
AccessAll = ushort.MaxValue,
}
2. Using these Permissions in your Blazor, Razor, MVC or Web API application
AuthP can be used with any type of ASP.NET Core application, with three ways to check if the current user has a given permission.
2a. Using AuthP’s [HasPermission] attribute
For a ASP.NET Core MVC or Web API controller you can add the [HasPermission] attribute to an access method in a controller. Here is a example taken from Example2’s WeatherForecastController, which is Web API controller – see the first line.
[HasPermission(PermissionEnum.ReadWeather)]
[HttpGet]
public IEnumerable<WeatherForecast> Get()
{
//… other code left out
}
2b. Using AuthP’s HasPermission extension method
If you are using Blazor, or in any Razor file you can use the HasPermission extension method to check if the current ASP.NET Core’s User has a specific Permission. Here is an example taken from AuthP’s Example1 Razor Pages application
public class SalesReadModel : PageModel
{
public IActionResult OnGet()
{
if (!User.HasPermission(Example1Permissions.SalesRead))
return Challenge();
return Page();
}
}
The HasPermission extension method is also useful in any Razor page (e.g. User.HasPermission(Example.SalesRead)) to decide whether a link/button should be displayed. In Blazor the call would be @context.User.HasPermission(Example.SalesRead).
2c. Using the IUsersPermissionsService service
If you are using a front-end library such as React, Angular, Vue and so on, then your front-end needs to know what Permissions the current user has so that the front-end library can create method similar to option 2, the HasPermission extension method.
The IUsersPermissionsService
service has a method called PermissionsFromUser which returns a list of the Permission names for the current user. You can see the IUsersPermissionsService service in action in Example2’s AuthenticateController.
3. Configuring the AuthP library in ASP.NET Core’s ConfigureServices method.
The AuthP library has a lot of methods and options to set it up. It will work with any ASP.NET Core authentication provider that returns the UserId as a string.
The code below uses ASP.NET Core’s Individual Accounts authentication provider in an MVC-type application – the highlighted lines contain the configuration code to set up the of the Permissions enum.
public void ConfigureServices(IServiceCollection services)
{
//… other normal ASP.NET configuration code left out
//This registers the AuthP library with your Permission Enum
services.RegisterAuthPermissions<MyPermissions>()
//This sets up the AuthP’s database
.UsingEfCoreSqlServer(Configuration.GetConnectionString("DefaultConnection"))
//This syncs AuthP to your ASP.NET Core authentication provider,
//In this example it’s the Individual Accounts authentication provider
.RegisterAuthenticationProviderReader<SyncIndividualAccountUsers>()
//This will ensure the AuthP’s database is created/migrated on startup
.SetupAuthDatabaseOnStartup();
}
NOTE: There are many configuration parts to the AuthP’s library, and this shows a simple configuration appropriate for an existing application that is using ASP.Net Core’s Individual Accounts authentication. Please look at the AuthP startup documentation for a more detailed list of all the configuration options.
How the AuthP library works inside
The final part of this article gives you an overview of how the AuthP library works, mainly with diagrams. This should help you understand how AuthP library works.
When someone logs in some ASP.NET Core claims are built and stored in an the Authentication Cookie or in the JWT Token. The diagram shows the AuthP code in orange, with the blue part provided by ASP.NET Core and its authentication provider.

As you can see AuthP finds the user’s AuthP Roles and combine the Permissions in all the user’s AuthP Roles into a string (known as packed permissions), which becomes the Permissions claim’s value. This Permissions claim is stored in the Authentication Cookie or in the JWT Token.
This approach is a) very efficient as the Permission data is available as a claim (i.e., no database accesses needed), and b) a user’s AuthP Roles can be changed without needing to re-deploy your application.
NOTE: Normally the Permissions are only calculated when someone logs in, and any change to the Users’ AuthP Roles would only change by logging out and back in again. However, there are features in AuthP that can periodically re-calculate the user’s Roles/Permissions. I talk about this in this section of the document explaining how JWT Token refresh works.
The second part is what happens when a logged-in user wants to access a Page, Web Api etc. Because AuthP library added a Permissions claim to the Authentication Cookie / JWT Token the ASP.NET Core ClaimsPrincipal User claims will contain the Permissions claim.
When an [HasPermission(MyPermissions.SalesSell)] attribute is applies to a ASP.NET Core controller or Razor Page is calls a policy-based service that the AuthP library has registered. This Permission policy allows access to the method / page if the “MyPermissions.SalesSell” Permission is found in the User’s Permissions claim’s string. Otherwise, it redirects the user to either the login page or an Access Denied page, if already logged in (or for Web API it returns HTTP 401, unauthorized, or HTTP 403, forbidden).

Conclusion
This first article gives you an overview of the AuthP’s most important, that is the ability to change what a Role can do via an admin page instead of the ASP.NET Core Roles where a change requires you to edit your code and redeploy your application. In addition, the AuthP’s Permissions allow you to have very fine-gained access rules if you need it. Future articles will explain other features in the AuthP libraray.
The AuthP library is far from finished but I think it has the basics in it. The big limitation of the preview is that some features, like bulk loading on startup, only run on a single instance of the web app (i.e. no scale out). My plan is to solve that in the non-preview version of the AuthP library
I have put out a preview version to get some feedback. I have set up a roadmap discussion for you to see what I am planning and getting your suggestions and help. Please have a look at the library and add your comments suggestions to the roadmap discussion.
Happy coding!
I’ve noticed during my testing that your HasPermissionAttribute has an important difference from Identity’s AuthrorizeAttribute… it doesn’t support inheritance.
I didn’t see reference to this in the documentation here (perhaps I missed it) – but I think this is an important distinction to mention.
It seems to be a conscious design decision (as you’ve set Inherted to false on the attribute). I’m thinking of using my own version of your attribute with Inherited set to true – I’ve tested it and it seems to work – but I’m just wondering if I’m missing something obvious?
Also, I see you’ve also blocked multiple attributes – so presumably its not possible to have multiple permissions granting access like it would be Identity? (i.e. any of one of a number of permissions granting access). I guess this makes sense given the granular nature of permissions in your library – just wanted to check my assumption is correct.
Example code illustrating behaviour difference:
[HasPermission(SomeAdminPermission)]
public class AdminBaseController : Controller
{
}
public class SomeAdminController : AdminBaseController
{
// In conventional Identity Authorise this would be restricted by the base controller permission
public IActionResult Index()
{
return View();
}
}
Anyhow, many thanks for such a useful library – it looks to do much of the heavy lifting.
Hi 0blit,
Firstly, let me be clear when you say “HasPermissionAttribute doesn’t support inheritance”. I think you mean that you can only one Permission in a HasPermissionAttribute, while a AuthorizeAttribute can have multiple Roles, and if the user has any of the Roles, then the user has access. My Roles / Permissions approach can be summed up as “Roles are for humans, Permissions are for features”.
Back in the old ASP.NET MVC days I used Roles a lot and I really liked one word for a group of features. But when I build big apps Roles didn’t work so well, for instance:
I client wanted me you design a very large multi-tenant and they were adamant that an admin user could change roles on the fly. I came up the original Roles / Permissions approach, which I have significantly improved.
The key was to keep Roles as a way to define a group of features that a user can use – they are easy to understand for the admin person. Then I created “Permissions”, which is set of enums, where each permission controls access to a feature. In a big app you will have many hundreds of Permissions and each Role might have hundreds.
The key thing is a user can have many Roles, and ALL of the permissions in each Role are combined to a Permission claim – so this is where inheritance happens. And because the Permission enums can be stored as a Unicode char you can a thousand of permissions in a user’s Permission claim.
Sorry if that’s a bit long but I like to be clear.
PS. You might to look at a Permissions hierarchy question / answer for more on the design thoughts.
Hi Jon,
Thanks for the detailed reply and the linked hierarchy discussion.
The latter part of my question was indeed about defining multiple attributes. I understand your rationale and your hierarchy discussion is helpful. I find myself defining the same granular CRUD permissions you mention and I need to think more about this as a role.
The initial point I was trying to convey about inheritance was different. I was talking about the ‘scope’ of the Authorize vs HasPermissions attributes.
Specifically, HasPermission is defined as follows:
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, Inherited = false)]
public class HasPermissionAttribute : AuthorizeAttribute
This is in contrast to the underlying AuthorizeAttribute which is defined as:
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)]
public class AuthorizeAttribute : Attribute, IAuthorizeData
This Inherited difference is a nuance I wasn’t expecting and just wanted to draw your (and others) attention to it as it could have inadvertently left some of my controllers unsecured.
We’re possibly a little unusual but we use a number of base controllers in our application (which have basic authorize constraints applied to them). We then have other controllers inherit from these base controllers. In Identity the derived controllers would inherit the authorisation constraints of their base classes. In AuthP this inheritance is lost and the derived controller is left open unless implicitly tagged with its own HasPermission attribute.
I’ve fixed this in our codebase trivially by defining my own version of your HasPermissionAttribute (with Inherited set to true). I just thought it was worth people being aware of this difference.
Thanks once again for such useful library. I hope to be able to incorporate it into my projects.
Hi Jon thank you for the library, I always enjoy reading your articles. I have been trying out AuthP with a .net core 6 web site. I managed to get things working but am having a problem with
When I use this configuration, it prevents a user from registering and I can see an error in the Chrome debugger “HTTPS to have cookies sent to same-site subresources”.
I have tried a few variations of setting the cookie options (SameSite=none etc) but I am not able to get this to work. Do you have any suggestions?
Thanks…
Hi Nick,
Can you open a issue on the AuthP repo with your problem as I can’t look at this immediately. Also, can you clone the AuthP and try Example3, which has this refresh feature, and see if that has the same problem as yours.
Thanks
Hey John thanks for the library i am new to dotnet but really enjoyed to read your article and love to implement i have a problem like how we can configure Authpermission library with customeIdentityUser which is inherited from identity user. like i went through the example2webApi which is configured for IdentityUser but have seen there is some function available for custom identity user too but still there is some issue with it if you provide some function or update in example two it will be better
Hi Alkama,
The AuthP library can work with ASP.NET Core’s individual user accounts authentication handler with a custom user, but the IdentityUser must have a key of type string.
To add a custom user you need to use the AuthP’s registration method called IndividualAccountsAuthentication<TCustomIdentityUser>, where you provide your customised individual user accounts class.
I hope that helps.
Wow. Wish I had found this a while back. Very well done. I’m now trying to decide whether to toss away my work and use this, or soldier on with what I’ve got.
I am trying to set a global query filter based on your example. I’m using Azure B2C and then using an IClaimsTransformation implementation to add the permission claims I need.
What is happening, though, is the constructor for the DbContext is getting called before the claims transformation runs. So I can’t inject the tenant id into the DbContext because I don’t have it yet.
Any ideas on how to get the ClaimsPrincipal updated before the DBContext constructor? I’m using AutoFac for DI. Great article, also saw the latest .Net Community Standup. Very useful stuff.
Thank you.
Wait. I may have found it. I’m using the same DBContext inside the ClaimsTransformation implementation. Which means it’s being constructed before my claims transformation executes. Oof. Can’t test it now, I’ll let you know.
Hi Bill,
I expect you have fixed this now, but here are some things I learnt building apps like this:
The admin data, like the user and tenants, aren’t like the tenant data – they don’t have a query filter on them. In my library I have a DbContext for the admin data (with no query filters) and another DbContext for the tenant data (with a query filter). EF Core allows me to have multiple DbContexts to a single database, but you MUST add a named MigrationHistoryTable for each DbContext so that each part can be migrated separately – see this line in the AuthP register code.
You also must understand that the userid can be null if a user isn’t logged in. This means you need to cover that case. I use .NET DI (used to use AutoFac, but .NET DI is quicker) and this class gets the logged-in user’s DataKey claim – NOTE: HpptContext is null on startup / background and the User can be null if there isn’t a logged-in user.
Thanks for the additional insight and reply. I was texting you from an airport lounge in Honduras when the answer popped into my head.
I’ll be back at my regular workstation in a week or so and let you know how your sound advice worked out.
Hi Jon
Continuing with this example, if I wanted to add a “global” permission for “Sales”, in order to assign that single permission, to a Sales Administrator, without having to assign each one of the permissions individually, is it possible? any ideas? Or would I have, as I said, assign the three previous permissions… when I could only assign one permission.
Excuse me for my english
Thanks for your time
Hi Julio,
The idea the AuthP library is that you create Permissions for the various sales features you want to control and then you create a Role called “Sales” containing the permissions for that Role. This gives more control of your features, for instance you could create “Sales Manager” Role which has the “SalesReturn” Permission while the “Sales” Role doesn’t have that “SalesReturn” Permission.
I hope that helps you.
Thank you very much
PS. Have a look at this section about editing Roles which has a screenshot showing how a Role is defined by selecting the Permissions for that Role.
What a great library !
I wonder if there’s a way to avoid the generation of AspNetCore.Identity.ApplicationCookie?
I know it not being used afterwards, but it does not feel right sending unnecessary auth related data.
I was looking for a way to “undo” the built in “addCookie” that comes with AddIdentity
Hi Jonathan,
The AuthP library needs an ASP.NET Core authentication provider to validate the user that logs in. I explain this section of a newer about multi-tenant apps (but its true for any AuthP usage)
If you use ASP.NET Core’s individual users account authentication provider, then you will need the cookie. The other options are use a JWT token (which AuthP supports – see this documentation) or something like Azure Active Directory (see this video and Example5 in the AuthP repo) for authentication. In fact AuthP can work with any ASP.NET Core authentication provider that creates a userId as a string.
I hope that clears up you question.
Hi Jon,
Thank you for the prompt reply!
I actually followed your documentation and using JWT token. Nevertheless, a cookie is still being being generated and sent back to the client whenever a user is signed in.
The cookie is not used for further authentication or authorization in subsequent requests, but is still keeps traveling and I was looking for a way to eliminate that completely.
Hi Jonathan,
That’s strange! I ran example2 (JWT Token) and as you said, when I logged in a cookie called “.AspNetCore.Identity.Application” was created. I have no idea why that is there!
I think you would have to ask an ASP.NET Core expert – I’ll reach out to Andrew Lock, who write the book “ASP.NET Core in Action”. I’ll let you know if he comes up with anything.
Hi,
That’s exactly the case.
I actually know where it is coming from (but haven’t figured out how to avoid that).
aspnetcore .AddIdentity is calling internally to .AddCooike
I’m looking for a way to “remove cookie” after calling .AddIdentity.
any tip would be great 🙂
I asked Andrew Lock and here is his answer.
So, now you know from the expert!
Thank you!
I really love your on AuthPermissions.AspNetCore.
I made an API that uses the refresh tokens and tested it with Swagger.
Do you have example code how I can access this API from an MVC project, and how I can ask a new token when it expires?
Thanks
Hi Jo,
I assume you have looked at the JWT Token refresh explained docs which has a nice diagram that explains how the refresh works.
Normally JWT Tokens are used with frontend libraries like angular, react etc. If you want to use it with MVC you are going to have to hold the JWT token in your Razor pages (most likely in your _layout.cshtml file). Then you need to capture the OnAuthenticationFailed event when the JWT Token times out.
If you look at the Example2′ Startup code at line 71 to 78 you will see I catch the OnAuthenticationFailed event to send back a useful header for a frontend library. You could use that event to create a new JWT Token.
I hope that gives you some ideas to look at.
Also, have a look at the video I created about the JWT Token refresh using the AuthP library.
Hi Jon
You have valued the option to include the use of http request routes, request body and query chain parameters for authorization in your library.
Thank you very much.
Hi Andres,
I’m not sure what you are asking. The data needed for authorization are in the user’s claims and come from either an authorization cookie or a JWT Token.
Hi Jon
I was thinking about something like this
https://stackoverflow.com/questions/60553385/global-resource-authorization-based-on-route-value
Thanks
The AuthP library doesn’t use that approach. If you wanted to do that, then it would work, but it wouldn’t link to any of the AuthP features.
Thanks for your time
Hi Jon
I really love your articles. I know you have planned a version for PostgreSQL. When do you plan to release this update? It would be very useful, so you don’t have to rewrite a lot of code.
Thank you very much.
Hi Julio,
I used this twitter pole to get feedback from users and they clearly said they wanted more multi-tenant features. This is nearly finished, but there is still a LOT of documentation and examples to write.
PostgerSQL come next, but it won’t be out for a month or so.
OK
I need multi-tenants too, and I have learned a lot from your articles.
I am waiting for the new version of the library with Postgresql for my projects.
Thanks for your time
Hi,
I really love your work and this is a real time saver. Is it somehow possible to use your library as a sort of identity provider for other .net core webapi’s and for example angular frontends connected to these webapi’s?
With kind regards,
Frank
Hi Frank,
There are lots of ways your question can be interpreted. For instance are you thinking of something like IdentityServer4, which is a separate application, or whether you want to use the AuthP library in the backend of your application. The IdentityServer4 approach would have some problems and putting theAuthP library in the backend is the recommended way. Let me give you some reasons for that.
The AuthP library relies on an enum which I call Permissions. Two parts of the library uses the Permission enum:
This means that the main authentication is done in the backend with claims and policy based authorization. However I realise the front-end needs to know about the user’s Permissions so the library has a method PermissionsFromUser (see docs on this) which provides the names of the Permissions to the front-end, which allows you to use the permissions in the front-end too.
My problem with the IdentityServer4 approach is you are sending out a Unicode string containing the values of the user’s Permissions, but your WebAPI applications may not have the Permissions enum definition to check against. If you can get over that then the IdentityServer4 approach.
Sorry for the long reply, but I couldn’t be sure what you want to do so instead it have explained how the AuthP Roles work and you can decide whether you can use it.
All the best on your project.
Thank you for your fast reply! I would indeed try to use it as a IdentityServer4 kind of way. I will investigate if i can create an separate .net core library (with the permissions) which i can share between my webapi’s and the separate ‘identity application’ so the same permissions enum will be available for both applications with the correct versioning.
OK, that makes sense. If you get something to work do write about it – I would be interested in how you did it.
PS. I have written about an approach where I break up a big solution into separate NuGet packages. You don’t really need this level of complexity, you only need base NuGet package to make it work.
I get the separation between Roles and Permissions. But is it not just moving the problem of hardcoding to the PermissionEnum level? Isn’t the code still littered with PermissionEnum.XYZ all over? How can it be made more dynamic?
Hi Alain,
I hear you, but my experience is that the developer writes the Permissions when they add a new feature and the Permissions only get changed if the feature changes, which needs a new deployment anyway.
Roles are a business-level issue and are defined by a senior IT / management person.
Roles can change as the business expands, say adding a new Role / Roles for a new position in the business. Also, its nice to try a new feature with a few users and then add that feature to more users once its found useful, which would have been a bit of pain with the normal Role approach.
I created this approach for a client because they were adamant that they wanted to change the Roles that a user has via an admin page. Also, lots of people liked this approach (> 400 stars) so much that I have build a library called AuthPermissions.AspNetCore to automate this approach and other features later in the series.
Thank you for sharing this article and opensource solution. Authentication and authorization processes are always time-consuming and an issue that needs attention. We have a subject that is open to development. QR Code sign in, passwordless (for example shazam), select with tenant.
Hi fatihozturk,
This library adds features at the authorization stage and can work with any ASP.NET Core Authentication provider that returns a string as the UserId (it does need an email and/or username too to show in the admin services).
But from what you say I’m not sure you need Authentication and Authorization, as anyone can access your application just going to the url.
Does it work with MySql?
Hi Jacques,
At the moment (V1.2.0) this library only works with SQL Server. I plan to add other database types in the future, but at the moment on PostgreSQL.
You might like to look at the part 7 of the original articles where I describe how to build your own version. That’s takes more work, but it means it works with any database that EF Core supports.
Thank you for creating and sharing this. It is very timely for me, especially the multi-tenant stuff.
Hi Adam,
Glad its useful. I should warn you that I’m still improving/changing the multi-tenant admin services, which its why I haven’t provided the multi-tenant admin documentation. There will be a new version of this library in two to four weeks time with the improved multi-tenant admin services with updated documentation.
In the meantime here are some old articles that might give you some ideas about building multi-tenant apps.
The AuthP library uses the same approaches to multi-tenant, but has much more built-in code to help you.
Great job, thanks.
Can this be used in an MVC5 application?
Hi Jeff,
Sorry, but it uses features only found in ASP.NET Core.