DPS907 notes – Tue Oct 1

Security introduction. Topic review and summary.

.

Reminder about how to check your work-in-progress

As our tasks get more complex, remember to simplify.

For example, sometimes you just need a quick answer – as a string – from a controller method. You don’t want to be bothered with a view model class, or an AutoMapper map, etc.

OK, great. Remember that a controller method can return any type of data. Including a string.

So, if you want to test your logic, create a method in the controller, which returns a string. Then call it, from a browser, or Fiddler.

You’re welcome.

.

It’s time to talk about security

Some web services are open. Most are not.

In this course, you will learn to secure a web service, It will be an introductory-level treatment, and provide a foundation for future scenarios that will be more complex.

Today, we’ll cover the important concepts, and demonstrate them with HTTP Basic Authentication.

In a future class, we’ll cover a more robust scheme, such as something based on OAuth or cloud-based providers.

.

Security, version 1 – HTTP Basic Authentication

From the perspective of the server, each incoming request is independent and stateless. The request must include credentials, so that the server can authenticate the request. If successful, the request may be authorized to access a resource.

Study this article for valuable information about access control.

Today, we will study the HTTP Basic Authentication scheme. It is described in this Wikipedia article, and in the Internet RFC 2617.

To implement this kind of security in an ASP.NET Web API web service, there are two simple requirements:

  1. Authenticate a request
  2. Configure authorization for a resource

.

Authenticate a request

As you know, a request to an ASP.NET Web API web service is handled by a “pipeline” of software modules. Each has a specific task to perform. If the task is performed successfully, the request is passed on to the next software module in the pipeline. Otherwise, an exception is created and returned as the response.

You already have experience with many of the software modules in the pipeline:

  • The request routing dispatcher (HttpRoutingDispatcher), which determines which controller and method will handle the request
  • Media type formatter, which can serialize and deserialize an HTTP content stream that isn’t include in the base JSON, XML, or multipart-form formatters
  • Model binding, which can serialize and deserialize an HTTP content stream to-and-from classes/types in your app
  • Controllers, which ultimately handle the request

A detailed diagram of the pipeline is below. (Click the diagram to open it in a new tab/window.)

RequestHandlingPipeline.

.

At the bottom of the blue-coloured components, you will find the web server (HttpServer). At the top of the blue-coloured components, you will find the request routing dispatcher. The orange-coloured components represent the software modules that implement and support the controllers.

message handler is a class that receives a request, and returns a response. A message handler is a good choice for operations on HTTP messages in general, in contrast to controller methods which are very specific.

The best strategy for authenticating a request is to create a message handler, and add the handler to the pipeline. Our handler will be one of the blue-coloured components (e.g. “Message Handler A”). In this scenario, every request will be authenticated, before the request is routed to the controller and method.

In the example app, we created a Handlers folder, and in that folder, we created a class that inherited from DelegatingHandler. It is initialized in the Global.asax class.

The authentication handler performs authentication, and if successful, it configures the request’s thread with an object representing the authenticated user.

.

Configure authorization for a resource

Authorization can be configured 1) for the entire web service, 2) for all methods in a controller, or 3) for specific methods only.

Add an [Authorize] attribute. This is a filter (which you will find in the orange-coloured components of the pipeline diagram). Example scenarios include:

  • [Authorize] – request must be authenticated
  • [Authorize(Roles = “User”)] – request must be authenticated, and user must be in the “User” role
  • [Authorize(Roles = “Updater,Admin”)] – request must be authenticated, and user must be in the “Updater” or “Admin” role
  • [Authorize(Roles = “Updater,Admin”, Users = “user123”)] – request must be authenticated, and user must be “user123″ or in the “Updater” or “Admin” role
  • [Authorize(Users = “user123,user456”)] – request must be authenticated, and user must be “user123″ or “user456″

If you choose to require authentication (for example) all but one method, add the appropriate [Authorize] attribute to the controller class. Then, add the [AllowAnonymous] attribute to the specfic/desired method.

This article has more information about filters.

.

Concept, topic, and skill highlights from the example app

The example app, oct01securitybasic, can be downloaded from the repository. It enables you to learn how to configure security, so that some requests must be authorized.

It includes some infrastructure that enables you to create and view credentials. Study these classes:

  • Credential (and its view models)
  • Repo_Credential – enables credential management and querying
  • CredentialsController – endpoint for credential management and querying
  • BasicAuthMessageHandler – performs the authentication
  • TestController – enables us to test our work

Before continuing, create some credentials that you can use to test authentication and authorization.

.

BasicAuthMessageHandler

This class is located in the new “Handlers” folder. It is initialized in Global.asax.cs, which adds it to the pipeline (in the lower part of the blue-coloured components in the diagram above).

The handler will examine every request. Its SendAsync method will attempt to authenticate the requestor, using the data in the header.

If successful, the handler creates principal object (which requires an identity object that represents the requestor), and sets it as the request thread’s principal.

If not successful, and authentication is required (determined later in the pipeline), it will create an HTTP 401 “unauthorized” response, and create a header to inform the requestor about its authentication scheme.

It’s also possible that an HTTP 403 “forbidden” response gets generated. That happens when authentication is successful, but the request is not authorized for the requested resource.

.

TestController

This class is based on the “API controller with empty read-write actions” template, and by default will return simple strings.

Use this class to test your authentication and authorization scenarios. Add authorize attribute(s) to one or more methods, or to the class.

When using Fiddler, you must add an ‘Authorization’ header to your request. For example:

Authorization: Basic <base64_encoded_name_and_password>

.

Topic review, and Friday’s test

Well, it’s been quite a ride so far. We’ve covered many web service topics. It’s time for a test, which will be on Friday.

For every topic, ask yourself two questions:

  1. Can I explain?
  2. Can I do?

If you can answer “yes” to both questions, you are prepared for a successful test.

All topics – including today’s security topic – will be tested.

You may be asked about factual information, as well as concepts, which will give you an opportunity to demonstrate reasoning, analysis, and synthesis skills.

Written portion – The question types will include short answer, multiple choice, sequencing, and so on.

Programming portion – You will write software for one or more scenarios.

.

How to prepare

Review your hand-written and/or digital notes.

Review the course notes. Every page. Every section. Every word.

Follow the links in the course notes and the readings – read, understand, and apply the readings.

Write code. Practice every scenario.

Know how to explain concepts, and draw simple diagrams where appropriate.

Know and understand the reasons for some of the design and coding decisions we make.

.

.

.

.

.

.

.

.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: