DPS907 WSA500 Assignment 7 – Fall 2016

Working with security components in a web service.

Read/skim all of this document before you begin work.

 

Due date

Wednesday, October 26, 2016, at 11:00pm ET

Grade value: 4% of your final course grade

If you wish to submit the assignment before the due date and time, you can do that.

 

Objective(s)

Work with the security components in a web service. Become very familiar with interaction patterns that involve security. Customize the security environment to meet the needs of an application. Build foundations for future experiences.

 

Introduction to the problem to be solved

We need a simple web service – with security – that will deliver data about smartphones. The web service will support fetch all, fetch one, and add new scenarios. Data will be persisted in a standard database store.

You may remember that this was the theme of our first Assignment 1.

Yes, you have permission to use some of the code that’s in the sample solution that was posted earlier this term.

This assignment does NOT use the Chinook sample database.

 

Specifications overview and work plan

The following specifications apply to all of your assignments:

  • Follows best practices
  • Implements the recommended system design guidance
  • Customized appearance on the landing web page
  • Uses Entity Framework and Code First technology
  • Includes a Fiddler log file that shows complete coverage of tests
  • All responses will be hypermedia representations
  • The project will include the recently-learned documentation features

For this assignment, here is what we’re looking for:

  • Supports HTTP GET, for get all and get one use cases, for authenticated requests
  • Supports HTTP POST, for the add new use case, for requests that include a specific claim
  • Delivers information about the user/requestor

 

During the class/session, your professor will help you get started and make progress on this assignment.

Every week, in the computer-lab class/session, your teacher will record a grade when you complete a specific small portion of the assignment. We call this “in-class grading“.

The in-class grading will be announced in-class by your professor.

This week, we will NOT have an in-class grading component.

 

Getting started

Create a new web service, named Assignment7. It will be a standard “Web API” project type, with “individual user accounts” authentication.

Remember to customize the home controller’s index view with your personal information, and the _Layout.cshtml view template with the application name.

Build/compile, and run (without debugging), to ensure that the app’s home > index view loads in a browser.

 

Doing the work

Before writing code for the use cases, add the infrastructure components that are needed, including:

  • HTTP OPTIONS handler
  • Link enabling classes
  • Enable and configure the Web API help page
  • Root controller (and its activation in the WebApiConfig class)
  • Entity class for the smartphone, and DbSet<TEntity> property in the data context class
  • AutoMapper, and a Manager class

Again, you have permission to use some of the code in the sample solution

Build/compile (to make sure that there are no errors).

Add at least four (4) smartphone objects to the data store, so that you have some data to work with as you complete the tasks below.

 

Configure the security environment

In its current form, the project’s security environment will work correctly, and similar to the “ProjectWithSecurity” code example.

