Claim base approach in ASP.NET Core

Question

We would like to build a permission-based app. Where an admin can set things up such as what a user can or not do.

Say, in Organization-A, an admin can set User1 to only CreateTools, EditTools and ViewTools. User2 can only do CreateTools and ViewTools.

While in Organization-B, an admin here sets John to CreateTools, ViewSales (for some reason, the admin here don't allow John to ViewTools)

As you noticed, these are not roles for a user but permissions for every user.

Furthermore, links (anchor tags) on the page will be displayed base on their permissions. Say, User1 logs in, he can only see links for CreateTools, EditTools and ViewTools

We think that, for us, at least the happy path (Or will this be painful? Please comment on this). Since we'd like to expand this on every organization that would like to use our app and just help them set permissions to their liking.

The way we intend to build this is thru a Web Api (ASP.NET Core) which will be consume by a Client (Browser. A SPA application)

What I've tried before, using ASPNET MVC 5 and have it scaffold with identity and build the app from there. But the thing that was role-base.

I've read about claim-base approach and saw this blog (very helpful) but its not obvious for me on how to implement this using a database and identity. Also read about how JWT works.

For us this is the crucial part but once we get this started on how it works. We'll build the app from there.

Any tutorials, links, blogs. Comments or suggestions will be very helpful. Or terms that we should be researching about.

Answer 1

Personally I would look at the open source project IdentityServer, the currently released version is version 3, but version 4, hosted in Asp.Net Core, has recently achieved Release Candidate status.

Architecture Overview

The IdentityServer project would provide you with a Security Token Service (STS), which can then be used to provide token based protection to resources, such as MVC pages, Web API calls, mobile applications etc.

Clients, Scopes and Claims define the applications that can use the STS for token based authentication, the type of information that they can request, and the actual Claims (such as users name, email address, etc); these Claims are stored by an Identity Provider with a database backend, which is separate from the STS itself.

The STS is tasked with providing implementations of two standards, OpenID Connect and OAuth2.

The STS will query the Identity Provider in order to authenticate a user, and construct a token that can contain Claims related to that user. These tokens are decoded by middleware configured in each Client, and the extracted Claims can be utilised to authorize access, optionally in conjunction with ASP.Net Core Policies, and together this approach will provide you with a comprehensive token and Claim based security architecture.

Reference material, samples and walkthroughs

I would strongly suggest you begin by examining the documentation, and samples, for IdentityServer3, and perhaps more specifically IdentityServer4.These explain the terminology, and contain comprehensive samples and walkthroughs for implementation.

Dominick Baier, co-author of IdentityServer, provides an overview of OpenID Connect and OAuth2 here.

Once you understand how token based authentication works, you should move on to examine how to configure an Identity Provider that supports your scenario.

There are multiple Identity Provider projects available to plug in to IdentityServer3, including ASP.Net Identity. Brock Allen (also co-founder of IdentityServer) has created the Membership Reboot and Identity Reboot projects for storing Claims etc, and Identity Manager, which provides an administration portal for user management. An explanation of each can be found at the following links:

Identity Reboot by Brock Allen

Introducing Identity Manager by Brock Allen

Identity Manager walkthrough by Scott Brady

IdentityServer4 currently supports ASP.Net Core Identity, which can, if required, be customised to support multi-tenancy.

A comprehensive set of IdentityServer4 Quickstarts can be found here, including specifically the use of ASP.Net Core Identity and Entity Framework to store data in SQL Server here.

Full source code for each of the Quickstarts is available on GitHub here.

Authorization Policies

With regards to authorisation, I recommend AspNetAuthorizationWorkshop on GitHub for explanations of various aspects of Claims based authentication and authorisation, specifically including the use of new ASP.Net Core Authorization Policies that can specify fine-grained rules based on Claims, by examining any combination of the set of an individual users Claims to see if they meet the security criteria - and, optionally, traditional Roles, which can also be applied to reduce administration overhead.

Wrapping Up

In summary, you could follow the above recommendations to create:

1. A database repository of user Claims, based on ASP.Net Core Identity.

2. A Security Token Service for authenticating the user, and providing a token containing the Claims, using IdentityServer.

3. A set of Authorization Policies that evaluate rules against a users Claims (and additionally Roles if you choose a hybrid approach).

Security is a complex area, that at first can appear quite daunting. However, both Dominick Baier and Brock Allen are recognised industry experts, who provide a good series of introductions and code samples, and their project, IdentityServer, is recommended by Microsoft for claims based authentication.