DPS907 WSA500 Assignment 6 – Fall 2017

Working with security components in a web service.

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


Due date

Monday, November 27, 2017, at 11:00pm ET

Grade value: 5% of your final course grade

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



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.

You have permission to use some of the code that’s in the sample solution that was posted in the “Templates and solutions” folder of the GitHub repository.

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

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.

DPS907 students must do one more task: Analyze a scenario and recommend a user account and claims configuration. 


Getting started

Create a new web service, named Assignment6. 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:

  • 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 Assignment 1 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 lots of 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.

However, that’s not good enough.

It must have some of the features of the “SimpleClaims” code example (e.g. “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 (copy) the AuthInfoController code that is 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: AddNewCustomer = CustomerEditor

For task/activity control, the “claim type” could maybe be “Task”. 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): Task = 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.

In other words…

For now, add another string collection property to the RegisterBindingModel class, for each kind of claim type: Descriptions, AccessControls, and Tasks. Similar to what we did for Roles in the SimpleClaims code example.

Then, in the Register() method of the AccountController, process each string collection.

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 claim
  • Add new use case, for an authenticated request that includes a specific role claim, and a custom claim
  • Deliver info about the request user


Remember to add appropriate code comments to your controllers and manager.

Make sure that you study the code examples, from this course and from the web apps course, to 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.


More 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 “Task” 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.


(DPS907 students…) Analyze a scenario and recommend a user account and claims configuration

To complete this task, you will write some brief documentation on a new linked web page in the project.

The new web page (view) will be on the /home/userinfo URI. (We shouldn’t have to include instructions on how to create a new view in an ASP.NET MVC web app. If you need a refresher, here’s a link to the web apps programming course notes.)

Here’s the scenario:

Think about the problem domain in the recently used project template (i.e. the Chinook sample database, the music business, etc.). Think about the data that’s being managed, and the kinds of things that would happen in the business.

Here’s what you must do:

Think about and analyze the scenario.

Identify at least five (5) different departments that could exist in the business. Use your knowledge of business in our society, however you have gained it (personal learning, the business courses in our program, workplace learning, etc.).

In each department, identify at least two (2) kinds of jobs that could exist. One job should be an entry- to intermediate-level job. Another should be a job with higher-level requirements and/or responsibilities.

Then, recommend a claims configuration. Make sure you have some of each of descriptive, role, access control, and task claim types. Include sample values for each claim type.

Finally, create some fictional user accounts, with varying claims.

Document all this on the /home/userinfo web page. Clearly and with care. Nicely organized. Tell a good story.


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.































%d bloggers like this: