RBAC Architecture

Role-Based Access Control (RBAC) in Clue2App manages who can access what resources and perform which actions.

Overview

Clue2App uses a hierarchical permission model:

Account
  └── Groups
       └── Roles
            └── Permissions

User Types

Type	Description	Scope
SYSTEM	Platform administrators	Access to all accounts
ACCOUNT	Account-level users	Limited to their account

Roles

Role	Permissions
ACCOUNT_ADMIN	Full account management, users, groups, apps
ACCOUNT_MANAGER	Manage users and groups only
APPLICATION_ADMIN	Full app management (create, edit, delete)
APPLICATION_MANAGER	Edit applications only
APPLICATION_DEVELOPER	Read-only access
SERVICE_ADMIN	Full service catalog control
SERVICE_MANAGER	Edit services only

Permission Matrix

Permission	ACCOUNT_ADMIN	ACCOUNT_MANAGER	APP_ADMIN	APP_MANAGER	APP_DEV
Add Users/Groups	✓
Edit Users/Groups	✓	✓
Add Applications	✓		✓
Edit Applications	✓		✓	✓
View Applications	✓	✓	✓	✓	✓

Architecture

How Groups Work

1. Users belong to Groups - A user can be in multiple groups
2. Groups have Roles - Each group is assigned one role
3. Roles grant Permissions - The role determines what actions are allowed
4. Permissions are additive - Users get the union of all their groups' permissions

Example

User: alice@example.com
  └── Groups: [DevTeam, QATeam]
       ├── DevTeam → APPLICATION_ADMIN
       │     └── Permissions: addApplications, editApplications
       └── QATeam → APPLICATION_DEVELOPER
             └── Permissions: readOnly

Result: Alice can create, edit, and view applications

API Endpoints

User Management

Method	Endpoint	Description
GET	/user/account/{accountId}	List account users
POST	/user/account/{accountId}	Create user
PUT	/user/{userId}	Update user
DELETE	/user/{userId}	Delete user

Group Management

Method	Endpoint	Description
GET	/group/account/{accountId}	List account groups
POST	/group/	Create group
PUT	/group/{groupId}	Update group

Role Management

Method	Endpoint	Description
GET	/role/	List available roles

Best Practices

Principle of Least Privilege

• Assign users the minimum permissions needed
• Use APPLICATION_DEVELOPER for read-only users
• Reserve ACCOUNT_ADMIN for account owners

Group Organization

• Create groups by team or function (e.g., "Backend Team", "DevOps")
• Avoid assigning roles directly to users
• Use groups to manage permissions at scale

Account Structure

• One account per organization or project
• Use SYSTEM type only for platform operations
• Account owners should be ACCOUNT_ADMIN

Planned Improvements

Future enhancements to the RBAC system:

1. Resource-Level Permissions - Control access to specific apps/services
2. Custom Roles - Create account-specific roles
3. Role Hierarchy - Inherit permissions from parent roles
4. Audit Logging - Track all permission changes
5. Temporary Elevation - Time-limited permission grants

---

Need help? Contact support or visit our GitHub Issues.