Users, Roles & Modules (RBAC)

Role-based access control: modules define available actions, roles bundle those actions, and users are assigned roles.

How RBAC fits together

Module ──▶ Sub-module ──▶ Action        (the catalog of what's possible)
                 ▲
                 │ referenced by actionId
                 │
Role  ──▶ [ module actions ]            (a named bundle of permissions)
                 ▲
                 │ roleId / roleName
                 │
User  ──▶ Role                          (who gets the bundle)

1. Modules (the permission catalog)

Modules describe the features, sub-modules and actions that roles can grant.

POST /v1/onboarding/module-data
Authorization: Bearer <JWT_TOKEN>

{
  "moduleType": "Module Access",
  "createdBy": "admin_user",
  "modules": [
    {
      "moduleName": "Banking",
      "subModules": [
        { "subModuleName": "Dashboard", "action": ["VIEW"] }
      ]
    }
  ]
}

Operation	Endpoint
List modules	`GET /v1/onboarding/module-data/listModules`
List module-data	`POST /v1/onboarding/module-data/list`
Update	`PATCH /v1/onboarding/module-data` (send `id`)
Enable / disable	`PATCH /v1/onboarding/module-data/{id}/activation?isActive=false`

2. Roles (bundles of permissions)

A role references module actions by their actionId (UUIDs from the module catalog).

POST /v1/onboarding/roles
Authorization: Bearer <JWT_TOKEN>

{
  "roleName": "Operations",
  "modules": [
    { "moduleId": "1", "actionId": ["90c74423-ddd8-42b0-9234-e3ac92df1b25"] }
  ],
  "createdBy": "adminUser",
  "description": "Operations team role",
  "isEnabled": true
}

Operation	Endpoint
List (paged)	`POST /v1/onboarding/roles/list?page=1&size=5`
Get by id	`GET /v1/onboarding/roles/{id}`
Id + name list	`GET /v1/onboarding/roles/role-list` (optional `?tenantCode=EDGEONE`)
Update	`PATCH /v1/onboarding/roles` (send `id` + `modifiedBy`)
Enable / disable	`PATCH /v1/onboarding/roles/{id}/activation?isActive=true`

📘 Note

On update, the modules array may omit moduleId and supply only actionId, depending on how the role's permissions are being adjusted. Confirm the exact merge semantics with the platform team — marked To be confirmed.

3. Users (assigned a role)

POST /v1/onboarding/users
Authorization: Bearer <JWT_TOKEN>

{
  "firstName": "Jane",
  "lastName": "Doe",
  "mailID": "jane.doe@example.com",
  "isActive": true,
  "roleId": "8d03710e-2b79-4e78-9905-44520224d956",
  "roleName": "admin",
  "mfaEnable": true
}

Field	Type	Description
`firstName` / `lastName`	string	User's name.
`mailID`	string (email)	User's email address / login id.
`isActive`	boolean	Active on creation.
`roleId`	string (UUID)	Assigned role id.
`roleName`	string	Assigned role name (must correspond to `roleId`).
`mfaEnable`	boolean	Whether MFA is required for this user.

Operation	Endpoint
List (paged)	`POST /v1/onboarding/users/list?page=1&size=10`
Get by id	`GET /v1/onboarding/users/{id}`
Update	`PATCH /v1/onboarding/users` (send `id`)
Enable / disable	`PATCH /v1/onboarding/users/{id}/activation?isActive=false`
Set / reset password	`PATCH /v1/onboarding/users/password` (encrypted fields)

💡 Tip

Create the module catalog and roles before creating users, so each user can be assigned a valid roleId at creation time.