Identity & RBAC.
Manage users, roles, permissions, and authentication providers with hierarchical path-based access control.
Users
Full CRUD operations for user management. Each user has an email, display name, assigned roles, and an optional user_path that determines their scope within the organisation hierarchy. Users can be created via the API or synced from an OIDC provider.
| Operation | Endpoint | Description |
|---|---|---|
| List | GET /users | List all users with pagination and search |
| Create | POST /users | Create a new user with roles and path |
| Get | GET /users/:id | Get user details by ID |
| Update | PATCH /users/:id | Update user fields and role assignments |
| Delete | DELETE /users/:id | Remove a user and revoke all sessions |
Roles
Roles are named collections of permission grants. They support full CRUD and can be assigned to any number of users. Common roles include admin,operator, developer, and viewer, but you can define any role name.
| Operation | Endpoint | Description |
|---|---|---|
| List | GET /roles | List all roles |
| Create | POST /roles | Create a role with permission grants |
| Get | GET /roles/:id | Get role details and grants |
| Update | PATCH /roles/:id | Update role name or grants |
| Delete | DELETE /roles/:id | Delete a role (unassigns from users) |
Permissions System
Permissions are granular action-resource pairs (e.g.workflow:read,provider:write,user:delete). They are not assigned directly to users but are grouped into roles. The system supports wildcard permissions (*:*for full access) and resource-scoped permissions (workflow:*for all workflow actions). Every API call is authorised against the caller's effective permissions.
OIDC Providers
Aurora supports external identity providers via OpenID Connect. Configure one or more OIDC providers (Google Workspace, Azure AD, Okta, etc.) and users will be able to authenticate using their existing corporate credentials. The gateway maps OIDC claims (email, groups) to Aurora users and roles automatically. Token validation, refresh, and revocation are handled transparently.
User-Role Assignment
Users can hold multiple roles. When a user authenticates, their effective permissions are the union of all permissions from all assigned roles. Role assignments can be managed via the user CRUD endpoints or via dedicated assignment endpoints. Changes take effect immediately — no session refresh required.
Role-Permission Grants
Permission grants are managed at the role level. When you update a role's grants, every user assigned that role immediately gains or loses the corresponding permissions. This makes it easy to enforce organisation-wide policy changes — update the "developer" role once and every developer is affected.
User Path Scoping
Every user can be assigned a user_path — a hierarchical path like /org/eng/team-alpha. This path is used by the workflow engine to determine which policies apply to the user's requests. Combined with role-based permissions, path scoping provides bothwho can do what andwhich policies apply to their traffic.