Authorization

Learning Goals

• Understand the difference between user roles and user claims
• Implement role and claim level authorization using ASP.NET Core Identity

Roles and Claims

As we can see in the ERD of our IdentityMessageBoard application, our database is configured for roles and claims. Both can be used for authorization, but what is the difference?

Claims - A claim is a piece of information about a user. It represents attributes or characteristics of the user like their age, email, or other customer data. Claims are flexible because you can define custom claims that could change if the user’s characteristics change.

Roles - Roles are a way to group users based on common responsibilities within an application. Roles simplify authorization management by allowing you to define permissions and access control at a higher level. For example, you can create roles like “Admin,” “Editor,” or “User,” and then define what each role can or cannot do within the application.

So… both roles and claims help us control what a user can do. Seems pretty similar; let’s take a look at a real-world example to help clarify.

Roles Based Authorization with Identity

Setup

We will be building off of our IdentityMessageBoard from yesterday. If you need a new version, you can checkout the authentication-finished branch from the starter repository.

Registering Roles and Authorzition

In order to use roles to authorize users, we need to register Roles in our application services, and configure the app to use authorization:

using IdentityMessageBoard.DataAccess;
using Microsoft.EntityFrameworkCore;
using Microsoft.AspNetCore.Identity;
using IdentityMessageBoard.Models;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllersWithViews();

builder.Services.AddDbContext<MessageBoardContext>(options =>
    options.UseNpgsql(builder.Configuration.GetConnectionString("IdentityMessageBoardDb")).UseSnakeCaseNamingConvention());

builder.Services.AddDefaultIdentity<ApplicationUser>(options => 
    options.SignIn.RequireConfirmedAccount = true)
        .AddRoles<IdentityRole>() // this is new!
        .AddEntityFrameworkStores<MessageBoardContext>();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization(); // make sure you have this line

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.MapRazorPages();

app.Run();

And, if you can believe it… that’s pretty much all the setup! Now you are ready to start using Roles!

        [Authorize(Roles = "Admin")]
        public IActionResult AllMessages()
            ...

Add Roles to Database and Existing Users

In order to see Role based authenticaion in action we need to:

• Create Roles
• Assign Roles to Users

In the past, we have created forms to add records to our database through a web application - why might we not want to do that for roles? At some point, a role will have to be assigned by a developer.

Think of an application like Amazon. If you are a merchant on Amazon, you must be registered with the company. Once registered, you may be able to create your own employee-users, but the initial setup will always be done by Amazon (or, a developer at Amazon). So, it will be common to manage Roles from the database - using SQL!

Add Admin Role to Database

INSERT INTO "AspNetRoles" (id, name)
VALUES (1, 'Admin');

INSERT INTO "AspNetUserRoles" (user_id, role_id)
VALUES ('<a user id>', 1);

When you have configured an admin role and assigned it to a user, that user should be able to see the All Messages View!

Claims Based Authorization

Compared to Roles based authorization, claims are a bit trickier to manage. By definition, claims are things that describe a user (like age), that can change over time.

Out of the box, claims are stored as key/value pairs associated with specific users. This could be ok for things like ‘birthdate’ where the key value pair could be "birthdate" : "01/13/1999". In this example, the age of a user will change, but the underlying data will not.

But consider a more complex example. What if we wanted to give users a different experience based on the number of times they interacted with our application. Maybe we want them to have sparkly font if they have visited the site more than 100 times. In that case, they key/value pair becomes more cumbersome - we would have to update that database record every time a user visits our page.

The more we are manipulating records, the more likely we are to have developer-errors impact our clients.

So, while there is funtionality included in the Identity Framework to handle Claim based authorization, it might not be the best.

Checks for Understanding

• Imagine you are talking to someone in Mod3 - they have just built their first MVC web application. How would you explain the differences between Authentication and Authorization?
• In your own words, what is a user claim?
• Could a user have multiple roles? Why or Why not?