Click here to Skip to main content
11,490,973 members (64,827 online)
Click here to Skip to main content

Tagged as

Embedded Application Identity Part 2: Role-Based Authorization in ASP.NET MVC 5

, 8 May 2014 CPOL 13.5K 12
Rate this:
Please Sign up or sign in to vote.
Add feature authorization to your MVC application with Roles

In this article we will implement the identity management requirements (defined in the previous article) that pertain to roles. Below is a recap of these requirements.

  • There will be 4 roles: Admin, Demographics Editor, Financial Manager, Online Access Manager.

  • Admin users can view all of the users in the system and create new users.

  • All users in any one of the predefined roles can at a minimum view account holder data.

  • Users in the Demographics Editor role can modify account holder’s demographic (address, phone, email address) data.

  • Users in the Financial Manager role can modify account information of the account holder.

  • Users in the Online Access Manager role can modify the account holder’s online access.

  • Each user may be a member of zero or more roles.

Role-based authorization is the function of specifying access rights to resources based on roles. Resources in this case are the various functions in an application. Roles simplify the management of authorization by giving application administrators and developers the ability to manage authorization for multiple users at the same time. Application administrators assign users to a role and developers limit certain functionality in an application to only those users in a role who are authorized to access that particular functionality.

The illustrations below demonstrate the value that role-based authorization plays in application security. In the first illustration all application users have access to all of the modules that make up the application because there are no restrictions based on the user's role. Thus there are u * m potential access points that need to be managed from a security standpoint where u is the number of users and m is the number of application modules.

Users

In the second illustration, each user is added to one or more roles and access to application modules are restricted by role which is much more manageable. From a security standpoint it is much easier to manage role-based authorization because multiple users can be added to a single role and the application only has to be coded to restrict access by role rather then individual user and there are far less roles than users. Also if a user's role in the organization changes overtime, the application code does not have to be modified. Instead the user would be assigned to a different role.

Roles

As in the previous article it would be helpful to have the ASP.NET source code for the sample application in front of you for reference as we will be making modifications to the source code to incorporate role-based authorization. As with the previous article, the source code is located on github in https://github.com/pcarrasco23/FootlooseFinancialServices. The commit called “Changes for Role-base Authorization” has the revisions to the Visual Studio project that pertain to this article.

Also we will be analyzing a potential threat using Fiddler so if you want to run the demonstration yourself you should download Fiddler.

Defining the Roles

The first step will be to define the four application roles. For simplicity we will insert the roles into the ASP.NET Identity database using the SQL script below. The script also seeds the database with the admin user in the Admin role so that that user has the capability from the application to create new users. For more advanced user/role management systems such as Active Directory there would be a user interface for this step.

INSERT INTO AspNetRoles
(Id, Name)
VALUES 
('Admin', 'Admin'),
('Demographics', 'Demographics'),
('Financial', 'Financial'),
('OnlineAccess', 'OnlineAccess')
DECLARE @UserId nvarchar(128)
SELECT @UserId = Id FROM AspNetUsers WHERE UserName = 'admin'
INSERT INTO AspNetUserRoles
(UserId, RoleId)
VALUES (@UserId, 'Admin')

In the Visual Studio project this script is stored in the AspNetRoles_Populate.sql file in the App_Data folder.

Restricting Functions By Role

Now we will make changes to the application to restrict certain functionality by role. This is, in order to access the functionality, the user must be a member of a role that is permitted to access the function.

Restriction by Role in the User Interface

First we want to remove the ability for a user to register him/herself. Although this is the default functionality in the ASP.NET MVC 5 template, typically you would not want your users to create their own profiles in the system (even though you had to do this for the admin user).

Open the file Login.shtml and remove the following line:

<p>
 @Html.ActionLink("Register", "Register") if you don't have an account.
 </p>

You should also remove the Register methods from the AccountController. Although removing the user control will prevent most users from being able to create their own profile, a tech savy user can access the functionality in ASP.NET MVC controllers without a user interface as we will soon see how that can be done.

Per the requirements, users in the Admin role should be able to view all users and create new users. The AdminController.cs was created to store the code for the functionality for Admin users. Note that the Register methods from AccountController were moved to AdminController. The Index method returns a list of all users in the ASP.NET Identity database as well as the roles of which they are a member.

Next the following code is added to _LoginPartial.cshtml. When a user in the Admin role logs into the application, this code will create browser links that refer to the AdminController methods above.

@if (User.IsInRole("Admin"))
 {
     <li>
         @Html.ActionLink("Register New User", "Register", "Admin")
     </li>
     <li>
         @Html.ActionLink("View Users", "Index", "Admin")
     </li> 
 }

The User object is an object of type System.Security.Principal.IPrincipal. The IPrincipal object represents the security context under which the code is running. The security context in the case of this application is the authenticated user. The IPrincipal interface has only one method – IsInRole(role) – which returns true or false to indicate if the security context is a member of the role provided. When a user in the Admin role runs this code, he/she will be given links to view all users in the system and create new users.

Now let’s run the application and login as the admin user. Since the admin user is a member of the Admin role you should see the Register New User and View Users links. Click on the Register New User link and create a new user. In my example I created a user with the ID “jsmith”.

Register_New_User

Next we will add this user to the Demographics and Financial roles. For simplicity, I will perform this step using SQL against the ASP.NET Identity database (although the UI can easily be modified to assign the user to one or more roles).

DECLARE @UserId nvarchar(128)
SELECT @UserId = Id FROM AspNetUsers WHERE UserName = 'jsmith'
INSERT INTO AspNetUserRoles
(UserId, RoleId)
VALUES (@UserId, 'Demographics')
INSERT INTO AspNetUserRoles
(UserId, RoleId)
VALUES (@UserId, 'Financial')