That’s not good enough. It must have some of the features of the “SimpleClaims” code example (“role” claim support”, and a bit more (custom claim support). Therefore:

  • The RegisterBindingModel will need changes
  • The Register() method in the account controller will need changes
  • A new authorization “filter” will be needed to handle the custom claim(s)

 

First, add the ability to work with “role” claims, probably using your past web apps course experience and the SimpleClaims code example to guide you. Test to ensure that it works.

Test – how?

Think about it…

You will have to register a new user account every time you make a change/edit.

Then, you will have to request an access token.

Finally, you will have to inspect the contents of the access token. How? Well, you could use the controller code that’s in the ProjectWithSecurity code example, right?

 

Next, add the ability to work with custom claims. With custom claims, the types and values can be anything. Remember, a claim is descriptive information. A claim can be used for purely descriptive purposes (e.g. full name, or friendly and nicely-formatted name), and/or for access control to resources, and/or for controlling the ability to perform a task/activity.

Here is a suggested way to begin working with custom claim types:

For descriptive claims, the “claim type” can be anything. As stated in the class notes, “EyeColour” could be used. The value could also be anything. For example:

  • EyeColour = Blue
  • FullName = Peter McIntyre

For resource access control, the “claim type” could maybe include include a part of the app name. The value could be a descriptor that’s appropriate for resource access control. For example:

  • In a “music business” app, control access to the “add customer” resource: MusicBiz = CustomerEditor

For task/activity control, the “claim type” could maybe be “Activity”. The value could be a descriptor that’s appropriate for an activity. For example:

  • In a “music business” app, enable the ability to set/configure a supervisor (manager): Activity = CanSetSupervisor

If you follow this suggestion, then its implementation in the RegisterBindingModel and the Register() method of the AccountController will be similar to that of the “role” claim implementation.

After adding the professor’s custom authorize attribute class (from the GitHub repository), you will be able to test and use the custom claims in your app.

 

~~~~~

 

Now, you can circle back and do the programming work.

As a reminder, your professor believes that the best way to work through any assignment is to do it incrementally. Get one thing working correctly, before moving on to the next. Test each part.

Therefore, you will probably be cycling through the following programming tasks, for each use case. (You first saw this list in the Assignment 2 specifications.)

  1. Write the resource model class(es) that support the use case
  2. Add one or more AutoMapper mappings for the class(es) that you just added
  3. Write the Manager class method that performs the data service operation
  4. Create a controller, if necessary
  5. Write the controller method that implements the use case
  6. Test, using Fiddler, debug and fix if necessary

Incrementally doing these tasks will ensure that you’re making progress. You will also notice that they’re repetitive. That’s good, because the process will become familiar and natural to you.

Here are the use cases, as suggested from the simple sentence above:

  • Get all use case, for an authenticated request
  • Get one use case, for an authenticated request that includes a specific role claims
  • Add new use case, for an authenticated request that includes a specific role claim, and a custom claim
  • Deliver info about the request user

All use cases will deliver responses that include hypermedia (link relations etc.). Therefore, you must write additional link-aware resource model classes for the Artist and Album entities. And, where necessary, AutoMapper “create map” statements.

Remember to add appropriate code comments to your controllers and manager. Also, remember to add XML code comments on controller methods, to enable the Web API Help Page feature. Add XML code comments on resource model properties. Doing this will enable the “Description” column of a Web API Help Page to show some useful information.

Make sure that you study the code examples, from this course and from the web apps course, to learn and implement the best practice way of designing and coding each programming task listed above. Also, use the comments and feedback that appears on your previous assignment checklists.

 

Info about the get all use case

This will work for ANY authenticated request.

 

Info about the get one use case

First, the request must be authenticated. However, only for requests that have these claims:

  1. Role claim “Employee”, and
  2. Role claim “Sales” or “ProductManagement”

 

Info about the add new use case

Again, the request must be authenticated. However, only for requests that have these claims:

  1. Role claim “Employee”, and
  2. Custom “Activity” claim, with a value of “SmartphoneEditor”

 

Info about the “deliver info” task

This will work for ANY authenticated request. Yes, you can use some of the code in the ProjectWithSecurity code example.

 

Configure the root (entry point) controller

As a final task, after configuring all the functionality above, go to the root (entry point) controller, and configure the link relations that you want to deliver to requestors.

 

Testing your work

Use Fiddler.

Ensure that it has been configured to save the message bodies in requests and responses. (A default installation does not do this.) If you are using a College computer, this should have been configured, but check anyway. If you installed Fiddler on your own computer, follow the instructions on this document.

Test all scenarios (use cases). Make sure that you test error or error-like scenarios.

 

Saving – “exporting” – your tests

On the left side list of requests, you can delete items that you do not want included in the export.

When you’re ready to save, choose File > Export Sessions > All Sessions…

The export format will be “HTTPArchive v1.2”. Click the Next button to choose a save location (your project’s root, in the same folder level as the “packages” folder and specify a filename. Name the file by using the project name (e.g. “<whatever>.har”).

(You can test whether the export was successful. How? First, close then re-open Fiddler. Choose File > Import Sessions. Select “HTTPArchive” as the import format. Navigate to the folder that holds the “har” file, and select it. Finally, browse through the request-response sessions.)

 

Reminder about academic honesty

You must comply with the College’s academic honesty policy.

Although you may interact and collaborate with others, you must submit your own work.

 

Submitting your work

At this point in time, you should be familiar with the process:

  1. Copy your project
  2. Remove its packages, bin, and obj folders
  3. Zip and upload to the designated location on My.Seneca/Blackboard before the due date-and-time

If you need more details, look at the info in assignments 1 through 3.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Advertisements
%d bloggers like this: