Website logo
Docs
API Reference
Postman Collection
Release Notes
Navigate through spaces
⌘K
Introduction
Overview
Getting started with the OS1 Platform
Getting started with building Apps
Concepts
Working with Callbacks
Console UI Overview
Custom Code
Working with GraphQL
Custom Attributes Ownership
Attribute-Based Access Control (ABAC)
Data Listing and Query (DLQS) Search
Core API dev guides
Overview
Authentication And Authorization
Participant
Container
Dispatch
Orchestrator
Workflow
Secure Data Storage
File Management
State Machine
Entity
Notification
Motion Tracking System
Location
Platform Order Management
Address
Scheduler
Logistics Framework API Dev guides
Overview
LogisticsOrder API
User API
Facility API
Vehicle API
How-To Guides
Integrate Your Application with Console UI
Integrate with Participants
Integrate with Containers
Integrate with Users
Integrate with Vehicles
Integrate with Facilities
Integrate with Entities
Integrate with Dispatch
Integrate with Logistics Order
Integrate with Platform Order Management
Integrate with Location Service
Integrate with Orchestrator
GraphQl Schemas
GraphQL: Dispatch Queries
GraphQL: Order Queries
GraphQL: Workflow Queries
GraphQL: Container Queries
Platform SDKs
SDK Overview
Sample Apps
Vehicle Management App
Container App
Resources
FAQs
Glossary
Data Types Used in OS1
Development Guidelines
Entity, Event, and Reason Codes
Service/API Level Error Codes
Docs powered by Archbee
Concepts

Attribute-Based Access Control (ABAC)

8min



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:

  1. 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.
  2. Policy-Based Approach: With ABAC, you define policies that the system then enforces. This approach ensures a consistent application of your access control policies.
  3. 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.
  4. 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.

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:

JSON
{
"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'.

JSON
{
"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.

Updated 11 Aug 2023
Did this page help you?
PREVIOUS
Custom Attributes Ownership
NEXT
Data Listing and Query (DLQS) Search
Docs powered by Archbee
TABLE OF CONTENTS
Overview
Feature Benefits
Example
Attributes
Steps to Implement ABAC Policy Feature
1. Defining Policies
2. Tenant-Level Configuration
3. Implementing Validate API
Docs powered by Archbee