Roles and Permissions Handling in SaaS Applications

Identity

One of the first things you’ll need to decide when 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 but rather try to solve everything by a super-admin role which allows every user to do everything possible within the scope of their tenant (look for my blog on multi-tenancy for more info on this topic). But as things move further along (and get more complicated), requests for more advanced scoping of users’ permissions will arise. Different customers will require different degrees of granularity and different permission logics. 

Working without the precise business requirements for this topic might lead to decisions which 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.

How you manage Roles in SaaS applications

Phase 1 — All or Nothing

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.

Phase 2 — Business Specific Intermediates

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.

Phase 3 — When Reality Strikes

As you start to gain more advanced customers you’ll quickly discover that each one tends to manage their organizational scopes differently, based on varying segregation methods:

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 following structure:

This company would want to provide each Product sub-organization with scopes of accessing different entities within their SaaS account, and even perform 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 organizations will manage scopes based on the specific roles 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 geography of the users within the organizations. The European department will get a certain set of permissions and the US department will get a different set of permissions.

Aim forLeast Privileged Access

By going for a generalized solution, you will most likely aim for the Pareto principle and meet the conditions of 80% of our potential customers. This might work to some extent when targeting SMBs. But if your potential customers are Mid-market or Enterprise, they will need tailor-made permission management 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 really investing in the logic and development of their Roles and Permissions.

Of course, providing a perfect solution which will apply this rule to each and one of your customers and their end-users, will be a difficult task to achieve, so let’s see what are the type of compromises in this space and possible solutions for each and one of them.

Over Permissions

Providing a user with too many permissions for your app may sound like something that is just unnecessary. But from a security aspect it’s just flat wrong, as it increases the attack surface in an event of an account compromise. 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.

Under Permissions

Users require a certain amount of 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!

Inactive Users

A private case of Over-Permission would be keeping users in the system while they are not actually using it. 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 inactivate 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).

Providing Enterprise-grade granularity and usage control

Granular access control with advanced 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!

Subscribe
Notify of
guest
Conversations(0)
Inline Feedbacks
View all comments