Authorization determines what each application or service user is allowed to access. Authorization and authentication often work together, but these are two separate processes. Before being authorized to access and perform specific actions, the user must undergo authentication (a mechanism for proving a user’s identity).
When logging into a system, a user must provide credentials like a username and password to authenticate. Next, the authorization process grants rights. For example, an administrative user can create a document library to add, edit, and delete documents, while a non-administrative user can only read documents in the library.
ASP.NET Core provides a simple, declarative policy-based authorization model. The authorization mechanism is expressed in requirements, while handlers evaluate a user’s claims against these requirements. It allows setting imperative checks according to simple policies that evaluate the user identity and the requested resource’s properties.
Let’s cover the four main ways to implement authorization in ASP.NET – simple, role-based, claims-based, and policy-based.
In this article:
AuthorizeAttribute and its associated parameters manage authorization in ASP.NET Core. The [Authorize] attribute, when applied to a controller, Razor, or action page, restricts access to such users who have been authorized. The following code restricts unauthorized users from accessing the Account_Controller:
[Authorize] public class Account_Controller : Controlle { public Result_of_Action Signin() { } public Result_of_Action Signout() { } } To assign authorization to a specific action instead of a controller, use the AuthorizeAttribute attribute. public class Account_Controller : Controller { public Result_of_Action Signin() { } [Authorize] public Result_of_Action Signout() { } } The Signout operation is now protected and only accessible to authenticated users. The AllowAnonymous attribute can enable access to specific operations, even to users who have not yet authenticated. For example: [Authorize] public class Account_Controller : Controller { [AllowAnonymous] public Result_of_Action Signin() { } public Result_of_Action Signout() { } }
It would restrict access to the Account_Controller to authorized users, excluding the Signin function, which may be performed by anyone irrespective of their authentication.
Role-based authorization allows you to assign and control roles granularly. Once you create an identity in ASP.NET Core, it can belong to one or several roles. For example, one user identity can belong to the user and administrator roles, while another belongs only to the user role.
You can create and manage roles according to the underlying store of the authorization process. However, roles are exposed to developers only through the IsInRole method of the ClaimsPrincipal class.
A role can be a claim, but not all claims can be roles. The identity issuer determines whether a role can be a set of users allowed to apply claims for group members. Claims provide information about an individual user. Using roles to add claims to users can create confusion between users and their claims, which is why SPA templates are not designed around roles.
You can register role-based authorization services in Program.cs by calling AddRoles with the role type in the application’s identity configuration. Here’s an example of using IdentityRole as the role type:
builder.Services.AddDefaultIdentity<IdentityUser>( ... ) .AddRoles<IdentityRole>() ...
A role-based authorization check is declarative, allowing you to specify the roles a user must belong to access a requested resource. You can apply role-based authorization checks to Razor Pages, controllers, and actions within controllers. However, you can’t apply them at the Razor Page handler level – only to the Page.
The following code limits access to actions on the AdministrationController to any user belonging to the administrator role:
[Authorize(Roles = "Administrator")] public class AdministrationController : Controller { public IActionResult Index() => Content("Administrator"); }
ASP.NET Core lets a trusted part assign one of several claims to a single identity. A claim represents a name-value pair that indicates what a subject is rather than what a subject can do. Claims-based authorization allows access to a resource according to the claim’s value. An identity can include several claims with different values and several claims of the same type.
A claim-based authorization check is declarative. You can apply it to Razor Pages, controllers, and actions in controllers. You can’t apply it at the Razor Page handler level – only to pages.
The policy-based authorization mechanism in ASP.NET Core is intended to isolate authorization and application functionality. A policy is a structure of predetermined constraints that the user must meet.
The most fundamental policy is that the user must be authorized, while role association is one of the most used requirements. Another commonly used requirement is having a specific claim or a claim with a specific value.
Requirements are user identity assertions that attempt to access valid methods. For example, use the following code to implement a policies object:
var policies = new AuthorizationPolicyBuilder() .AddAuthenticationSchemes("Cookie, Bearer") .RequireAuthenticatedUser() .RequireRole("Admin") .RequireClaim("editor", "contents") .RequireClaim("level", "junior") .Build();
Requirements are gathered by the builder object, which then constructs the policies instance using several extension methods. As shown above, requirements affect authentication status, roles, schemes, and any combination of claims read from the authentication cookie or bearer token.
Frontegg offers seamless Role-Based Access Control (RBAC) for ASP.NET usage. Not only does it simplify and optimize user management, it also helps elevate security levels. SaaS companies can now implement a least-privilege policy by specifying end-users and admins for tighter access control. All of this can be managed in a self-served way via a centralized dashboard.
Another key aspect in B2B SaaS applications today is complexity.
User management is getting more and more complicated due to the quick scaling up of businesses, which is bringing new use cases to the frame. This means vendors need to handle more and more roles and permissions, which is stressing out dev and IT teams. This is exactly what Frontegg helps eliminate, while allowing development teams focus on what really matters – innovation.
Start For Free
