{"id":56700,"date":"2021-01-27T08:00:03","date_gmt":"2021-01-27T07:00:03","guid":{"rendered":"https:\/\/code-maze.com\/?p=56700"},"modified":"2022-05-25T00:06:36","modified_gmt":"2022-05-24T22:06:36","slug":"using-roles-in-blazor-webassembly-hosted-applications","status":"publish","type":"post","link":"https:\/\/code-maze.com\/using-roles-in-blazor-webassembly-hosted-applications\/","title":{"rendered":"Using Roles in Blazor WebAssembly Hosted Applications"},"content":{"rendered":"

In this article, we are going to learn how to use Roles in Blazor WebAssembly Hosted applications for an additional level of security for both Blazor-Client pages and Blazor-Server controllers.<\/p>\n

To download the source code for this article, you can visit our Roles in Blazor WebAssembly Hosted Applications<\/a> repository<\/div>\n

If you want to learn more about Blazor WebAssembly, we strongly suggest visiting our\u00a0Blazor WebAssembly series of articles<\/a>, where you can read about Blazor WebAssembly development, authentication, authorization, JSInterop, and other topics as well.<\/p>\n

So, let’s start.<\/p>\n

Adding Roles in the Database<\/h2>\n

We have already created the Blazor WebAssembly Hosted project with applied authentication in our previous article<\/a>. So, we will just continue with the same project.<\/p>\n

First of all, we have to support roles for ASP.NET Core Identity. To do that, let’s modify the configuration in the Startup<\/code> class or the Program class if you are using .NET 6 and above<\/strong>:<\/p>\n

services.AddDefaultIdentity<ApplicationUser>(options => options.SignIn.RequireConfirmedAccount = false)\r\n    .AddRoles<IdentityRole>()\r\n    .AddEntityFrameworkStores<ApplicationDbContext>();<\/pre>\n
All we do here is use the AddRoles<\/code> method to include role services for ASP.NET Core Identity.<\/p>\n
Now, we have to add roles to the database. To do that, we are going to create a new class in the Data<\/code> folder:<\/p>\n
public class RoleConfiguration : IEntityTypeConfiguration<IdentityRole>\r\n{\r\n    public void Configure(EntityTypeBuilder<IdentityRole> builder)\r\n    {\r\n        builder.HasData(\r\n            new IdentityRole\r\n            {\r\n                Name = \"Visitor\",\r\n                NormalizedName = \"VISITOR\"\r\n            },\r\n            new IdentityRole\r\n            {\r\n                Name = \"Administrator\",\r\n                NormalizedName = \"ADMINISTRATOR\"\r\n            }\r\n        );\r\n    }\r\n}<\/pre>\n
Also, we have to include this class in the ApplicationDbContext<\/code> class and override the OnModelCreating<\/code> method:<\/p>\n
public class ApplicationDbContext : ApiAuthorizationDbContext<ApplicationUser>\r\n{\r\n    public ApplicationDbContext(\r\n        DbContextOptions options,\r\n        IOptions<OperationalStoreOptions> operationalStoreOptions) : base(options, operationalStoreOptions)\r\n    {\r\n    }\r\n\r\n    protected override void OnModelCreating(ModelBuilder builder)\r\n    {\r\n        base.OnModelCreating(builder);\r\n        \r\n        builder.ApplyConfiguration(new RoleConfiguration());\r\n    }\r\n}<\/pre>\n
After that, we are going to create our migration files and execute them to update the database:<\/p>\n
Add-Migration RolesAdded -o Data\/Migrations<\/code><\/p>\n
Update-Database<\/code>.<\/p>\n
As you can see, when we create new migration files, we use the -o<\/code> flag to specify the output folder.<\/p>\n
Finally, since we have a single user in the database, let’s attach an admin role to that user:<\/p>\n
INSERT INTO AspNetUserRoles \r\nVALUES ('UserId','Administrator RoleId')<\/pre>\n
Of course, you will use your id values for the existing user and the Administrator role.<\/p>\n
Implementing Roles in a Blazor WebAssembly Hosted Application<\/h2>\n
Now that we have roles configured and placed in the database, we can use that to protect our pages and actions.<\/p>\n
Let’s first modify the FetchData<\/code> component to allow the Administrator role only:<\/p>\n
@page\u00a0\"\/fetchdata\" \r\n@using\u00a0Microsoft.AspNetCore.Authorization \r\n@using\u00a0Microsoft.AspNetCore.Components.WebAssembly.Authentication \r\n@using\u00a0BlazorWasmHostedAuth.Shared \r\n@attribute\u00a0[Authorize(Roles\u00a0=\u00a0\"Administrator\")] \r\n@inject\u00a0HttpClient\u00a0Http<\/pre>\n
Then, we can do the same thing for the WeatherForecastController<\/code>:<\/p>\n
[Authorize(Roles\u00a0=\u00a0\"Administrator\")] \r\n[ApiController] \r\n[Route(\"[controller]\")] \r\npublic\u00a0class\u00a0WeatherForecastController\u00a0:\u00a0ControllerBase<\/pre>\n
What we want to do now is to modify the user registration logic to include the Visitor role as soon as we register a new user. To do that, we have to include the Register.cshtml<\/code> and Register.cshtml.cs<\/code> files in our project (add a new scaffolded item). We did the same thing in the previous article<\/a> with the Account\/Login page (Customizing Components<\/a> section), so in the same way, we can include the Account\/Register page.<\/p>\n
Once we have the Register page in our project, we can open the Register.cshtml.cs<\/code> file and modify the OnPostAsync<\/code> method to include the Visitor role for newly created users:<\/p>\n
...\r\nelse\r\n{\r\n    await _userManager.AddToRoleAsync(user, \"Visitor\");\r\n    await _signInManager.SignInAsync(user, isPersistent: false);\r\n    return LocalRedirect(returnUrl);\r\n}<\/pre>\n
Okay.<\/p>\n
Let’s start the app, register a new user, try to click Fetch data, and inspect the result:<\/p>\n
\"User<\/a><\/p>\n
We can see that the user with the Visitor role can’t access this page.<\/p>\n
If we do the same with the Administrator user (the one we already have in the database), we will see the same response. Well, that’s not what we expect.<\/p>\n
To see the reason for that, let’s remove the Roles<\/code> property from the [Authorize]<\/code> attribute in both FetchData<\/code> (client project) and WeatherForecastController<\/code> (server project) files.<\/p>\n
Also, we are going to add a bit more code to the FetchData<\/code> page to show user claims:<\/p>\n
<h2>Claims<\/h2>\r\n<AuthorizeView>\r\n    <ul>\r\n        @foreach (var claim in context.User.Claims)\r\n        {\r\n            <li><b>@claim.Type<\/b>: @claim.Value<\/li>\r\n        }\r\n    <\/ul>\r\n<\/AuthorizeView><\/pre>\n
At this point, we can start the app, log in with the admin user, and navigate to the FetchData page:<\/p>\n
\"Claims<\/a><\/p>\n
We can see there is no Role claim, and that’s the reason why both Administrator and Visitor can’t access the page.<\/p>\n
Now we can return the Roles<\/code> property in both files.<\/p>\n
Adding Roles to the Claims<\/h3>\n
To solve our problem with a role claim, we have to include it in the claim list. To do that, we are going to modify the ConfigureServices<\/code> method in the Startup<\/code> class  or the Program class in .NET 6 and above <\/strong>(the code we are adding is the same for .NET 5 or .NET 6 and above):<\/p>\n
services.AddIdentityServer()\r\n    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>(opt => \r\n    {\r\n        opt.IdentityResources[\"openid\"].UserClaims.Add(\"role\");\r\n        opt.ApiResources.Single().UserClaims.Add(\"role\");\r\n    });\r\nJwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove(\"role\");<\/pre>\n
Here we are using the Action<\/code> delegate parameter of the AddApiAuthorization<\/code> method to configure additional options. We add the role claim to user claims collection for both Identity resources and API resources. Also, we prevent the default mapping for roles in the JWT token handler.<\/p>\n
Now if we start the app, and log in as the administrator, we will be able to access the FetchData page and we will see the role claim in the claims list. Of course, we won’t be able to do that with the Visitor user.<\/p>\n
Additionally, if we don’t want to show the FetchData link for the non-administrator users, we can modify the NavMenu.razor<\/code> file:<\/p>\n
<AuthorizeView Roles=\"Administrator\">\r\n    <Authorized>\r\n        <li class=\"nav-item px-3\">\r\n            <NavLink class=\"nav-link\" href=\"fetchdata\">\r\n                <span class=\"oi oi-list-rich\" aria-hidden=\"true\"><\/span> Fetch data\r\n            <\/NavLink>\r\n        <\/li>\r\n    <\/Authorized>\r\n<\/AuthorizeView><\/pre>\n
Once we log in as a Visitor, we won’t be able to see the page link:<\/p>\n
\"Hidden<\/a><\/p>\n
Supporting Multiple Roles<\/h2>\n
Before we implement logic to support multiple roles, let’s add a new role for our admin user:<\/p>\n
INSERT INTO AspNetUserRoles \r\nVALUES ('UserId','Visitor RoleId')<\/pre>\n
Now, we can start the app, and log in as the Administrator:<\/p>\n
\"Multiple<\/a><\/p>\n
What we can see is that we are missing the FetchData menu even though our user should be able to see it.<\/p>\n
So, where is the problem?<\/p>\n
The problem is that IdentityServer sends multiple roles as a JSON array in a single role claim: role: [\"Administrator\", \"Visitor\"]<\/code>. So, what we need to do is to create a way to split this array into multiple role claims with a single role as a value.<\/p>\n
To do that, we are going to create a new factory class on the client-side and modify it:<\/p>\n
public class CustomUserFactory : AccountClaimsPrincipalFactory<RemoteUserAccount>\r\n{\r\n    public CustomUserFactory(IAccessTokenProviderAccessor accessor)\r\n        : base(accessor)\r\n    {\r\n    }\r\n\r\n    public async override ValueTask<ClaimsPrincipal> CreateUserAsync(\r\n        RemoteUserAccount account,\r\n        RemoteAuthenticationUserOptions options)\r\n    {\r\n        var user = await base.CreateUserAsync(account, options);\r\n        var claimsIdentity = (ClaimsIdentity)user.Identity;\r\n\r\n        if (account != null)\r\n        {\r\n            MapArrayClaimsToMultipleSeparateClaims(account, claimsIdentity);\r\n        }\r\n\r\n        return user;\r\n    }\r\n\r\n    private void MapArrayClaimsToMultipleSeparateClaims(RemoteUserAccount account, ClaimsIdentity claimsIdentity)\r\n    {\r\n        foreach (var prop in account.AdditionalProperties)\r\n        {\r\n            var key = prop.Key;\r\n            var value = prop.Value;\r\n            if (value != null &&\r\n                (value is JsonElement element && element.ValueKind == JsonValueKind.Array))\r\n            {\r\n                claimsIdentity.RemoveClaim(claimsIdentity.FindFirst(prop.Key));\r\n                var claims = element.EnumerateArray()\r\n                    .Select(x => new Claim(prop.Key, x.ToString()));\r\n                claimsIdentity.AddClaims(claims);\r\n            }\r\n        }\r\n    }\r\n}<\/pre>\n
So, we create a new class that inherits from the\u00a0AccountClaimsPrincipalFactory<\/code> class and overrides the CreateUserAsync<\/code> method. We use the AccountClaimsPrincipalFactory<\/code> class to enable a default implementation for converting a RemoteUserAccount<\/code> into a ClaimsPrincipal<\/code>. In the overridden CreateUserAsync<\/code> method, we extract the ClaimsIdentity<\/code> from the created user and call the MapArrayClaimsToMultipleSeparateClaims<\/code> method. In this method, we iterate through every property from the account’s AdditionalProperties<\/code> collection and if we find the value and that value is a JSON array, we map each element of the array as a separate claim.<\/p>\n
Finally, we have to register this custom factory in the Program<\/code> class:<\/p>\n
builder.Services.AddApiAuthorization()\r\n    .AddAccountClaimsPrincipalFactory<CustomUserFactory>();<\/pre>\n
Excellent.<\/p>\n
Now, we can test our solution.<\/p>\n
First of all, as soon as we log in as Administrator, we can see the FetchData menu. Once we navigate there, we can see the content and both roles:<\/p>\n
\"Multiple<\/a><\/p>\n
So, that’s all it takes to handle multiple roles for a single user.<\/p>\n
Conclusion<\/h2>\n
In this article, we have learned:<\/p>\n