Attribute-Based Access Control (ABAC)
Attribute-Based Access Control (ABAC) is an advanced method of controlling access to resources. In contrast to Role-Based Access Control (RBAC), ABAC allows for a more granular and dynamic form of access control based on multiple attributes of the subject, resource, and environment. The ABAC Policy feature allows developers to manage users' access to an API endpoint (resource) based on the user's permissions.
The ABAC Policy Feature offers multiple benefits:
- Granular Access Control: By using attributes to control access, you can define fine-grained access control policies that are specific to the individual user, resource, and context. This level of control is beyond what RBAC can offer.
- Policy-Based Approach: With ABAC, you define policies that the system then enforces. This approach ensures a consistent application of your access control policies.
- Flexibility: ABAC policies can consider any attribute, allowing for a dynamic and flexible approach to access control. This flexibility is beneficial in complex environments where access needs can change rapidly.
- Scalability: ABAC scales to handle large numbers of users and resources. As your system grows and becomes more complex, ABAC can continue to provide robust access control.
NOTE
Remember, for ABAC to work, ABAC-related config should exist for the tenants. If there is no ABAC-related configuration, no policies will be evaluated during authorization. During the authorization process, RBAC is always the initial level. If ABAC is enabled, it serves as a secondary layer of authorization, offering more comprehensive and detailed access control. This layered approach enhances security and guarantees that access is only granted when both RBAC and ABAC conditions are satisfied.
To confirm if ABAC is enabled, call the GET /v1/aaa/tenants/{tenantId}to retrieve the tenant details. In the response, check if isAcvtive in the abacConfig array is set to true.
Let's consider a scenario where you have facility and department set as indexed custom attributes of user type participant.
In this context, if ABAC is enabled and the Validate API returns success (HTTP 200 status code), a GET method on /coreos/participants/users/facility/<facility_id> will return users whose facility attribute is set to <facility_id>
However, if the Validate API returns a failure (any HTTP status code other than 200) when ABAC is enabled, the user will receive a 403: Forbidden as the response. This enforces the policy that only users with the correct facility_id attribute have access to the specified resource.
This example illustrates the granular control over resource access that can be achieved through the use of ABAC policies, enhancing security and ensuring that only authorized users have access to specific resources.
Attribute Name | Description |
attributePath | That SON path in ValidateAPI response for requestParameter value. JSON path value will be matched with requestParameter value. [optional] This field is only be present in ABAC related resources. |
requestParameter | Value of this attribute used for applying ABAC policy. |
resourcePathFormatted | Resource Path with naming conventions for each resource path. [optional] This field will only be present in ABAC related resources. Nullable: true |
To define a policy, you need to use the following API call:
PUT /core/api/v1/aaa/apps/{{appId}}/resources/{{resourceId}}
Here is request body example:
The resourcePathFormatted field can be set to null to indicate the resource is not related to ABAC.
The ABAC feature requires access to user attributes which are not available in AAA (Authentication and Authorization). To evaluate these attributes, an API needs to be created in an application. This can be configured in AAA using the following API call:
PUT /core/api/v1/aaa/tenants/{{tenantId}}
When implementing the POST API, this will validate if the userId specified by the parameter 'userId' has access to the attribute present at 'userAttributePath' with the value specified by the 'userAttributeValue'.
The above example indicates that the function should return success(200) when the user has access to the attribute facilityId and its value is BLR_HQ_FC. If the user does not have access, it should return a non-HTTP success code.