Confidentiality, Integrity, and Availability, or CIA, form the foundation of information security practices. Confidentiality ensures that information is accessible to authorized individuals only. Integrity ensures information is accurate, while Availability ensures information is available to intended individuals whenever they need it without any disruptions.
Access Control is one of the fundamental ways to implement Confidentiality. It governs the who (authentication) and what (authorization) part of any security system. Access control systems are vital as they reduce the security risk in any organization by ensuring that data and resources are accessible to authorized entities using a set of predefined access policies.
These are different access control models, and these models differ from each other based on how they control access to resources. A few models are listed below:
- Discretionary Access Control (DAC), where the owner of the resource, controls who can access it and what permissions they have. Access control is at the resource owner's discretion, so this model is considered more flexible but less secure.
- Mandatory Access Control (MAC) defines system-wide access policies governed by central authority (administrators). MAC is considered more secure as it has consistent and rigorous enforcement of access policies.
- Role-Based Access Control (RBAC) grants access to entities based on their organizational roles rather than individual identities.
- Attribute-based Access Control (ABAC) grants access to entities based on certain attributes associated with the individual. These attributes could be user attributes like department or location or resource attributes like type, metadata, and so on. ABAC policies are defined based on the combination of these attributes.
This blog focuses on Role-Based Access Control. We are going to cover an interesting case study from one of Encora's recent projects where we implemented RBAC using Microsoft Entra ID as the Identity and Access Management platform.
Role Based Access Control
RBAC (Role Based Access Control) is an access control model where accesses are defined based on organizational roles. Users are grouped into roles and permissions are assigned to these roles. These groups/ roles could be created based on job functions and responsibilities. The best part is the flexibility to add a user to multiple groups, thus granting cumulative access to the user based on all the groups that they are a part of. This is extremely popular model because of the below advantages:
- Simple and easy maintenance- Onboarding and offboarding of users becomes easy.
- Scalable & flexible- IT Administrator can remove or add users to multiple groups or roles.
- Centralized policies: Centralized control allows organizations’ IT teams to have consistent, standardized, non-discretionary IT security policies.
RBAC Implementation
Implementation of RBAC has four stages-
- Role Identification: Analyzing user roles and responsibilities based on business functions.
- Role Assignment: Mapping roles to users based on their job functions. Users can have multiple roles.
- Permission Assignment: Defining what actions each role can perform. Best practice is to follow the principle of least privileges.
- Role Administration: This is the last stage of managing roles and permissions over time. IT Administrators need to ensure users, roles and assigned permissions are updated periodically.
There are several ways for RBAC (Role Based Access Control) implementation. Specialized RBAC management tools, hybrid implementation of ACL (Access Control List) & RBAC, RBAC using IAM (Identity and Access Management) tools are a few of the popular ways. All popular IAM tools like Microsoft Entra ID, Okta, One Login, Ping Identity etc. have RBAC frameworks built in. IAM based RBAC implementation offers various advantages:
- Centralized Identity Management
- Scalable & Agile
- Built-in RBAC frameworks and policies
- Enhanced security using advanced features like MFA etc.
- Strong risk management of IAM tools
Let us now see a case study where we implemented IAM-based RBAC with Microsoft Entra ID as Identity and Access Management for an enterprise application.
Enterprise Case Study
Encora designed and implemented an Azure cloud-based scheduler for automating work scheduling in the utility operations space. This scheduler application was built in-house for the Electric Operations department to be used by the client’s internal work managers. This application was successfully deployed to production and hundreds of users began using it for their day-to-day work of job scheduling. Later, we received another request from the PMO department of the client. They had a manual ‘legacy’ process to manage and schedule the transformer’s inspection work which they were handling manually on Excel sheets. Encora suggested automating this manual process by adding a new module to the existing application instead of creating a new application. This decision was made because of below advantages:
- Reuse scheduling algorithm
- Code reusability; the idea was to reuse existing APIs and avoid base code setup
- Leverage existing Azure infrastructure; no need to provision new Azure resources
Thus, this approach optimized costs and saved a lot of time as well. The client was happy and satisfied with Encora’s suggested solution of adding a new module to the existing application. Since all the users of this application were internal, we implemented Single Sign On using Open ID Connect SSO protocol and Client’s Microsoft Entra ID as Identity Provider. Please refer to this blog Implementing SSO in Enterprise Applications Using OpenID Connect if you want to read about OIDC SSO protocol. The current task was to add a new module to the existing application, and to leverage and extend Entra ID as IAM tool.
Challenges Faced
The biggest challenge here was that after the login, any user with a valid identity token issued by Microsoft Entra ID received full access to our application.
As you can see in the above diagram, both work managers and the PMO group had access to each other's modules. The client’s expectation was that specific groups should have access to only their module.
Solution Implemented
Encora decided to implement Role Based Access Control to ensure that the right role/ group had access to their own modules only. The picture below gives a high-level understanding of implementation-
All popular IAM solutions including Microsoft Entra ID have in-built support for RBAC (Role Based Access Control). We had to make minor configuration changes on Entra ID and a few lines of code changes on the API side to implement RBAC in an enterprise application within a few hours.
Entra ID Changes
- Created necessary groups on Client’s Microsoft Entra ID. These groups were created based on business functions and departments.
- Based on users’ department and business function, they were then added to these groups.
- Search for client application under App registrations. Navigate to the Token Configuration section, and then add ‘Groups’ to optional claims. With this step, we are instructing Entra ID that any token issued for this application should have ‘Group’ as an additional claim.
- The next step was to make some changes in the Manifest section of the client application. The above step of adding group as additional claim will ensure that the below highlighted line gets added to the manifest section.
- The last step on Entra ID was to update the manifest section and add “emit_as_roles” property to Optional Claims JSON. Check the yellow highlight in the screenshot below:
We have flexibility to control the inclusion of roles as optional claims in different token types. In the above screenshot we have added “emit_as_roles” to all three types of tokens-- Identity, Access and SAML.
We are done with Microsoft Entra ID changes. Four simple steps which could be done within a few minutes. These configuration changes will ensure that any identity or access token issued by this Microsoft Entra ID for this application will have an additional claim “group” property.
Please check the Entra ID generated sample Identity token for this application. You can see the highlighted part where Microsoft Entra ID included all the roles/ groups that the logged-in user is part of.
Code Changes
Microsoft Entra ID is doing its job by including roles/ groups inside issued Identity token. The next task is to validate these roles on the API side. Please note that this group validation code would vary with programming languages, but below C# code snippets will give you a high-level idea.
- The first step is to extract roles/ groups from the identity token of the authenticated user.
- You can pass these extracted roles to your front-end application to implement role-based UI/ layout. These values could be used to show/ hide the content on screen.
- Also, you can control the accessibility of API controllers by using [Authorize] filter which is in-built in .NET framework.
This ensures that this controller could be accessed only if the ‘groups’ claim of access token has any one group out of listed list.
The Entra ID configuration changes and backend (API) side code changes are done. Now, let us see the third and last step--Changes on the front-end side. We had used Microsoft-recommended MSAL (Microsoft Authentication Library) for implementing SSO in our Angular application as it provides all the security best practices for OIDC implementation in web applications. The screenshot below gives you a high-level idea about how we used Role Guard for implementing RBAC on the Angular side.
Based on the extracted roles from the Identity token, we can control the accessibility of different routes and modules in Angular application.
The best part about this above RBAC implementation was that the entire solution was done in three days: one day for research & analysis, and two days for the actual implementation. That is the beauty of using modern authentication techniques like Single Sign-On, OIDC, OAuth etc. Imagine the amount of effort and time we would have spent to implement RBAC if this were traditional username-password authentication, where we would have maintained users and roles in our database.
Also, this RBAC implementation is flexible and scalable for upcoming modules and users. Recently, we added another module to this application. All we had to do was to add a new group on Entra ID and make two lines of code changes to accommodate the newly added Entra ID business group.
Conclusion
In this blog, we covered different access control models and delved more deeply into Role Based Access Control and its advantages. There are several ways of RBAC implementation, and the Identity & Access Management based RBAC is most popular because of advantages like centralized access management, enhanced security and risk management. All popular IAM tools have built-in RBAC framework and policies. We also saw a case study where we implemented IAM based RBAC using Microsoft Entra ID as IAM tool for one of the utility and operations clients of Encora. This access control implementation was done within a short amount of time with minimal code and configuration changes on the Entra ID side.
Author Bio
Aditya Chouhan has ~15 years of IT industry experience. He has expertise in Microsoft technology stack, Azure Cloud, Application Security, and Identity & Access Management. Currently, he is working as AVP Engineering at Encora. He is also one of the Innovation leaders of Encora in Cloud Services. He holds master's degree in management of information systems from University of Nebraska, Omaha, and bachelor's in computer science from Indore, India. As part of his job at Encora, Aditya drives delivery of multiple business initiatives and provides technical assistance to multiple global engineering teams. He loves to speak and write about technology.
