How to limit resource creation with RBAC permission?

Question

The project I am working on is a SaaS application with multiple payment tiers. Each one has multiple limits for different actions. One example would be that a free user can only create 1 space, a premium user can create 5 spaces, and a pro user can create unlimited spaces.

I am thinking about a system that has the following permissions:

• create-1-space
• create-5-spaces
• create-unlimited-spaces

In all examples I have seen, a permission is used to just protect the endpoint. In this scenario, however, the endpoint would need to query the number of spaces, meaning that the permission would not be self contained.

What is the recommended practice for controlling this usage?

Answer 1

In my experience, role-based access systems are most useful when they have the following qualities:

1. A repository that maps Roles to Users in a many-to-many relationship, resulting in Role-User records, one record per Role-User combination.

2. A mapping from Roles to approved Activities. This mapping can occur in a repository, but it can also occur in code if the mapping is stable enough.

3. The ability to "bind" allowed Activities to Commands. This allows, for example, the disabling of a button when the capability provided by that button is no longer within the purview of a user's Roles and allowed Activities.

4. The ability to combine Roles and Activities with business rules in various combinations.

In any reasonable software system, a Role often embodies limits. A supervisor can approve overtime but not sign checks. Employees may only be allowed to perform certain Activities at a particular time of day.

Which brings us to the issue at hand: should roles be used to identify payment tiers?

The purist in me says that this isn't a role; it is a feature. Roles in a software system are intended to embody your customers' business rules, not your company's business rules. Roles are typically set by an administrator user; you would have to lock out these specific Roles from that person so they can't change them.

But you may have other constraints such as development costs, and the software doesn't really care; it will function perfectly adequately if you co-opt the Role system to perform this function rather than spending the time and money to build a whole other subsystem just to impose tier limits.