Below are some baseline considerations for Role Based Access Control in SAAS applications.
A role is a grouping of permissions that can be assigned to a user or service-account. Most people think of predefined roles that are configured by the service provider; however, a service provider can opt to allow customers to create custom roles based on selections of permissions.
Generally, your permissions sets that can be assigned to roles will be CRUD (Create Read Update Delete) style, but you can quickly gain some nuance, like being able to edit or delete your own data.
- Internal Vs End User Roles
- Opacity in roles can be problematic.
- How can you make it more transparent for a business type user to understand how to collaborate with others if their role is not sufficient to get a job done?
Depending on your organization structure or business objective, you might get granular in the roles for a certain business unit.
- Customer Service Rep
- Consider - what if any customer data can they access.
- Sales (Access scoped to creating clients and managing their own)
- HR / Security (onboarding, offboarding, role adjustment)
- Finance (is your financial & operational source of truth in your application or with your banking/payments processing service provider?)
- Consider - can you delegate their needs to your payments provider?
- In cases where your financial team members or respective auditors need to verify records or customers, that will generally be a read only role.
- Auditors - Financial & Security
- Avoid doling out “God Mode” Admin accounts at all costs.
- Do you have a process for elevating or assigning composite or multiple roles to an individual?
- If for instance you have a team member that works in Customer Service and Sales, how can you avoid having to elevate them to an admin role to do both jobs successfully?
End User Roles
- Admin (Full create, update, read & delete permissions for the account/organization)
- Maintainer (Full Access besides User Managment - else you open yourself up to privilage escalation sitations)
- Standard User (Most Access besides User Managment - typically does not allow destructive activities)
- Could also encapsulate a regular user like in twitter
- Pure User Management
- Guest/Read Only (possibility of being scoped to a single document/resource)
End User Notes
- Depending on your target market, you might need to integrate with a customer’s SSO provider
- Plan to map your roles to a customer’s IT governence
- Will you bill differently for each role?
- Do your Guest/Read Only users have the ability to leave comments? (Many product allow this.)
- Do you leverage roles to help maintain subscription status access? Think Free vs Premium vs Business, etc.
- Expiring Memberships
- Requested Escalation
- Temporary Escalations
- Approval flows (if a user cannot complete a task, can they submit the data where another user can approve/deny the change?)