One of the first things you’ll need to consider while designing the initial version of your B2B SaaS application is how to regulate the product’s user management and permission handling aspects.
At first, you probably won’t dive too deeply into permissions. Instead, you might try to solve everything using a super-admin role that allows all users to perform any action within the scope of their tenant. For more information on this topic, check out my guide on multi-tenancy.
However, as you start scaling up and things become more complicated, requests for advanced scoping of user permissions will arise. Different customers will require varying degrees of granularity and different permission logics.
Furthermore, you’ll need to achieve this elastic scalability without neglecting the needs of smaller customers, who also contribute significantly to your business today.
Working without the precise business requirements for SaaS user management may lead to decisions that will be far from optimal for your product’s ability to meet your customers’ needs. And since this is a critical topic with prominent security, privacy, and compliance aspects, this might cause some serious business trouble down the road, with an unhealthy dose of financial and regulatory implications.
Since we don’t know what our users want, we will most likely go for the all-or-nothing approach and provide two roles: Admin and Read-only, when the former can do everything possible in the scope of their tenant/account and the latter can only see everything but not perform any state-changing actions. The meaning of this – multiple technical and operational limitations in the long run.
When the need for more granularity will arise, you will probably add some more specific roles according to the requests of your initial customers. These might include roles like Reporter, Commenter, Editor, etc. These roles will allow some additional permissions on top of the Read-only role, or exclude some highly-privileged permissions from the Admin role.
As you start to gain more advanced customers (with complex requirements), you’ll quickly discover that each one tends to manage their organizational scopes differently, based on varying segregation methods. Enterprise-scale operations can go in many different directions on many levels. For example, here are some variations in user management in SaaS applications.
Structure-based segregation — These organizations will operate their roles in your SaaS application according to their organizational structure. Let’s imagine an organization with the structure shown in the diagram below.
This specific company would want to provide each Product sub-organization with scopes of accessing different entities within their SaaS account, while even performing different sets of actions on these entities. For example, the Reporting feature may not be relevant to Product 1 sub-organization members, while the Editor feature may not be relevant to Product 3.
Function-based segregation — These types of organizations will typically be managing scopes based on the specific roles that have been defined within the organization. For example, looking at the previous organization chart, all Engineers will get a certain role and all Designers will get a different role: their permissions will be based on these predefined scopes.
Geography-based segregation — In this case the permissions and mostly visibility scopes will be managed according to the geo-location of the users within the organization/s. The European department will get a certain set of permissions and the US department will get a different set of permissions. This is common where extra focus needs to be placed on compliance and data privacy (GDPR, CCPA, etc.).
By going for a generalized SaaS user management solution, you will most likely aim for the Pareto principle and meet the conditions of 80% of your potential customers. This might work to some extent when targeting SMBs. But if your potential customers are Mid-market or Enterprise, they will need a tailor-made permission management solution or platform at some point.
The academics would claim that you should aim for perfection and go by the Least Privileged Access concept.
This important security and control concept means that we shouldn’t allow a user to do anything more in the system than is required by them in order to perform their jobs. We all understand that almost no SaaS solution will meet this rule these days, unless you are really investing in the logic and development of your Roles and Permissions. More often than not, this is not the case due to a plethora of limitations.
Providing a user with too many permissions for your app may sound like something that is just unnecessary. But from a security and compliance aspect it’s just flat wrong, as it increases the attack surface in the event of an account compromise, putting company and user data at risk. Also, it may open an opportunity to perform unnecessary actions by mistake, just because they are allowed by the system.
Solution: Provide Roles and Permissions granularity as part of your solution to allow customers to create and tailor their roles to any user.
Users require specific capabilities from your system.
But what if they need to perform an additional action? The initial question that this situation brings up is how will the account admin even be aware that an additional permission was requested. If that’s solved, what often happens is that the system is built in a way that in order to allow the additional action you will extensively increase the user’s scope and put them in the “Over Permission” state.
Solution: Provide Roles and Permission granularity with an advanced feature for Permission and access requests. As an example, think of the “Grant Access” request on a Google Drive document — If Google can do it, so can you!
A private case of Over-Permission would be keeping users in the system while they are not actually using it (an user who is not working in the organization or has long completed his work as a freelancer). This could increase the attack surface on the specific account and confuse other users into thinking that a certain user is active and can perform tasks on the account.
Solution: Notify your customers when a certain user is inactive for some amount of time, or automatically deactivate the user until they decide to login and use the system. In the latter case they will need to reactivate their account once again (including email/identity verification).
Granular access control with advanced SaaS user management of roles and permissions isn’t something you would want to provide on your SaaS MVP. It is, however, definitely something your customers will require down the road.
Within the usage-control universe, some features are quite elementary, like allowing basic role assignment for users. Your more advanced customers will require the granularity and ability to control the sets of roles in their account. Finally, you can achieve a high level of control with advanced features that will enable your customers to optimize role assignment on their accounts.
Now, this is true product differentiation and enterprise-readiness.
Start For Free
