ABAC (Attribute Based Access Control)

Prev Next

Introduction

You want to make sure all your OTYS users have acces to the correct modules and functionalities. You want to show the ones they need, and to hide the ones they should not be able to use. The easiest way to do this, is by setting up ‘Atribute Based Acces Control’, or ‘ABAC’ in short. ABAC makes it easy to setup new users instantly with the correct permissions and to change configurations for groups of existing users.

Configuring ABAC, especially the first setup, takes some time and attention. The strength of ABAC is at the same time the ‘risk’ - make some mistakes and all your users are missing a key functionality. We advise to work together with a consultant to setup the first configuration. If you want to make changes later on, this can be done by a key user or via a Support Ticket.

General

User rights within OTYS Go! can be managed with 'User Based Access Control', where you enable and disable settings per individual user. When you have just a couple of users, this probably works fine. For our customers with more users, a more complex structure, and customers who just want the easiest way to make sure each new user get’s the correct permissions without lots of clicking, we created ‘ABAC’.

Why ABAC and not ‘Role Based Acces Control’, RBAC?

In a RBAC system you define different roles, like ‘Recruiter’ and ‘Accountmanager’. Permissions are then assigned to these roles; maybe the ‘Accountmanager’ needs the Sales module and the Recruiter does not. This would cover a lot of use cases for our customers, but with ABAC we offer even more flexibility. With ABAC you can define different types of ‘attributes’. These can be roles (Recruiter, Accountmanager) but also for example locations like Houten and Veenendaal. Now you can connect permissions to roles and also to the locations. This makes it possible for example to make sure Accountmanagers (and not Recruiters) have the Sales module, and all users for location ‘Houten’ can use a specific Dashboard - no matter if they are an Accountmanager or a Recruiter.

Since we wanted to do things proper, we have not only implemented permissions (user settings) in OTYS ABAC but have made it possible to make the (highly customizable) OTYS experience more 'manageable'. Using our ABAC system you are able to define the following elements based upon a users attributes:

  • User DB settings (so user settings starting with 'DB' in user settings)

  • User Mongo settings (so user settings starting with 'SE' in user settings)

  • Dashboards sets (what dashboards should the user see when they log in to the OTYS system)

  • Default filters (what filter should by default be opened if a user opens a module)

  • List views (which columns should a user see when opening a specific module)

  • Detail views (what should a user see when opening a specific record).

Next to settings that activate modules and functionalities, we also support options that give users more or less freedom to make their own changes. You can for example choose to give a user -based upon their attributes- one list view without the option to change it, give the user multiple list views and allow them to switch between views or even give the user the possibility to create their own list views.

Dependencies

  • Organization units

    To use ABAC, you also need ‘Organization units’. This functionality, that is used to configure and assign the attributes, can also be used for other situations where you want to group users. It is possible that these are already configured and used, while ABAC is not yet activated.

  • Key user rights
    To see the ABAC module and to be able to make changes here, you need Key user rights, since these are advanced settings. A lot of customers only have a Super User; this is often a better fit for companies that do not have a IT minded Application Manager who can spend a lot of time to really get to know the advances settings. Customers who do not have a full Key User can work with our Support- and Consultancy team to setup advances configurations like ABAC.

Activation

The ABAC functionality needs to be activated by OTYS. We advice to also work together with a consultant to setup the first configuration.

Configuration

  1. Configure the attributes
    Use client setting ‘Basic Client Settings - Organization Settings’ GE37) to configure the attributes. There are 5 Units available. If not configured yet, they will show as ‘Unit name 1’, ‘Unit name 2’ to ‘Unit name 5’. Use a unit per type of attribute. For example rename ‘Unit name 1’ to ‘Role’ and add items for ‘Recruiter’, ‘Accountmanager’ etc. Rename ‘Unit name 2’ to ‘Office location’ and add items for ‘Houten’, ‘Veenendaal’ etc. Use more or less units, and create more or less values, dependent on the structure you want to create.

  2. Configure ABAC rules
    When you open client setting ‘ABAC - ABAC configuration’ (GE300) it will look similar to a modal. It shows a list view of ABAC rules, with filter options in the panels and a ‘create new’ button at the top.
    Via the button ‘New ABAC setting’ at the top, you have two options:

    1. Empty ABAC setting. With this option you can add new rules one by one
      Select for which attribute you want to add a rule. Example: at ‘Role’ select ‘Accountmanager’
      At ‘Setting type’ select the correct type of setting. Example: ‘Sales - Enable for client/user’ and ‘Setting value’ select ‘Enabled’. Save your rule.
      For info on ‘Force disabled’ and ‘Rank’ see tips below.

    2. Import ABAC settings. With this option you can select an existing user, and copy all their user settings to ABAC rules. This is a quick way to get started, but will also copy a lot of settings that are not really relevant. You will probably have a more clean result when you add the rules one by one.
      At ‘User’ select which user you want to copy from.
      At ‘Setting type’ select which type of settings you want to copy from this user. This is a multi-select.
      Select for which attribute you want to copy the settings. Example: at ‘Role’ select ‘Recruiter’. Click ‘Import’ to continue.

  3. Assign attributes to users
    In user setting ‘Basic User Settings - Organization Settings’ (GE196) you can connect attributes to the user. Per Organization Unit you select all items that apply to the user. If configured correctly, ABAC is able to ‘stack’ rules, and even work with conflicting rules. See Tips&Tricks.

Combining roles

When two rules about a setting apply to the same user
When using ABAC, you can assign multiple attributes to a user. Rules will be combined; so if a user has both the role ‘Recruiter’ and the role ‘Accountmanager’, they will have the combined permissions of those roles. When rules for different attributes contradict each other (for one attribute a setting is disabled, for the other it is enabled) the system will assume that the intention is to enable the setting.
Example: the user is both Recruiter and Accountmanager. For the Recruiter role, the Sales module is disabled. For the Accountmanager role, the Sales module is enabled. Since the user has both roles, including Accountmanager where it should be enabled, the system will enable the Sales module for this user.

For setting types that are not enabled vs disabled, but allow multiple options, the combined options will be available for the user. This will apply for the Dashboard sets, list- and detail views. When ‘Location Houten’ has a specific dashboard set, and ‘Location Veenendaal’ has another dashboard set, a user who is assigned both Houten and Veenendaal will have both dashboard sets.

How to use ‘Force disabled’
For most settings ‘enabled’ will give you more options then ‘disabled’. When you set 'Sales - Enable for client/user’ to ‘enabled’, the user will see the module. With disabled, they have no acces. There are some settings, where ‘disabled’ will give the user more options. For example ‘Candidate Manager - Hide delete button candidates’. When enabled, the user will not be able to use the delete button. When you create rules for this type of settings, where ‘disabled’ gives more options, and the rule is about ‘disable’, combine with the ‘Force disabled’ checkbox. This is especially important when there are conflicting rules.

Example: For ‘Accountmanager’ we want to hide the delete button. Recruiters should have it.

The rules will be:

  • Role: Accountmanager. Setting type: User setting (SE). User setting (SE): Sales - Enable for client/user. Setting value: Enabled. Force disabled: NOT activated

  • Role: Recruiter. Setting type: User setting (SE). User setting (SE): Sales - Enable for client/user. Setting value: Disabled. Force disabled: Activated

This will hide the button for a user who only has role Accountmanager.
It will show the button for a user who has only ‘Recruiter’.
It will also show the button for a user who has both roles. Normally ‘enabled’ ‘wins’ from 'disabled’ if both rules apply for a user. With ‘Force disabled’, this rule will win

Usage

New users

When creating a new user with ABAC active, you will select their attributes. This will automatically assign all that is configured with ABAC rules for these attributes to this new user.

Changes for existing users

When the attributes of a user change, for example when the get a new position or will work from a new location, a Key User kan change their attributes via user setting ‘Basic User Settings - Organization Settings’ (GE196). Please note: a script will run every night to re-assign all settings, dashboard sets etc, so changes will only be visible for the user the next day.

ABAC and Azure

For customers who are using Azure we offer an integration so that OTYS Go! users can automatically be created, linked and/or blocked based upon their Azure group(s) and OTYS Go! users linked to an Azure user can automatically login based upon their Microsoft (Azure) account in OTYS Go!. We have therefore created an alternative Azure ABAC integration which allows you to connect organization units to specific Azure groups. When you create a new user in Azure and connect the user to groups the user will automatically be created in OTYS by the Azure script, with the assigned organization units that will give them the correct permissions.

Azure groups can be connected to Organization units via client setting 'ABAC - Azure groups' (GE305).

  • At 'Group name' fill in the group name. Although this does not do anything from a technical perspective, it is wise to use the exact same name as the group name in Azure (so it is easier to pinpoint a group).

  • At 'Group id' fill in the Azure group ID. For this one it is of course important to have the EXACT ID of the Azure group.

  • Select the organization unit(s) that apply for this Azure group.

Please note that if you have already configured an Azure group in the non-ABAC way (through client setting SE3231) AND an Azure user IS already connected to this group AND this group is NOT configured in the new ABAC way (through client setting GE305); the new Azure ABAC process will not be applied. You can 'solve' this in two ways:

  • Remove the user from this old group. Make sure that the user IS linked to a group that is configured in the new ABAC way (through client setting GE305) or else his account will be blocked.

  • Add the Azure group ID in the new Azure way (through client setting GE305)

Testing

When setting up ABAC, it can help to first only assign attributes to one user and check if the results are as you expected.

Troubleshooting

When you do not see the results you expect, check if there are conflicting rules. If you know the setting, search by key word in the right panel. You can also search by keyword on terms like name of a module, since most settings will start with that.

Other helpful options are found via ‘add criterium’, also in the right panel. Here you will find filters for ‘organization unit’, to help for example see all the rules for ‘Role: Accountmanager’. You can also search by settings type, for example to check all rules about Dashboard sets.

Check out if any rules are missing, or if rules contradict each other. If they contradict, see tips under ‘Combining roles’ above.