Managing Access Control Rules
The Access Control Management interface lets you create and manage Attribute-Based Access Control (ABAC) rules that control API access in your BioT environment.
BioT comes with default ABAC rules that enforce basic security and HIPAA compliance. This interface allows you to add custom rules or modify existing ones to meet your specific organizational requirements.
These rules apply to all API access, whether calls are made directly via the REST API or through BioT's web portals (Manufacturer Portal, Organization Portal).
Common use cases for customizing access control:
- Restricting sensitive operations to specific user roles or templates
- Blocking certain user types from administrative endpoints
Note: Some advanced ABAC configurations are not yet available through the UI. If you need a configuration not supported here, contact BioT support for assistance via the API.
Getting Started
To access Access Control Management:
- Log in to the BioT Console
- Click the Access Control tab in the top navigation
Feature AvailabilityAccess Control Management is not enabled by default. If you don't see the Access Control tab in your Console, contact BioT support to enable this feature for your environment.
Access Control Components
Access control in BioT is built from three main components that work together:
Rules - A rule is a complete access control policy that determines what happens when a specific API is called. Each rule combines conditions and actions to enforce security requirements.
Conditions - Conditions are criteria that evaluate information about the user (initiator) or the data being accessed (entity). For example, "is the user a nurse?" or "does the user belong to organization X?". Conditions are reusable and can be used in multiple rules.
Actions - Actions define what happens when all conditions in a rule evaluate to true. The primary action is ACCESS_DENIED_ACTION, which blocks the API request.
How Rules Execute
Multiple rules can be attached to the same API endpoint. When an endpoint is called, BioT evaluates all attached rules sequentially:
- Each rule checks its conditions
- If all conditions in a rule are true, the rule executes its actions
- If any condition is false, that rule is skipped and the next rule runs
- Rules continue to run in sequence until all rules are evaluated or until a rule denies access
Important: If any rule triggers ACCESS_DENIED_ACTION, evaluation stops immediately. The API returns 403 Forbidden and no subsequent rules are evaluated.
Example Scenario
Throughout this guide, we'll use a practical example to demonstrate how to create and manage access control rules: preventing nurses (caregiver template type) from creating patients.
In this scenario:
- We'll create a condition that checks if a user is a nurse caregiver (template name = "nurse")
- We'll create a rule that applies the "access denied" action to the "create patient" endpoints
- When a nurse attempts to create a patient, the rule's condition evaluates to true, triggering the action and denying access
The Access Control interface has two main tabs: Manage Conditions and Manage Rules.
In the following pages, we'll walk through creating the conditions and rules for this example.
Updated 14 days ago
