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:

Type of access control products might need

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.

System Architecture 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:

Screenshots — Assigning Users to a list

Creating complex Roles where Interviewer is a role & Sales, Product, Bengaluru, etc are LDF attributes— LDF+RBAC

Credits: Nikhil Singh, Gaurav, Atul, vijay kahalekar, & Shrijata Mukherjee