Overview
In a web application, it is important to set up proper access through authenticated Users and their Roles. Roles are predefined sets of permissions assigned to users based on their responsibilities or functional needs. Users are then assigned roles that dictate their level of access and functionality within the application, ensuring efficient access control, scalability, and enhanced security by grouping individuals with similar privileges.
This is why Dotnet Report provides a built-in mechanism to use your web application’s Users and Roles to apply to Reports and Dashboards for access restrictions. It can also be used to apply row-level data access restrictions within reports.
In this article, we will demonstrate the steps to utilize users and roles used in your Web Application to apply Report Access Restrictions in Dotnet Report. We will use the .NET Identity framework to implement this with individual user accounts saved in a MS SQL database. This is the most common authentication method used in .NET web applications.
In this example, there are 4 existing roles in the database, Administrator, Owner, Power User, and Regular User. There are also 3 current users, with certain roles assigned. These are important as they will be implemented within the Dotnet Report software to manage access.
Steps to Implement User Roles in Dotnet Report
After first installing Dotnet Report, when a user is creating a new report and wants to restrict certain roles from viewing or editing reports, they are unable to do so because the roles list is not populated or connected to your application’s roles by default, as shown below.
Populating the Roles list can easily be done by opening the “DotNetReportApiController” file and providing appropriate values to the settings variables, which should be within the top 40 lines of the file.
settings.ClientId = "";
settings.UserId = "";
settings.UserName = "";
settings.CurrentUserRole = new List();
settings.Users = new List();
settings.UserRoles = new List();
settings.CanUseAdminMode = true;
settings.DataFilters = new { };
Using .NET Identity Manager
To use .NET Identity framework in our Controller, we need to add the following code to add the identity manager and user manager in our controller:
private readonly RoleManager _roleManager;
private readonly UserManager _userManager;
public DotNetReportApiController(RoleManager roleManager, UserManager userManager)
{
_roleManager = roleManager;
_userManager = userManager;
}Side note: To make sure the constructor populates the roleManager and userManager correctly, we also need to add the initialization code in Program.cs. A simple example is shown below using default identity:
builder.Services.AddDefaultIdentity(options => {
options.SignIn.RequireConfirmedAccount = false;
options.SignIn.RequireConfirmedEmail = false;
})
.AddRoles()
.AddEntityFrameworkStores();Now that we have access to .NET Identity framework’s role manager and user manager in our controller, we can use it to populate our roles and users list, and also get information about the currently logged-in user.
To add role manager to the controller, we will add a variable with the identity role type and make its value a list of all the current user roles in the project. After that, you should be able to populate the list by simply just updating the value of the “settings.UserRoles” variable.
List<IdentityRole> roles = _roleManager.Roles.ToList();
settings.UserRoles = roles.Select(x => x.Name).ToList();Once this is done, you should be able to view all the roles in the Admin mode of Dotnet Report when attempting to create a new report.
Getting the Current Users’ Roles
The next step is to get the current user’s roles and pass it to Dotnet Report through settings so that the system would know what roles the logged-in user has. To do this you have to use the dotnet report setting property, “settings.CurrentUserRole” to populate your project’s current authenticated user roles. Now, certain roles will be allowed to only view files, while other roles can edit them as well.
var currentUser = User;
var userRoles = currentUser.FindAll(ClaimTypes.Role).Select(c =>c.Value).ToList();
settings.CurrentUserRole = userRoles;Steps to Implement Users in Dotnet Report
Next, we will populate the users list, which is very similar to how we populated the roles list. Once again we will make the appropriate value changes to the settings variables.
To populate this list, you need to change the value of the “settings.Users” variable(also found in the DotNetReportApiController).
List<IdentityUser> users = _userManager.Users.ToList();
settings.Users = users.Select(x => (dynamic)x.Email).ToList();We should now have all the users displayed, and can now edit their access to reports.
Providing UserID Value
To let dotnet report know about the currently logged in user, we need set UserId property on settings. To do this, we need to get back on the “DotNetReportApiController” and change the value of the “settings.UserId” to the code below. After this change is made, the project’s administrator can begin making visible edits to the selected user’s access to reports.
settings.UserId = currentUser.FindFirst(ClaimTypes.Email)?.Value;Side note: Make sure that the value you use for UserId is the same that you provide in the Users list, “settings.UserId” and “settings.Users” are the same, or the changes will not be visible.
Demonstrating using Roles for Report Access restrictions
Now that the Roles lists’ are populated, we can begin demonstrating the restriction features that we had just created. We’ll start by just utilizing the Regular User and the Administrator roles for the example. We’ll change our test report so that Regular Users can only view the report while Administrators will have much more privileges.
Now that the changes are made, let’s take a look and see how they were implemented. When logged in as a Regular User the following is shown for the report.
However, when the Administrator User logs into the system, they can edit and delete these reports as shown below.
Demonstrating using Users for Report Access restrictions
Let’s now move on to the demonstration of Users for report access restrictions. We’ll edit our test report so that the User, “mir_alikhan@tamu.edu”, can only view this specific report.
Now, after the User logs in as “mir_alikhan@tamu.edu”, we notice that the User can only view the test report, when not under Admin mode.
Conclusion
Having User and Role restrictions is essential for enterprises. Dotnet Report recognizes this need and allows clients to link Users and Roles to both dashboards and reports, while also having restriction access features. In this article we walked through how to implement these restriction features on reports for both users and roles.
