Note: RBAC in MPI is minimal and early-stage. It supports only two roles with no granular permissions. We are open to feedback and suggestions on how access control should evolve.

How it works

MPI uses a simple admin / basic two-tier model. A user is either an admin (full access) or a basic user (patient search and duplicate matching only).

The role is determined by checking the user's data.groups array in Aidbox against the configured MPI_ADMIN_ROLE environment variable.

Configuration

1. Environment variables

VariableServicePurposeExample
MPI_ADMIN_ROLEBackend + FrontendGroup name that grants admin accessSIT_EMPI_ADMIN_DEV
MPI_ENABLE_AUTHENTICATIONBackendEnable authentication (true/false)true
MPI_ENABLE_AUTHORIZATIONBackendEnable authorization (true/false)true
AUTH_DISABLEDFrontendDisable auth entirely, dev mode (true/false)false

2. Aidbox User setup

We use data.groups (not data.roles) because it maps naturally to Active Directory / LDAP groups. When Aidbox is connected to an external IdP (Azure AD, ADFS, Okta, etc.), AD group memberships are propagated into data.groups automatically — so adding a user to the AD group is enough, no manual Aidbox edits needed.

Add the role string to the data.groups array of the Aidbox User resource:

{
  "resourceType": "User",
  "id": "my-user",
  "data": {
    "groups": [
      "SIT_EMPI_ADMIN_DEV"
    ]
  }
}

The value in groups must match MPI_ADMIN_ROLE exactly. If it doesn't match, the user is treated as a basic user.

For Aidbox Client resources (service accounts), the check looks at details.roles instead of data.groups.

What each role can see

FeatureAdminBasic user
Patient search & detailsYesYes
Duplicate matchingYesYes
Select matching modelYesNo
Merges pageYesNo
Non-duplicates pageYesNo
Audit logs pageYesNo
Unmerge operationsYesNo
Aidbox Resource Browser linkYesHidden
REST API (merge, unmerge, model CRUD, bulk match)Yes403 Forbidden

Basic users see only the Patients tab in the navigation. All other tabs are hidden.

Last updated: