As a SaaS startup, you know your product will be used in different ways by different customers, requiring different user roles. Have you considered all of them? After all, SaaS user management and permission handling is a critical aspect of many apps. You also need to consider access control, which users will be allowed to perform which actions, and generally how you will implement web application user management best practices.

If you feel overwhelmed already, don’t worry. Relevant is a SaaS engineering company with in-depth expertise in mobile and web application development. We help startups and enterprises build highly-performant, secure, and scalable products that deliver value to their customers. With expertise ranging from retail and fintech to IoT, travel, and construction, we can implement various ideas in well-designed, intuitive, and feature-rich software products.

Keep on reading to get a brief but detailed tour of SaaS permissions management, the differences between RBAC, ABAC, and PBAC, and how to implement access control design best practices.

User management challenges in SaaS applications

Not all users are equal. Sometimes, they will want to perform actions that don’t match their user roles and permissions. Depending on the users’ niche, operational maturity, and organizational structure, they might need specific user roles.

This results in the need to initiate and execute granular user access controls. They allow the software to serve its purpose and meet complex enterprise authorization demands while ensuring application security, performance, and data integrity. So, if you want to guarantee product scalability and availability in distributed environments, designing and implementing SaaS user account management tools should be one of the most important concerns.

User access control types: RBAC vs. ABAC vs. PBAC

When it comes to application access management, there are three approaches you can follow:

• RBAC or the Role-Based Access Control model
• ABAC or the Attribute-Based Access Control model
• PBAC or the Permission-Based Access Control model

What is RBAC?

The RBAC model handles user permissions, allowing access to resources and performing actions based on their roles. This is especially convenient for handling multiple accounts with the same access level — like regular Facebook users, group admins and moderators, etc. By updating policies and SaaS permissions for a role, you update them for all user accounts that have this role.

How is role-based access control implemented?

There are cases when the same user needs to have various roles or specific permissions work for many roles. While allowing for flexibility, this can create quite complicated structures. So, there are two basic ways to manage SaaS users with RBAC:

• Granular RBAC implies that certain users within an app instance can create custom roles with unique sets of permissions. This helps meet the needs of every customer by providing granularity in application access control management.
• Role hierarchy implies building a clear hierarchy of roles (e.g., when a Team Lead is above a Developer or a QA engineer and has some permissions they don’t). Lower levels can’t access certain permissions but can be granted permanent or temporary access by a higher role.

RBAC aligns with the principle of “least privileges,” meaning every role has the least number of privileges required to perform its tasks. This helps minimize possible web application vulnerabilities.

What is ABAC?

In the ABAC model, a user role is just one of several attributes:

• User attributes (e.g., organization, user name, role, email, country of registration, etc.)
• Environment attributes (e.g., the user-browser agent or another origin of a request, etc.)
• Resource attributes (e.g., who created the resource in question, when it was created, etc.)

With ABAC, an authorization engine evaluates all attributes before granting users rights to access the necessary resources or perform the requested action. This is useful to ensure that remote workers can access the corporate intranet only when using a VPN — a use case where a standard RBAC wouldn’t have sufficed.

What is PBAC?

With the PBAC model, permissions become separate entities, formed through the abstraction of various actions performed in the application. For example, when a user requests to perform an action, the system checks whether the user actually has such permission or not.

These permissions are called grants and can be assigned directly (to individual users) or indirectly (to user groups). However, all user permissions work only if inherited from a user group. This approach makes permission management much more convenient for heavily populated user groups within large organizations.

B2B SaaS application user roles and permissions handling

You can use several approaches to segregating user roles and permissions in SaaS products: by structure, function, or geography. Here’s what each of them does.

Structure-based segregation

With this approach, every user can assign different access rights and permissions to various roles based on their organizational structure. Imagine several product teams working within the same application instance. One of them might not have a QA engineer, so these functions are performed by the Team Lead. In this case, the permissions should be adjusted accordingly.

Function-based segregation

In the function-based approach, permissions are assigned based strictly on the roles within the organization. For instance, the Designers’ permission sets will differ from the Developers’.

County-based segregation

This self-explanatory approach is a norm in multinational enterprises, where the organization spans a variety of local instances with varying user roles and permissions sets.

Other things to consider while application user roles are cases of over-permissions when certain power roles have superuser rights. They should be persuaded to use less-privileged accounts for daily activities. 

On the opposite side, we have under-permissions. Just like temporary links to Google documents, these access rights can be short-lived and custom in action. You need to find a way to recognize the need for additional rights and grant them upon request. 

Lastly, there is a case of inactive users who clog your user database and increase the potential attack surface. Therefore, your SaaS database design should support automated user deletion after a certain inactivity period, as well as credentials rotation.

User handling on a multi-tenant application

One of the most widespread approaches to SaaS deployment is multi-tenancy when a single application database and infrastructure is used to run multiple instances of customers (tenants). Each tenant must be able to manage their users separately, in a secure and reliable way. Here are several best practices for doing so.

• Protecting data from access outside of the tenant. Every customer must define the scope of its users and roles and explicitly prohibit access to their data to anyone outside the tenant.
• Delegating user management privileges. Different customers will have different user management policies and flows, so it’s important to delegate user access management to admins within every tenant. This helps ensure tenant admins don’t have access to data in other tenants while operating the data in their tenant.
• Restricting the admin rights. Although all users share the same database, accessing data within other tenants should be impossible for any admin. Inside a tenant, an admin can manage permissions, users, user groups, etc.
• Providing simple access to admin features. Access management can be complicated enough, so make admin features easily accessible.

Finally, you should have centralized logging, audit, and control across all tenants while also allowing tenant admins to configure everything within their tenants.

Summary

Building a correct RBAC SaaS model for your application is a vital step in ensuring its stability, scalability, and security. Define the roles and what they should be able to do in advance, but provide the possibility to create custom roles and adjust permission sets to meet unique customer demands. We also recommend following SaaS user management best practices to create flexible yet powerful access control mechanisms.

We know what we’re talking about because Relevant has successfully developed many SaaS products for our clients. You’re welcome to read our case studies on end-to-end software development to see how we structured user access control, and it worked like a charm. If you need help with implementing user management features in your SaaS (or developing a SaaS application, for that matter), contact us now.