DPS907 WSA500 Assignment 7

A portfolio of apps that share a common security environment.

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

 

Due date

Tuesday, December 12, 2017, at 11:00pm ET (notice the Tuesday due date)

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.

 

Objective(s)

Create a working portfolio of apps that share a common security environment. Use the professor-provided IA Server app for identity management and the cookie/token-issuing part of authentication.

A simple diagram that shows the intended end result is below.

 

Introduction to the problem to be solved

Assume that you are in an organization that is implementing a portfolio of web apps and web services. All will share a common security environment.

We must create that common security environment, and ensure that it works. There will be three apps. One will be the IA Server app. Another app will be a data-rich app (using the web service project template that includes the Chinook sample database). A third app will be simpler, and intended to simply prove that it’s possible to add another app to the common security environment.

 

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:

  • A correctly-configured IA Server app, with initial users and app claims
  • Additional added (at run/test time) app claims and user accounts
  • In the new data-rich app, add and configure the security components it needs
  • In addition, add the resource models, manager, and controller code to deliver employee data, using a range of authorization criteria
  • In the simple app, add and configure the security components it needs
  • Edit its Values controller, to deliver simple string data, using a range of authorization criteria

 

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: “Configure manager/supervisor” must work only for the new manager/supervisor. 

 

Getting started

Get the IAServer project from the GitHub code example repository. It is in the week 9 folder.

  • Do NOT load and run this IA Server app yet

Next, create a new web service, named A7Music. It will use the “Web service project template v1”.

Finally, create another new web service, named A7Other. It will use the standard “ASP.NET Web Application” template, with NO user authentication configured.

For both the A7Music and A7Other apps, remember to customize the home controller’s index view with your personal information, and the _Layout.cshtml view template with the application name.

 

Doing the work

Let’s start by preparing the the infrastructure components.

 

IA Server app configuration, with initial users and app claims

Open the IA Server app in Visual Studio. Do a build/compile, but do not load and run the app yet.

  • Do NOT load and run this IA Server app yet

To facilitate testing and grading, we must change its database’s “Initial Catalog” name. How?

  1. Open its Web.config source code file
  2. Look for the connection string named “DataContext”
  3. In its connectionString attribute value, look for the “Initial Catalog=IAStoreV2;” string

Change the “IAStoreV2” string so that it includes “IA” and part of your Seneca user account name. For example, your professor’s Seneca user account name is “pmcintyr”, so his string value would be changed to, for example, “Initial Catalog=IApmcintyr;“.

Next, configure the IA Server to programmatically create a new user account – for you – when the app loads for the first time. (Notice that it already creates the uam and dev user accounts.) Just copy-paste the code block, and change the code that enables you to create a new user account for you.

Then, configure some “app claims” for the “master list” of allowable claims. Use the existing method stub (code block), and fill in the claims that you want your app to have. Recall that we’re working with the music business theme. At a minimum, please create these app claims:

  • Role claims, for Employee, and Customer
  • OU claims, at least three (3), for departments (organizational units) that would typically work with employees and customers
  • OU claims, at least three (3), for city names (locations); you can assume that the music business has offices or facilities in a number of cities worldwide
  • Task claims, at least three (3), for the kinds of tasks that would typically be done for employee, customer, and sales tasks; some of these claims should address typical human resources activities (read/skim the linked article to learn more about that organizational function)

Finally, you should be able to load and run the app. When you do, you will notice that you can login as uam, dev, or your new account. (Use the “Login” link on the web page that loads.) Make sure this works correctly BEFORE continuing.

 

Additional app claims and user accounts

Using the existing functionality in the IA Server (look for a controller that will enable you to do so), add two (2) additional app claims, for the OU and/or Task claim types.

Make sure you capture that activity in Fiddler.

Then, using the existing functionality in the IA Server, create several user accounts, with claims that make sense for the kind of user account. Here’s what we suggest:

Use a common password for all user accounts (maybe Password123!). That way, your testing process will be easier (and the marking process will be easier).

Create about four user accounts for employees of the music business. We recommend that you use the data from the Employees entity collection in the sample database. In other words, select about four of the existing “employees”, and create user accounts for them.

Optionally, you can also add more accounts, with simple names, for example, emp1@example.com, emp2, emp3, and emp4. Or, you could use a name that more closely matches their primary job function (e.g. sales1, clerk3, etc.).

When you are creating user accounts, ensure that you configure claims that make sense. Each user account will have a role claim, and it is likely that each will also have (two or more) custom claims.

