Role-Based Access Control and Dashboard Access
Overview
Role-based access control (RBAC) refers to the idea of assigning permissions to users based on their role within an organization. It offers a simple, manageable approach to access management that is less prone to error than assigning permissions to users individually. In our instance we will use RBAC with our applications and external APIs.
This is not to be confused with how internal users gain access to the Auth0 Dashboard. Specific roles are already in place within Auth0 that are assigned to a user at creation. These roles allow them to have limited access to Auth0 Dashboard features so they can complete their jobs without putting production applications at risk and complying with the least privilege principle.
RBAC
When using RBAC for Role Management, you analyze the needs of your users and group them into roles based on common responsibilities. You then assign one or more roles to each user and one or more permissions to each role. The user-role and role-permissions relationships make it simple to perform user assignments since users no longer need to be managed individually, but instead have privileges that conform to the permissions assigned to their role(s).
Benefits
RBAC has many benefits including:
- create systematic, repeatable assignment of permissions
- quickly add and change roles, as well as implement them across APIs
- integrate third-party users by giving them pre-defined roles
RBAC Model
Roles
Essentially, a role is a collection of permissions that you can apply to users. Using roles makes it easier to add, remove, and adjust permissions than assigning permissions to users individually. As your user base increases in scale and complexity, roles become particularly useful.
Take the following example with two APIs that could exist, the RCC API and the Events API.
The RCC API could have the rcc:route or rcc:user permission and the Event API could have a read:events permission. These permissions could then be gathered into a role called RCC Member and assigned to the a user.
Enable Role-Based Access Control for APIs
You can enable role-based access control (RBAC) using the Auth0 Dashboard or the Management API. This enables the API Authorization Core feature set. To do this you must Enable RBAC on any of the APIs defined in Dashboard > Applications > APIs.
Based on what is documented in Confluence we should create the following roles via Terraform. When a user is lazy migrated we can match their current groups against these pre-defined groups and set them in Auth0.
| Group | Role |
|---|---|
| Guest | customer:guest |
| Registered | customer:registered |
| RCC | customer:rcc |
| Industry Partner Programme (IPP) | customer:ipp |
| Ambassador | customer:ambassador |
| EF | customer:pro |
| Board | customer:board |
| Investors | customer:investors |
| Staff | customer:staff |
| Trading | customer:trading |
Dashboard Access
We can assign team members roles to allow them to have limited access to the Dashboard. This is not to be confused with RBAC as that is to limit access to Applications or APIs. Unfortunately the roles for the dashboard are limited to:
| Role | Permission | Notes |
|---|---|---|
| Admin | Read and write access to all resources in the Auth0 Dashboard. | We should limit this to as few accounts as possible. Admins making changes means that we cannot replicate our tenants effectively. |
| Editor - Specific Apps | Read and write access to specific applications only. | |
| Editor - Connections | Read, write, and create access to all types of connections. | |
| Editor - Users | User management operations (create, delete, block, unblock, reset MFA, reset password, update metadata, assign roles, etc.) and access to logs. | Perfect for Customer Service but as we are moving functionality to Dixa we should not assign this role. |
| Viewer - Users | Read-only access to users and logs. | We should only consider this for Customer Service accounts. |
| Viewer - Config Settings | Read-only access to all configuration settings (applications, APIs, rules, security settings, etc.) except for sensitive information such as secrets, billing, users, and logs. | Perfect for our Product and Tech teams. Should be used to review tenants before creating tickets to update them. |
| Support Access | Access to tickets (submit, view, and update) and aggregated metrics. |
Tenant members with less privileged roles will have a restricted Dashboard experience and they will have access only to the sections and actions they can perform. The table below shows the specific feature permissions for each role.
| Dashboard Section | Subsection | Admin | Editor - Specific Apps | Editor - Connections | Editor - Users | Viewer - Users | Viewer - Config | Support Access |
|---|---|---|---|---|---|---|---|---|
| Get Started | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Activity | Stats | ✅ | ❌ | ❌ | ✅ | ✅ | ❌ | ✅ º |
| Applications | Applications | ✍ | ✍ *¶ | ❌ | ❌ | ❌ | 👁 ‡ | ❌ |
| APIs | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 ‡ | ❌ | |
| SSO integrations | ✍ | ✍ *¶ | ❌ | ❌ | ❌ | 👁 ‡ | ❌ | |
| Authentication | Database | ✍ | ❌ † | ✍ | ❌ | ❌ | 👁 ‡ | ❌ |
| Social | ✍ | ❌ † | ✍ | ❌ | ❌ | 👁 ‡ | ❌ | |
| Enterprise | ✍ | ❌ | ✍ | ❌ | ❌ | 👁 ‡ | ❌ | |
| Passwordless | ✍ | ❌ | ✍ | ❌ | ❌ | 👁 ‡ | ❌ | |
| Organizations | Organizations List | ✅ | ❌ | ❌ | 👁 | 👁 | 👁 | ❌ |
| Organization Overview | ✅ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ | |
| Organization Members | ✅ | ❌ | ❌ | 👁 | 👁 | ❌ | ❌ | |
| Organization Invitations | ✅ | ❌ | ❌ | 👁 | ❌ | ❌ | ❌ | |
| Organization Connections | ✅ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ | |
| User Management | Users | ✍ | ❌ | ❌ | ✍ | 👁 | ❌ | ❌ |
| Roles | ✍ | ❌ | ❌ | 👁 | 👁 | 👁 | ❌ | |
| Branding | Universal Login | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ |
| Custom Domains | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ | |
| Email Templates | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ | |
| Email Providers | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 ‡ | ❌ | |
| Security | Attack Protection | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ |
| Multi-factor Auth | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 ‡ | ❌ | |
| Monitoring | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Actions | Flows | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ |
| Library | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ | |
| Auth Pipeline | Rules | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 ‡ | ❌ |
| Hooks | ✍ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Monitoring | Logs | ✅ | ❌ | ❌ | 👁 § | 👁 § | ❌ | ❌ |
| Streams | ✍ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Marketplace | ✍ | 👁 | 👁 | 👁 | 👁 | 👁 | ❌ | |
| Extensions | ✍ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Settings | General | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ |
| Subscription | ✍ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Tenant Members | ✍ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Signing Keys | ✍ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Advanced | ✍ | ❌ | ❌ | ❌ | ❌ | 👁 | ❌ | |
| Get Support | Support Tickets - Create | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Support Tickets - View All | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | |
| Quota Reports | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Usage Reports | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Compliance | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Tenant Tagging | ✍ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Production Checks | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | |
| Notifications | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
As with RBAC we should assign roles via Terraform. On creating Tenants we should create our Admin accounts and demote them to Viewer - Config when they have finished their respective tasks.