DPS907 notes – Thu Nov 19

Security topics, wrap up.

 

Info about Test 9

Today – Thursday, November 19 – we do NOT have Test 9.

Instead, it will be on Monday, November 23, at the beginning of our class/session, at 9:50am.

It will ask questions that attempt to wrap up our coverage of security topics over the past three weeks (since the study week break).

 

Info about Lab 8

The Lab 8 due date is still Monday, November 23, but the My.Seneca/Blackboard uploader/acceptor will be open until Wednesday, November 25, at 12:00pm noon ET.

There is no late penalty for submitting Lab 8 between Monday and Wednesday at noon.

After the test on Monday, your professor will be available in-class to help you complete your Lab 8 work. We will not learn new topics on Monday.

 

Next week

Next Thursday, November 26, we will begin our topic coverage of SOAP XML (legacy) web services.

 

Today’s topic coverage

Today, we’ll look at a small number of security-related topics, to help wrap up our coverage of security topics.

Topics include:

  • IsRequestForMedia utility method
  • Custom AuthorizeClaim attribute
  • Social network login, for a web app

 

IsRequestForMedia utility method

This isn’t really a security topic, but it’s relevant to our Lab 8 assignment.

It would be really nice to know whether a request has an accept header for a media type. If it does, then the ByteFormatter media type formatter class will return the result. If it does not, the standard and built-in JSON or XML formatters will return the result.

To help answer the question, a static method named IsRequestForMedia was created in a new static “utility” class.

Use it in a “get one” controller: If IsRequestForMedia, then return the object’s media bytes. Otherwise, just return the object.

 

Custom AuthorizeClaim attribute

The Authorize attribute protects a controller method.

At a minimum, it ensures that the request is authenticated.

Optionally, the Authorize attribute can ensure an authenticated request includes a named role claim, or a named username claim, as shown in these examples:

// Named role claim...
[Authorize(Roles = "Student")]

// Named username claim...
[Authorize(Users = "Marie")]

 

OR condition

If a method can be run if the authenticated request includes ANY of several named role claims, the Authorize attribute simply includes a comma-separated string of role names:

// Can run method if a request has the "Student" role claim, OR 
// the "Mentor" role claim...
[Authorize(Roles = "Student, Mentor")]

 

AND condition

If a method can be run if the authenticated request includes ALL of several claims, simply include a list of Authorize attributes:

// Can run method if a request has the "Professor" AND
// "Coordinator" role claims...
[Authorize(Roles = "Professor")]
[Authorize(Roles = "Coordinator")]

 

Beyond “Roles” and “Users” – custom claim handling

The built-in Authorize attribute handles the three situations covered above (authenticated, authenticated with a named role claim, and authenticated with a named username claim).

What if we want to handle a custom claim?

The Lab 8 base project includes a custom authorize attribute class. Simply name the type and value, and it will ensure that the authenticated request has the matching claim. Easy and simple. Here’s how it’s used:

// Can run method if a request has a claim type "EyeColour" 
// with the value "Blue"
[AuthorizeClaim(ClaimType = "EyeColour", ClaimValue = "Blue")]

 

Social network login, for a web app

In this section, we introduce you to the ability to use an external identity authority for a web app.

Later, your professor plans to post another code example that does this for a web service.

Time constraints over the past few weeks delayed the work. Check back in a few weeks; it will be posted in the same Week 10 folder on GitHub.

 

Rick Anderson wrote a post that inspired today’s code example:
Code! MVC 5 App with Facebook, Twitter, LinkedIn, and Google OAuth2 Sign-on

Also, Robert McMurray wrote a useful post:
External Authentication Services with ASP.NET Web API

Why would you consider using an external identity authority? Several reasons, perhaps including these:

  • Avoid identity management and authentication responsibilities in your app
  • Eliminate the need for your app’s users to create yet another account
  • Leverage existing user accounts

 

Requirements, in general

The posted articles (linked above) include detailed and prescriptive information on how to do this task. However, these are the requirements, in general:

Choose the correct project template. It must use Individual User Accounts.

Register your app with the external identity authority. In this step, you trade information with – for example – Facebook, so that it knows that your app will be using it for authentication.

Configure the app with the data provided by the external identity authority. Almost always, it includes an identifier, and a secret. (So in many ways, the data items act as credentials for the app.)

Optionally, configure the app to capture additional data when an authenticated user begins using your app for the first time. After first-time login, a user account is created in your app, and gets marked with the external authentication provider (e.g. Facebook). If you want more info captured – e.g. first and last names, etc. – add code to the “register external user” method. You can also add code to configure claims.

 

Using the SocialLoginWebApp code example

Run the app. Begin the authentication process as you normally would, by clicking the “Log in” link:

session1

 

Choose another service to do the log in:

session2

 

You are redirected to the other service. It prompts for authentication, or account selection if your browser already has an authenticated session with the other service.

session3

 

If this is the first time that you’ve used the other service to login, it asks you for consent.

session4

 

Then, the local app adds a local account to represent the “external login”.

session5

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

%d bloggers like this: