DPS907 notes – Thu Nov 23

Continue the introduction to security topics for a web service. Coverage of claims, and their implementation and use in a web service.

 

Test today

The weekly test will be done sometime during the class timeslot.

Also, keep in mind that the test questions will cover all of this weeks topics, from Tuesday and from today.

 

Code examples reminder

The GitHub code example repository for this week, has assets that support this topic.

 

A re-introduction to claims

It is likely that you worked with claims in your ASP.NET MVC web apps programming course. Your professor recommends that you review the content from the February 22 notes, specifically, these sections:

  • “Problem, and solution”, and
  • “Introduction to claims”

 

Read them now, before continuing.

Welcome back.

 

So, a claim is defined as follows:

A claim is a a statement that one subject makes about itself or another subject.

Therefore, a statement is descriptive information about a subject.

A subject is a participant in the lifetime of an application. A subject could be a human user, or a corporate body, or a programmable object (e.g. a security provider).

 

Claims management and issuance, in a web service project

In the web apps course, you learned that claims are managed and issued by an identity authority (which is the ASP.NET Identity system in our app).

Then, a claim can be used by an application for any of these reasons:

  1. To provide descriptive information (e.g. full name)
  2. To control access to a resource
  3. To control the ability to perform tasks or activities
  4. etc.

For our web services, claims are packaged in an access token, after a user successfully authenticates. Therefore, the result of a successful authentication is an access token, that (among other data) includes claims.

 

Creating claims, and custom claims

In the web app course’s SecurityClaimsIntro code example, you learned how to work with some of the standard (predefined, “well known”) claim types.

In the RegisterViewModel – which describes the package of data in a “register new user account” request – had these additional claim-related properties added:

  • GivenName – for the standard “…givenname” claim type
  • Surname – for the standard “…surname” claim type
  • Role – for the standard “…role” claim type

You also saw how the Register() POST-handling method in the AccountController was changed, so that these new claims could be configured for the new user account.

Finally, you saw how to use the [Authorize] attribute to control access to methods in the HomeController. (Study the use of the attribute on the controller declaration, and on each method declaration.)

In summary, the process to handle the standard claim types is well understood, and you have had enough practice with that.

How are custom claim types handled?

The same way:

  1. Modify the view/resource model, so that it includes properties for the custom claim types
  2. Modify the account-creation code (in the controller), so that it processes and configures the new claims
  3. In a controller or manager, test for the presence of the custom claim, when necessary

 

A new filter for authorizing custom claims

The Web API framework does not include an [Authorize] filter for custom claims. However, we can easily create one. Your professor has written a class that you can use (yes, you have permission) to authorize custom claims.

Get the CustomAuthorizeAttribute.cs source code file from this week’s GitHub repository folder. Save it in your Controllers folder, and edit its namespace to match the name of whatever project it’s part of.

Then, use it as follows. For example, assume that you’re looking for an “eye colour” claim type, with the value “blue”. In a controller, maybe before a method signature, add the new [AuthorizeClaim] attribute:

[AuthorizeClaim(ClaimType = "EyeColour", ClaimValue = "Blue")]
public IHttpActionResult Get()
{
  // etc.
}

 

Handling AND and OR conditions when using [Authorize] or [AuthorizeClaim] attributes

Yes, you can handle AND and OR conditions. How?

 

AND condition:
A method will run if it has a list of Authorize attributes that are ALL true:

// If ALL listed conditions are true, then authorization will succeed
[Authorize(Roles = "Employee")]
[AuthorizeClaim(ClaimType = "EyeColour", ClaimValue = "Blue")]
public IHttpActionResult Get()
{
  // etc.
}

 

OR condition:
A method will run if its Authorize attribute has several values, as a comma-separated string, of which ANY are true:

// If ANY value is true, then authorization will succeed
[Authorize(Roles = "Student, Mentor")]
public IHttpActionResult Get()
{
  // etc.
}

 

 

 

 

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Advertisements
%d bloggers like this: