Attribute-Based Access Control in a Microservices Architecture
Access control is a fundamental element of the security infrastructure of any company. Every security officer wants to apply the principle of less privilege, zero-trust, segregation of duties, and other best practices without harming the company workflow. There are several approaches to organizing an access management system. In this blog, we analyze the two most popular access control models: role-based and attribute-based. We’ll talk about attribute-based access control implementation challenges and walk through a POC implementation.
WHAT IS ROLE-BASED ACCESS CONTROL (RBAC)?
Role-based access control (RBAC) is an access control method based on defining employee roles and corresponding privileges within the organization. The idea of this model is that every employee is assigned a role. Every role has a collection of permissions and restrictions. An employee can access objects and execute operations only if their role in the system has the relevant permissions.
For example, a company’s accountant should be allowed to work with financial information but shouldn’t have access to client contact information or credit card data.
A user might be assigned to one or several roles. When a new employee comes to your company, it’s easy to assign a role to them. And when someone leaves the company, you don’t need to change the role parameters or a central policy.
Let’s consider the main components of the role-based approach to access control:
● User an individual (with UID) with access to a system
● Role a named job function (indicates the level of authority)
● Permission equivalent to access rights
● Session a mapping between a user and a set of roles to which the user is assigned in the context of a working time
● Object a system resource that requires permission to access
● Operation any action in the protected network
The basic rules of RBAC are:
● A user can execute an operation only if there is a role assigned to the subject.
● Identification and authentication are not considered operations.
● All user activities are carried out through operations.
WHAT IS ATTRIBUTE-BASED ACCESS CONTROL (ABAC)?
Attribute-based access control is a model that evolved from RBAC. This model is based on establishing a set of attributes for any element of your system. A central policy defines which combinations of user and object attributes are required to perform any action. Let’s consider the main components of the ABAC model :
Let’s consider the main components of the ABAC model:
- Attribute — a characteristic of any element in the network. An attribute can define:
- User characteristics — employee position, department, IP address, clearance level, etc.
- Object characteristics — type, creator, sensitivity, required clearance level, etc.
- Type of action — read, write, edit, copy, paste, etc.
- Environment characteristics — time, day of the week, location, etc.
- Subject — any user or resource that can perform actions in the network; a subject is assigned attributes to define its clearance level
- Object — any data stored in the network; objects are assigned attributes to describe and identify them
- Operation — any action taken by any subject in the network
- Policy — a set of rules allowing or restricting any action in your information retrieval system; rules are “IF/THEN” statements based on attributes of any element (user, resource, environment)
ABAC ARCHITECTURE :
This picture highlights how ABAC works: you have the notion of an interceptor or enforcement point (PEP) which intercepts the flow between the user and the app. This enforcement point will check whether the user can get access to whatever it is they want to get access to (data, an API call, a widget…). The idea is that the PEP is local to what you are protecting but the decision-making is centralized and that is what will give
you consistent authorization. You can have PEPs for SPA, for APIs… And they can enforce the same authorization policies consistently.
The PDP or Policy Decision Point is the one that processes the authorization requests and evaluates them against a set of policies you would have previously written. The language policies are written are typically alfa or xacml.
The PIP (Policy Information Point) is an abstract representation of your data sources and user directories (AD, DB…) where you might store additional information about the users and resources. They can be useful to help make the right decision.
ROLE-BASED ACCESS CONTROL (RBAC) VS ATTRIBUTE-BASED ACCESS CONTROL (ABAC)
Let’s compare these two popular approaches — role-based access control vs attribute-based access control — to determine the pros and cons of each.
RBAC pros and cons
RBAC is the most popular approach to restricting access. The main advantage of this model is that companies no longer need to authorize or revoke access on an individual basis, bringing users together based on their roles instead. Establishing a set of roles in a small or medium-sized company isn’t challenging. On the other hand, setting up such a system at a large enterprise is no easy task.
There are several limitations to the RBAC model. You can’t set up a rule using parameters that are unknown to the system before a user starts working. Permissions can be assigned only to user roles, not to objects and operations. Also, using RBAC, you can restrict access to certain actions in your system but not to certain data.
ABAC pros and cons
The key benefit of ABAC is that it grants access based not on the user role but the attributes of each system component. This way, you can describe a business rule of any complexity. Even if you need to make certain data only accessible during work hours, it can be easily done with one simple policy. On top of that, ABAC rules can evaluate attributes of subjects and resources that are yet to be inventoried by the authorization system.
As for ABAC limitations, this type of system is hard to configure due to the way policies must be specified and maintained. It’s difficult to perform a before-fact audit and determine the permissions available to a specific user. It could be impossible to determine risk exposure for any given employee position.
Gartner predicts that 70% of all organizations will use ABAC by 2020 Combining RBAC and ABAC
Companies often start with implementing a flat RBAC. This model is easier to set up and maintain. As organizations grow and manage more sensitive data, they realize the need for a more complex access control system. RBAC and ABAC can be used together, with RBAC doing the rough work and ABAC complementing it with finer filtering.
Three RBAC-An approaches handle relationships between roles and attributes:
- Attribute-centric. A role becomes the name of one of the user attributes. It resembles a job title. In such a model, the “role” attribute is used to mark a set of attributes required for a certain position.
- Role-centric. Attributes are added to constrain roles. In such a model, attributes can reduce permissions available to a user. This approach strengthens the security of your data.
- Dynamic roles. Attributes such as time of day are used to determine the subject’s role. In some cases, a user’s role can be fully determined by dynamic attributes.
ABAC Microserive sample application
DEVELOPMENT ENVIRONMENT
TECHNOLOGIES
- C#.NET
- ASP.NET WEB API Core
- Azure cloud services
OPEN SOURCE TOOLS USED
- Ocelot (For API Gateway Aggregation)
- Swashbuckle (For API Documentation)
WEBAPI ENDPOINTS
The application has four API endpoints configured in the API Gateway to demonstrate the features with token-based security options enabled. These routes are exposed to the client app to consume the back-end services.
END-POINTS CONFIGURED AND ACCESSIBLE THROUGH API GATEWAY
- “/user/authenticate” — To authenticate a user and issue a token
- “/Products” — To retrieve products information.
- “/Customers” — To retrieve customer's information.
END-POINTS IMPLEMENTED AT THE MICROSERVICE LEVEL
- “/api/user/authenticate”- To authenticate a user and issue a token
- “/API/Products” -To retrieve products information.
- “/API/Customers” — To retrieve customer's information.
SOLUTION STRUCTURE
- Azure AD B2C Authentication
- Handles the authentication part using username, password as input parameters and issues a JWT Bearer token with Claims-Identity info in it.
- Gateway Service
- Validates the incoming HTTP request by checking for the authorized JWT token in it.
- Handle authorization based on role base claim.
- Reroute the HTTP request to a downstream service.
- Use Ocelot open source NuGet package to handle all gateway operations with the help of configuration settings.
- MVC Application
- An MVC client app that connects to API Gateway, can be used to log in with a username, password and display products & customers’ information.
- Product Service
- Supports HTTP Get methods. Receives HTTP requests for these methods.
- Reads Identity information from the Authorization Header which contains the Bearer token
- Returns the response result to the client
- Customer Service
- Supports HTTP Get methods. Receives HTTP requests for these methods.
- Reads Identity information from the Authorization Header which contains the Bearer token
- Returns the response result to the client
- Authorization Class Library
1. A class library is used to contain all policy definitions & verification logic
- Authorization Handler Service
- Service is used to handle Policy configuration settings at runtime so no need to compile a solution or projects
- Provide UI to handle all CRUD operations related to Policy configuration JSON.
- We can provide a list of Roles through Application JSON. So we can provide a list of configurable roles to an Authorization Handler Service & apply a Policy with a role's access to an API available in Microservices.
APPLICATION ARCHITECTURE
The sample application is built based on the microservices architecture. There are several advantages in building an application using Microservices architecture like Services can be developed, deployed & scaled independently. The below diagram shows the high-level design of Back-end architecture.
- Azure AD B2C Authentication — Authenticates user based on username, password, and issues a JWT Bearer token that contains Claims-based identity information. Azure AD B2C Authentication Supports Multiple Identity Provide authentication like Google, Amazon, LinkedIn, etc.
- Product Microservice — Perform Product-related data operations.
- Customer Microservice — Perform Customer related data operations.
- API Gateway — acts as a center point of entry to the back-end application, Provides data aggregation and the communication path to microservices. Also, maintain claim-based authorization. All settings are managed using the configuration settings JSON file.
- Authorization Class Library — Class library is used to contain all ABAC policy definitions & verification logic.
- Authorization Policy Handler Service — Service is used to handle Policy configuration settings at runtime so no need to compile a solution or project. Using a JSON configuration file we can change policy structure, add a policy or delete policy from the list of defined policies for microservice API at Runtime. Authorization Policy handler UI is accessible only for Admin users otherwise we are getting an “Access denied” error.
How to choose an access control solution
When it comes to security, it’s crucial to plan and monitor your access control processes carefully. Use a robust access management tool to help you set up your access control, and regularly review your setup to make sure it still fits your organizational needs.
Whether you invest in Access Rights Manager make sure the tool you choose can set up a protocol and mechanism to ensure users have the correct access to what they need to do their jobs, and nothing more.
Conclusion
Using a customized ABAC POC, we can easily perform authorization and authentication over different microservices at runtime without changing the actual application code.
Also, use various Azure B2C identity providers to access applications in different portals. This solution will provide a centralized microservice configuration as well as policy deployment fetchers. Here we resolved all kinds of API Gateway Desing Pattern In Microservices problems and provide a solution to deploy ABAC policy at runtime.
Use the below link to download ABAC microservice architecture sample application from Github:- https://github.com/chetandravekar/ABACMicroserviceArchiTecturePOC.git