Note that this work will be captured by the Fiddler request logging feature, so that your professor will be able to see that this was done correctly.

 

In the A7Music app, add and configure the security components it needs

The A7Music app will need to validate access tokens.

Therefore, as you have recently learned, add the necessary security components to the app.

Additionally, configure the app (and the other participating apps) to use a common encryption/decryption key for the access tokens and cookies.

 

In the A7Music app, enable it to deliver employee data

This app will fulfill a small number of use cases:

  1. Get all employees
  2. Get one employee
  3. Add new employee
  4. Configure an employee’s manager (supervisor)

You do NOT have to return results from associated/related objects. The goal in this assignment is to participate in a common security environment, and configure controller actions with various “authorize” attributes.

Have you done some of this work before?

Yes, very similar to what was done in Assignment 3.

Review and re-use your work from Assignment 3, or look at the sample solution in the GitHub code example repository (in the “Templates and solutions” folder).

 

Get all employees

This will work for users with these claims:

  • Role Employee, and
  • One of the OU or Task claims

 

Get one employee

This will work for users with these claims:

  • Role Employee, and
  • Two of the OU and/or Task claims

The result is that this action will have three (3) “and” conditions for authorization.

 

Add new employee

This will work for users with these claims:

  • Role Employee, and
  • A Task claim that has something to do with the ability to add a new employee

 

WSA500 students ONLY – Configure an employee’s manager (supervisor)

This will work for users with these claims:

  • Role Employee, and
  • A Task claim that has something to do with being a manager/supervisor

 

DPS907 students ONLY – Configure an employee’s manager (supervisor)

This will work for users with these claims:

  • Role Employee, and
  • A Task claim that has something to do with being a manager/supervisor

This work has one extra security feature.

If the two conditions above are met, then the actual work done in the Manager method will succeed ONLY if the user account name in the request’s security principal matches the user account name in the employee that will be the manager/supervisor. In other words, only the employee’s new manager/supervisor can do this task.

When you are testing this use case, make sure that you are authenticated as one of the “employees” that are actually in the database’s Employees entity collection.

How would you do this? Do an extra check in the Manager method – check the security principal. (You learned about this in both your web apps course, and in this course.) Compare the user name (which is enough, in this situation, to uniquely identify a user).

For example, if the current request is from Andrew Adams, and the request is to configure Andrew as Nancy Edwards’ manager/supervisor, you would expect that the request would succeed.

However, if the current request is from someone else (e.g. “clerk3@example.com”), and the request is to configure Andrew as Nancy’s manager/supervisor, you would expect that the request would fail.

As was just mentioned above, in the past, you have learned how to check the security principal:


var user = HttpContext.Current.User as ClaimsPrincipal;

The “user” variable has an “Identity” property, which has the user name value that you need to compare. (And recall that user name is the same as the user’s email address.)

 

In the A7Other app, add and configure the security components it needs

Similar to what you did (above) in the A7Music app, configure this A7Other app with the necessary security components.

 

Edit the A7Other Values controller to deliver simple string data

This A7Other app does not have its own persistent data store, and it is NOT necessary to create one.

In the Values controller, implement all five methods (get all, get one, add new, edit existing, and delete item). The return type for every method (except delete item) can be “string”, to make it really easy to test. The add new and edit existing methods need an entity body, so keep that simple, by configuring it as a string. The method bodies do not have to do anything much, except that all but delete item will return a string.

The real purpose of this controller is to give you an opportunity to add combinations of [Authorize] and [AuthorizeClaim] attributes to the action methods. When you do this work, make sure that each method has a slightly different combination of attributes, so that you can test them with user accounts that will work, and others that will not.

Note that this work will be captured by the Fiddler request logging feature, so that your professor will be able to see that this was done correctly.

 

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

This Assignment 7 has a modified submission process (when compared to earlier assignments). 

We need all three projects to be able to grade your work. 

Therefore, here is the modified procedure:

  1. Make copies of all three projects
  2. For each project, remove its packages, bin, and obj folders
  3. Zip all three projects together (in one zip file), and upload to the designated location on My.Seneca/Blackboard before the due date-and-time

 

For example, assume that you are currently viewing a folder named “A7” in File Explorer.

It should have these three sub-folders:

  1. IA
  2. A7Music
  3. A7Other

Select all three folders, then zip them into one zip file result.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Advertisements
%d bloggers like this: