The document discusses claims-based authorization, which verifies a user's identity through claims issued by trusted parties, such as their date of birth on a driving license. It explains how developers can implement policies to enforce claims requirements in an ASP.NET environment, allowing certain actions to be restricted based on these claims. The document also covers multiple policy evaluations and the option for custom policy handlers to create more complex authorization scenarios.

1. Authorization (Part II)
Claims Based Authorization
On creating an identity it might be assigned one or more claims that are issued by a
trusted party. A claim is a name-value pair that depicts what the subject is, not what the
subject can do. E.g. you might have a Driving License, issued by a local driving
authority. Your driver’s license has your DOB on it. In this case, the claim name would
be DOB , the claim value would be your DOB, e.g. 8th June 1970 and the person who
issued it would be the driving license authority. Claims based authorization in simple
words, access the value of a claim and permits access to a resource that is based upon
the value. For example, if you want access to a night club the permission process might
be:
The security officer at the door would evaluate the value of your date of birth claim and
whether they trust the issuer before granting you access.
An identity can contain multiple claims with multiple values and has multiple claims of
the same type.
Adding claims checks

2. Claim based authorization checks are declarative. The developer fixes them within their
code, against a controller or an action within a controller, specifying claims which the
current user should possess, and optionally the value the claim must hold to access the
requested resource. Requirements of claims are policy based, the developer should build
and register a policy expressing the claims requirements.
The simplest type of affirmation sees for the existence of a claim and does not check the
value.
First, you need to create and list 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("EmployeeOnly", policy =>
policy.RequireClaim("EmployeeNumber"));
});
}
In this case the policy EmployeeOnly, checks for the presence of an EmployeeNumber
claim of the current name.
Then you can apply the policy using the Policy property on the AuthorizeAttribute
feature to define the policy name;
[Authorize(Policy = "EmployeeOnly")]
public IActionResult VacationBalance()
{

3. return View();
}
The AuthorizeAttribute feature can be applied to an entire controller, in this instance,
only names matching the policy will be allowed an entry to any Action on the controller.
[Authorize(Policy = "EmployeeOnly")]
public class VacationController : Controller
{
public ActionResult VacationBalance()
{
}
}
If you have a controller that is covered by the AuthorizeAttribute feature, but want to
permit anonymous access to particular actions you apply the AllowAnonymousAttribute
feature;
[Authorize(Policy = "EmployeeOnly")]
public class VacationController : Controller
{
public ActionResult VacationBalance()
{
}
[AllowAnonymous]
public ActionResult VacationPolicy()
{
}
}

4. Most claims come with a value. You could specify a list of permitted values when
creating the policy. The following example is only applicable for employees whose
employee number was 1, 2, 3, 4 or 5.
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddAuthorization(options =>
{
options.AddPolicy("Founders", policy =>
policy.RequireClaim("EmployeeNumber", "1", "2", "3", "4", "5"));
}
}
Multiple Policy Evaluation
If you apply many policies to a controller or action then all policies must progress before
access is granted. For example;
[Authorize(Policy = "EmployeeOnly")]
public class SalaryController : Controller
{
public ActionResult Payslip()
{
}
[Authorize(Policy = "HumanResources")]
public ActionResult UpdateSalary()
{

5. }
}
In the above example, any name that fulfills the policy of EmployeeOnly can access the
Payslip action as that policy is made compulsory on the controller. But in order to take
up the UpdateSalary action, it (identity) must please both the EmployeeOnly and the
HumanResources policy.
If you need more complicate policies, e.g. taking a DOB claim, calculating an age from
it then checking the age is 21 or more than that you need to write custom policy
handlers.
If you want to learn ASP.Net and improve yourself in .NET training, CRB Tech
Solutions would be of great help for you. Join us with our advanced program in
ASP.Net course.
Stay tuned to CRB Tech reviews for more technical and other resources.