Restriction by Role in the Server-Side public API

Going back to AdminController.cs, you will note that the public methods are qualified with the Authorize filter.

[Authorize(Roles = "Admin")]

This attribute will only allow execution of the method if the authenticated user is a member of the Admin role. As noted earlier, although the UI has code that limits the admin functionality to users in the Admin role, an MVC controller can be executed using any HTTP client such as Fiddler. Therefore it is good security practice to implement security in the UI layer as well as in the server-side public code that is exposed via HTTP.

To demonstrate how public code can be accessed by unauthorized users, let’s remove the Authorize method attribute from the Index method of AdminController, rebuild, and run the project. Open Fiddler and log in as a user who is not a member of the Admin role (such as the user you just created).

Now go to Fiddler and search for the login request. It will be the one with the empty url “/”. I am running my Visual Studio project using IIS Express and the host address of the application is localhost:5925. Go to the Inspector tab and copy the the “Raw” contents minus the first line with the GET method and the URL.

Authorize_Fiddler

Then go to the Composer tab and paste the Raw contents in the “Request Headers” field like below. Enter the URL for the Admin controller and make sure the method specified is “GET”. Click the Execute button on the far right.

Authorize_Fiddler2

The Execute button will cause the Admin controller to execute with the credentials of the non-admin user because you copied the authorization token cookie that was created when you logged in. You will see this in the “/Admin” request. Click on this request to view the information associated with this request. You will see that the server returned the HTML content of the Index method of AdminController (which in this example returns a list of users in the system – something non-Admin users generally should not see!!) even though the authorized user is not a member of the Admin role. That is because there was nothing to tell the server to limit this functionality to Admin users.

Authorize_Fiddler3

Now go back to the code and add the Authorize attribute back to the Index method of AdminController, rebuild, run the application, and login again as the non-Admin user. Go to the Compose tab and click the Execute button again. This time the server will not return anything because the authorized user is not a member of the Admin role (Note that this time the body of the /Admin request returned 0 bytes).

Authorize_Fiddler4

As you can see it is critical that security is a fundamental part part not only of the UI design but of the server-side public API as well.

Let’s finish up by completing the other requirements for the Demographic, Financial, and Online Access roles. In the Person/Edit.cshtml file add the following if statements around the tab markup. Only members in the Demographic role can access the Person tab to edit an account holder’s demographic information. Only members in the Financial role can access the Account tab is modify the account holder’s account information. Lastly only members in the Online Access role can give an account holder online access. A user in the Admin role should be able to perform all of these functions.

<ul>
 @if (User.IsInRole("Demographics") || User.IsInRole("Admin"))
 {
     <li><a href="#person" data-toggle="tab">Person</a></li>
 }
@if (User.IsInRole("Financial") || User.IsInRole("Admin"))
 {
     <li><a href="#account" data-toggle="tab">Account</a></li>
 }
@if (User.IsInRole("OnlineAccess") || User.IsInRole("Admin"))
 {
     <li><a href="#login" data-toggle="tab">Login</a></li>
 } 
</ul>
<div> 
 @if (User.IsInRole("Demographics") || User.IsInRole("Admin"))
 {
     <div id="person" style="margin:5px;">
     @Html.Partial("PersonEdit", Model)
     </div> 
 }

 @if (User.IsInRole("Financial") || User.IsInRole("Admin"))
 {
     <div id="account" style="margin:5px;">
     @Html.Partial("AccountsEdit", Model.Accounts)
     </div> 
 }

 @if (User.IsInRole("OnlineAccess") || User.IsInRole("Admin"))
 {
     <div id="login" style="margin:5px;">
     @Html.Partial("LoginEdit", Model.Login)
     </div> 
 }
</div>

Login as the non-Admin user (jsmith), search for account holders, and select an account holder. Note that only the Person and Account tabs are visible.

Person_Edit_Tabs

Next go into the PersonController.cs file. You will see the appropriate Authorize attributes for the New, Edit, and Save methods. Using the Authorize attributes here will prevent unauthorized access to these public methods by means outside of the application’s user interface (such as through Fiddler).

In the next article we discuss how the ASP.NET Identity database can be replaced with Active Directory for identification management in our Footloose Financial Services application.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Peter Carrasco
Team Leader
United States United States
I am a senior software engineer and technical lead for a mid-sized technology firm. I have an extensive background in designing, developing, and supporting ASP.NET web-based solutions. I am currently extending my skill-set to the area of application identity management and access control.

Comments and Discussions

 
QuestionAwesome Pin
Mike Hankey2-Feb-15 23:32
professionalMike Hankey2-Feb-15 23:32 
QuestionList users with roles Pin
JoshYates198027-Aug-14 8:47
professionalJoshYates198027-Aug-14 8:47 
QuestionSource Pin
peterc02698-May-14 12:39
memberpeterc02698-May-14 12:39 
AnswerRe: Source Pin
peterc02698-May-14 12:42
memberpeterc02698-May-14 12:42 
GeneralRe: Source Pin
Peter Carrasco8-May-14 17:10
memberPeter Carrasco8-May-14 17:10 
GeneralRe: Source Pin
SelArom18-Jun-14 18:50
memberSelArom18-Jun-14 18:50 
GeneralRe: Source Pin
Peter Carrasco20-Jun-14 18:36
memberPeter Carrasco20-Jun-14 18:36 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.150520.1 | Last Updated 8 May 2014
Article Copyright 2014 by Peter Carrasco
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid