Guide to building an Access Control & Permissions modules for SaaS Applications
Belong moved from Belong Hire, a sourcing tool, towards building a CRM & an Applicant Management System (ATS+Careersite+Onboarding+Talent CRM). With this, the type of users & their needs became too complex to be served by simple pre-defined roles & permissions. With more complex use cases came more user-data & hence more security protocol. We want to give you a quick glimpse into our journey in building an Access Control & Permissions modules for SaaS Applications.
On a side note, to decide what to build & how to build, we follow the below-mentioned process:
So, which type of access controls do you need?
Access control can differ by degree of granularity & type of use case. Some are listed below:
With so many types of access control, which one should I use?
To answer this we need to evaluate some key factors:
- What is your product’s target market segment?
- What are the different type of personas that will be using the app?
- What is the type of industry/function your product serves? Depending on the industry one operates in, the product may need to have a complex access & permissions layer with all role-based, relationship-based, LDF-based, & user-based.
- Is your product inheriting roles & relationship data from some other system or is it defined in your product? In case, you are inheriting this data from some other system & you need to think of a system which can update role & relationship continuously.
- What type of data does your product store? For products that store sensitive data, one may need complex access & permissions layer since only limited data needs to be stored for different personas.
Answering some of these questions via user/buyer research, studying a competitor, or sorting through customer support & feature requests can help validate the complexity of the system you need & would define the problem space. Most products can live with simple role-based access module.
For Belong, based on our research (user, competition, buyer, customer support, etc.), we realized we needed a module that could:
- Provide a customisable role & attribute-based access
- Control permissions to even one single user
- Only show data which is relevant and needed
- Can serve the needs of a variety of organizations
- Can be managed by clients themselves
A bit on the technology
We chose Access Control Lists to deploy Access & Permission controls since the user & business requirements were complex. ACL as a framework is powerful to build any kind of access control, be it Attribute-based, Role-based, User Level, LDF, etc. You can take a look at the architecture in this diagram.
How do I define a solution?
Key steps in defining a solution once you have validated user need & defined an MVP are:
- Understanding your information & system architecture, as this will allow you to figure out the right grouping & ordering logic and, hence will influence the design of your permissions layer UX/UI
- Map your tech systems & all APIs to understand what capabilities can be controlled to what level of granularity
- Map the tech capabilities with user need & fill any gaps
- Define the granularity of attribute-based control depending on the incoming data
- Define how access control for users with multiple permissions work — will it be union or intersection or any other rule
- Define sound defaults with preset roles so first-time app users can just use preset default roles, & not get lost with irrelevant content & prevent a security breach
A bit on the UX & Information Grouping
- Group permission logically so that the app information architecture is inherited in the grouping logic & hence users don’t spend extra mental bandwidth on this
- Keep the language/copy of permission simple & relate it to already existing behaviours in the app; avoid introducing new terms
- Build the module in phases; the first version need not be super complex but certainly imagine & make your team imagine the future
- Document the whole system well so the users can refer to it whenever in need; publish it for users to refer in future
Finished Product for Belong
For Belong, the final system is robust & can handle complex access & permissions requirements. The system is built so it can handle most future use case and even be plugged into future products. Some screenshots for reference below: