RBAC vs ABAC: Role vs Attribute Based Access Control

OrgVue allows clients to set up their own permissioning, and also to request more complex access rules to be built by the OrgVue development team and implemented on behalf of the client by qualified OrgVue consultants.

What is the difference between RBAC and ABAC?

These two levels of access control are defined as follows:

Role-Based Access Control (RBAC) – where an OrgVue client is able to set up their own permissioning to enable access to datasets and properties

Attribute-Based Access Control (ABAC) – where user access to nodes is based upon attributes of the node itself. The rules are written by the OrgVue development team in co-operation with the combined OrgVue Implementation and client design teams.

As far as is possible, security should be configured using RBAC, as this is easier to configure and maintain and can be done so by Tenant Admins, whereas a change in ABAC requires developer time in creating a new XML script.

In the standard configuration (RBAC), there are two basic roles in OrgVue:

• 'Admin' role: has full access to all datasets and all columns (properties) within each dataset. This includes access to the “Users” dataset, through which admins can manage user accounts and user roles within the tenant.
• 'User' role: has the minimum level of access to OrgVue. By default, users only have access to datasets which they themselves have created, thereby granting them the same permission levels as an admin. They also have access to datasets which they have been permitted to see through OrgVue’s data sharing RBAC mechanism.

An OrgVue user must have at least one of the above two roles to be able to access the OrgVue workspace.

ABAC Security Rules

• ABAC rules are written in XML (eXtensible Mark-up Language), which allows very flexible rules to be written.
• Configuration files containing these rules can either be saved on a dataset-by-dataset basis, or applied via the server to an entire tenant.
• In label-based ABAC, the developer will either reference properties in the dataset itself, or create a dedicated security property in the Users dataset to store each user’s label (similar to ‘role’ except only one label per user is typically allowed).

Recommended Best Practice for Clients considering ABAC

Here are some points to consider in order to assure that the chosen security settings function in a way that OrgVue users can understand and work with:

  • If requesting a new rule e.g. ‘HR users should only be allowed to see…’ the 'HR Users' group needs to be specifically defined (is it by a role tag ‘hr’ or by a separate property in the users data?)
  • When rolling out access across your business, we would advise starting with the core team, before extending to the wider team and key managers in the business.
  • During the testing (UAT) stage, please report any problems as soon as possible, especially if your ABAC is not not giving users the information they are meant to see.
  • Set up an Excel spreadsheet detailing UAT results and share with the Implementation Team to make sure that your ABAC requirements are being met prior to implementation.
Have more questions? Submit a request

Comments