Access Control in SaaS applications with EBAC (Entity based access control) approach

Due to the complexity of the ABAC model, and the “oversimplification” of the RBAC model there is a need to build hierarchies between RBAC and ABAC models. This approach is called EBAC (Entity Based Access Control)

EBAC is a simple subset of ABAC and doesn’t bring to the table any new concepts rather than a simplified model of ABAC.

Under the EBAC model, we will first use the RBAC engine in order to quickly determine the user’s first access layer and then we will operate the ABAC model in order to evaluate the requested entity.

Dynamic Roles

• The role is just a set of permissions.

The Role itself doesn’t represent anything in the system, it is just a predefined set of permissions. Once the Solution is shipped to the client and deployed to a new environment. Super Admin is created. This is the one role that has all of the permissions in the distributed system. From here on out the this is the highest body of user management in the system.

As this is an EBAC system, the role would look like a list of permissions based on the actions that can be performed on a particular entity where special attention is on is it singular or plural.

For Example:
[‘roles:create’, ‘roles:read’, ‘roles:update’, ‘roles:delete’, ‘users:read’, ‘users:update’…]
This user has permissions to add/change/delete all roles and users

[‘user:read’, ‘user:update’, ‘organizations:read’, ‘organization:update’]
This user has permissions to read/update only his own user, he can read all organizations but update only the one that he is a part of.

Role Setup (can be predefined by system or created by Super Admin)

Initial roles can be predefined by the system itself and after that modified by Admin or it can be blank and created by the admin from scratch.

For example, the system can provide roles such as Admin, Organization Manager, Global Manager, User

Organization Manager has all permissions within the organization where he belongs, but cannot see other organizations.
Global Manager has the same set of permissions but within all organizations in the system. The User has access to the organization where he belongs but it can only see entities that are his.

Roles Management

Roles Management is achieved through a simple UI in the Admin frontend application.

New User Flow

When a new user is added to the organization he gets a base set of permissions (ex: User), and he is added to the default organization (Global), now it is on Admins to actualy assign the correct organization to a user, and modify his permissions and/or change his role

Conclusion

The huge upside of this system is that is not affected by the growth of the system overall, and it can be customized to the single action in the system. The downside is that the initial setup is a bit slow with role creation but this can be avoided with predefined roles by the system itself.