Authorization is the step that determines what a user is able to do and see on your applications. For example, an administrative user is allowed to create a document library, add documents, edit documents, and delete them. A non-administrative user working with the library is only authorized to read the documents.
Authorization is independent from authentication. However, authentication must precede authorization because authentication verifies "who are you?" where as authorization grants you "What are you allowed to do and see?"
Let us understand different types of network security authorizations possible in ASP.NET Core
I. Simple authorization in ASP.NET Core:Let us understand different types of network security authorizations possible in ASP.NET Core
Simply put, simple authorization grants access to all authenticated users. Let us understand this using couple of scenarios.
[I.A] Authorizing all the authenticated users for a class: Let examine below code snippet. As "[Authorize]" is used before the class "AccountController", any authenticated user can access Login() and Logout() functions.
/* Code snippet starts */
[Authorize]
public class AccountController : Controller
{
public ActionResult Login()
{
}
public ActionResult Logout()
{
}
}
/* Code snippet ends */
[I.B] Authenticated users only are authorized to perform certain actions: Let us examine below code snippet. Here, "[Authorize]" is used before the function "Logout()". This means, only authenticated users can perform the action "Logout()". Unauthenticated users can perform "Login()" action, but they cannot perform "Logout()" action.
/* Code snippet starts */
public class AccountController : Controller
{
public ActionResult Login()
{
}
[Authorize]
public ActionResult Logout()
{
}
}
/* Code snippet ends */
/* Code snippet starts */
public class AccountController : Controller
{
public ActionResult Login()
{
}
[Authorize]
public ActionResult Logout()
{
}
}
/* Code snippet ends */
II. Role-based authorization in ASP.NET Core:
It grants access for the specific roles that the users are mapped with. Let us understand this using couple of scenarios.
It grants access for the specific roles that the users are mapped with. Let us understand this using couple of scenarios.
[II.A] Authorizing all the users mapped to a role: Let examine below code snippet. All the members that are mapped to the role "Administrator" can perform all the actions defined in below class.
/* Code snippet starts */
[Authorize(Roles = "Administrator")]
public class AdministrationController : Controller
{
}
/* Code snippet ends */
[II.B] Authorizing different actions to different roles: In below code snippet, members of the role "Administrator" and "PowerUser" can perform the action "SetTime()" where as members of the role "Administrator" can only perform the action "ShutDown()".
[Authorize(Roles = "Administrator, PowerUser")]
public class ControlPanelController : Controller
{
public ActionResult SetTime()
{
}
[Authorize(Roles = "Administrator")]
public ActionResult ShutDown()
{
}
}
[Authorize(Roles = "Administrator, PowerUser")]
public class ControlPanelController : Controller
{
public ActionResult SetTime()
{
}
[Authorize(Roles = "Administrator")]
public ActionResult ShutDown()
{
}
}
III. Policy-based Authorization in ASP.NET Core
The need for Policy-based Authorization: Authorization using roles for protecting resources from unauthorized access have been in use for quite some time. However, on the field, we come across the situations where we can have multiple variations of specific role. For example, initially we define a role called "Administrator". Later we may come across the variations like "CustomerAdministrator", "ReportsAdministrator", "SuperAdministrator" and so on. Similarly our initially designated "manager" role may get unfolded like "project manager", "program manager", "general manager" etc. As the number of these roles increases significantly, it becomes extremely difficult to effectively handle the roles. Here’s exactly where a policy-based authorization model comes in. It grants access based on the policy requirements set.
An authorization policy consists of one or more requirements. It's registered as part of the authorization service configuration, in the Startup.ConfigureServices method:
The need for Policy-based Authorization: Authorization using roles for protecting resources from unauthorized access have been in use for quite some time. However, on the field, we come across the situations where we can have multiple variations of specific role. For example, initially we define a role called "Administrator". Later we may come across the variations like "CustomerAdministrator", "ReportsAdministrator", "SuperAdministrator" and so on. Similarly our initially designated "manager" role may get unfolded like "project manager", "program manager", "general manager" etc. As the number of these roles increases significantly, it becomes extremely difficult to effectively handle the roles. Here’s exactly where a policy-based authorization model comes in. It grants access based on the policy requirements set.
An authorization policy consists of one or more requirements. It's registered as part of the authorization service configuration, in the Startup.ConfigureServices method:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddAuthorization(options =>
{
options.AddPolicy("RequireElevatedRights", policy => policy.RequireRole("SuperAdministrator", "ReportsAdministrator","CustomerAdministrator"));
});
}
Then, instead of specifying roles in the [Authorize] attribute, specify the policy you want to assert:
[Authorize(Policy = "RequireElevatedRights")]
public class ChannelAdministrationController: Controller
{
}
{
services.AddMvc();
services.AddAuthorization(options =>
{
options.AddPolicy("RequireElevatedRights", policy => policy.RequireRole("SuperAdministrator", "ReportsAdministrator","CustomerAdministrator"));
});
}
Then, instead of specifying roles in the [Authorize] attribute, specify the policy you want to assert:
[Authorize(Policy = "RequireElevatedRights")]
public class ChannelAdministrationController: Controller
{
}
and that’s all!
As you can see, the name of the policy is RequireElevatedRights, and any user with either “SuperAdministrator” or “ReportsAdministrator” or "CustomerAdministrator" role will be authorized to invoke any action of the ChannelAdministrationController.
As you can see, the name of the policy is RequireElevatedRights, and any user with either “SuperAdministrator” or “ReportsAdministrator” or "CustomerAdministrator" role will be authorized to invoke any action of the ChannelAdministrationController.
IV. Claims-based authorization in ASP.NET Core
When an identity is created it may be assigned one or more claims issued by a trusted party. A claim is a name value pair that represents what the subject is, not what the subject can do. For example, you may have a driver's license, issued by a local driving license authority. Your driver's license has your date of birth on it. In this case the claim name would be DateOfBirth, the claim value would be your date of birth, for example 8th June 1970 and the issuer would be the driving license authority. Claims based authorization, at its simplest, checks the value of a claim and allows access to a resource based upon that value. Thus, it grants access based on appropriate claim values provided within a particular policy.For example if you want to avail senior citizen concession in railway journey the authorization process might be:
The Railway ticket collector officer would evaluate the value of your date of birth claim and whether they trust the issuer (the driving license authority or voter card or social security number or Aadhar card etc.) before granting you access.
Adding claims checks: Claims requirements are policy based, the developer must build and register a policy expressing the claims requirements. First you need to build and register the policy. This takes place as part of the Authorization service configuration, which normally takes part in ConfigureServices() in your Startup.cs file.
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddAuthorization(options =>
{
options.AddPolicy("SeniorCitizen", policy => policy.RequireClaim("DateOfBirth"));
});
}
In this case the "SeniorCitizen" policy checks for the presence of an "DateOfBirth" claim on the current identity.
Let us see below example. The AuthorizeAttribute attribute can then be applied to an entire controller, in this instance only identities matching the policy will be allowed access to any Action on the controller.
[Authorize(Policy = "SeniorCitizen")]
public class SeniorCitizenConcession: Controller
{
public ActionResult AllowConcession()
{
}
public ActionResult IssueLowerBirthSeat()
{
}
}
V. Resource-based authorization in ASP.NET Core
We saw how you could create a policy that protects a resource based on properties of the user trying to access it. We used Claims-based identity to verify whether they had the appropriate claim values, and granted or denied access based on these as appropriate.
In some cases, it may not be possible to decide whether access is appropriate based on the current user's claims alone. For example, we may allow users to edit documents that they created, but only access a read-only view of documents created by others. In that case, we not only need an authenticated user, we also need to know who created the document we are attempting to access.
Resource based authorization will grant "read/write/edit" access for the authors who created the documents and grant "read" access for those documents that they have not authored.Simply put, it grants access to authenticated users based on additional attributes set for the resources that they need access to. To learn how to implement this authorization, click here
We saw how you could create a policy that protects a resource based on properties of the user trying to access it. We used Claims-based identity to verify whether they had the appropriate claim values, and granted or denied access based on these as appropriate.
In some cases, it may not be possible to decide whether access is appropriate based on the current user's claims alone. For example, we may allow users to edit documents that they created, but only access a read-only view of documents created by others. In that case, we not only need an authenticated user, we also need to know who created the document we are attempting to access.
Resource based authorization will grant "read/write/edit" access for the authors who created the documents and grant "read" access for those documents that they have not authored.Simply put, it grants access to authenticated users based on additional attributes set for the resources that they need access to. To learn how to implement this authorization, click here
VI. View-based authorization in ASP.NET Core
Using "View-based authorization in ASP.NET Core", a developer can show, hide, or otherwise modify a UI based on the current user identity. To learn how to implement this authorization, click here
Using "View-based authorization in ASP.NET Core", a developer can show, hide, or otherwise modify a UI based on the current user identity. To learn how to implement this authorization, click here