Attribute-Based Access Control (ABAC)

overview 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 feature benefits 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 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 example 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/\&lt;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 attributes 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 steps to implement abac policy feature 1\ defining policies 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 { "resourcepath" "/core/api/v\[1 2]/participants/users/\[a za z0 9]{1,15}/ ", "resourcepathformatted" "/core/api/v\[1 2]/participants/users/facility/{{facilityid}}", "attributepath" "$ data facilityid", "requestparameter" "facilityid", "allowedhttpmethods" \["get"] } the resourcepathformatted field can be set to null to indicate the resource is not related to abac 2\ tenant level configuration 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}} 3\ implementing validate api 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' { "userid" "uuid", "userattributepath" "facilityid", "userattributevalue" "blr hq fc" } 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