DPS907 notes – Mon Nov 9

Security topics.


Review of the security topic coverage

Before we cover new topics, let’s review the topics that were introduced last week.

Locating security components in a project: ASP.NET Identity adds packages, classes, and configuration.

The authentication process results in the issuance of a cookie (for browser clients) or token (for programmatic clients).

The request thread includes a security principal object, which is available to all code in the request-processing pipeline. The security principal object can represent an anonymous user (for unauthenticated requests), or a specific authenticated user.

There are essentially three security components in a secured app:

  1. Identity management, including account storage and account management tasks
  2. Authentication, to validate credentials, and issue a cookie or a token
  3. Authorization, to inspect a cookie or token, construct a security principal object, and match it against authorization rules

The first two components can be separated into an “identity server” app.

A separate app can use the services of the “identity server” by using a specific configuration. It includes the third component named above.

A number of excellent must-read resources were identified for further study.

Finally, a number of security terms were named and defined.


Overview of this week’s topic coverage

Some topics that we cover this week:

  • The challenge of security on the web in 2015
  • An introduction to the OAuth authorization framework
  • Finding OAuth in ASP.NET Identity
  • Working with a client app (other than Fiddler), and the async pattern
  • An idea for Lab 8, and design issues
  • A re-introduction to claims
  • Studying “version 2” of the Identity Server, which handles claims
  • Hands-on interacting with the updated Identity Server


The challenge of security on the web in 2015

Your professor will introduce and discuss the challenge of security on the modern web. Be prepared to listen, think, question, and plan for solutions.

The OAuth authorization framework was designed to meet the challenge. It is mature, widely-deployed, and suitable for use on small apps, and on the web’s biggest apps.

Read and study the document titled Security on the web.


Working with a “client app”

An app named ClientAppInstruments has been created, as an example of a “client app”.

From the perspective of the user, it is a trusted app. It is capable of maintaining the confidentiality of credentials, and of the requests and responses (when deployed using TLS).

An important design feature of a client app is that it uses asynchrony. Why? When a requestor sends a request to a web app or service, it does not know how long it must wait for a response. Using an asynchronous programming pattern, resources (such as memory and communications channels) can be released while the requestor is waiting for a response.

In an ASP.NET app, the async pattern can be described with a few rules:

An async method is marked with the “async” keyword. For example, “public async…”.

The method’s return type is wrapped in a Task type. For example Task for void results, and Task<T> for other results.

When calling an async method, prefix the method name with “await”. For example, “var foo = await bar.FindUserAsync(…)…”.

The compiler constructs all the callbacks and closures needed to implement your intent.


A discussion about Lab 8

Lab 8 is due in two (2) weeks, on November 23.

We will discuss an idea for the assignment today, and some of its design issues. The intention is to publish the specifications by the end of tomorrow (Tue Nov 10).


A re-introduction to claims

It is likely that you worked with claims in your ASP.NET MVC web apps programming course. The content in this section repeats the professor’s introduction to claims in his web apps programming course, and adapts some of the content for web services.

What is a claim? An often-used definition:

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).


Claim examples

What does a claim (statement) look like?

Here are some examples. For these examples, assume that the subject is a user (and your professor), Peter McIntyre.

The user name is pmcintyr.
username = “pmcintyr”

The user’s full (readable) name (e.g. first name, and last name) is Peter McIntyre.
name = “Peter McIntyre”

The user’s birth date is May 15, 1980 (yeah, right).
dateofbirth = “1980-05-15″

The user’s email address is peter.mcintyre@senecacollege.ca.
email = “peter.mcintyre@senecacollege.ca”

The user’s roles are: employee, faculty, coordinator.
role = “employee”
role = “faculty”
role = “coordinator”

Custom claim example:
The user’s driver’s license number is M12345809515.
driverlicense = “M12345809515″

Custom claim example:
Is an administrator of the course outline system.
courseoutlinesystem = “administrator”



Claims management and issuance

While a claim is a statement about a subject, claims are managed and issued by an identity authority (which is the ASP.NET Identity system in our web app).

Then, a claim can be used by an application to authorize a user to access resources and/or perform tasks.

In a web app, claims are packaged in an authentication cookie, after a user successfully authenticates. Therefore, the result of a successful authentication is a cookie that (among other data) includes claims.

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

Our web app or web service must trust the identity authority. (That is done by sharing a cryptographically-strong ‘machine key’ value between among the identity authority and the apps. When you separate the identity authority and web app/service, you will have to configure this value.)


Separating the app from the identity authority

In this course, you have learned to use a separate Identity Server (IS) as an identity authority.

The big benefit of this approach is that we do not need identity management and authentication logic in our web service app(s):

  • Authentication is done by an “identity authority”
  • The authentication process issues an access token to the user
  • The app(s) simply use the claims that are included in the user’s access token


An updated Identity Server v2

An updated Identity Server can be found in the Week_09 folder of the course’s GitHub code repository.

Download and open it.

It includes claims processing. Use the Task List, and the “Attention” comment token, to locate and study its added features.

























%d bloggers like this: