Person Authorization - Role Based Access Control

Modified on Tue, 24 Sep at 10:43 AM

Overview

In Resource Central it is possible to manage Persons based on Azure’s Role Based Access Control (RBAC). When a Resource Central Role is mapped to an Azure app role, the users signing into Resource Central with the Azure role in their AAD access token will be create as a Person thus gaining access to specified sections in RC based on the role’s access control.

The following will describe how to configure RBAC in Resource Central.

Configure Role Based Access Control

The RBAC option can be found in SYSTEM ➔ Authentication ➔ Person Authorization – RBAC:

NOTE: The section is only visible after the following parameter has been enabled RC.Authentication.IsShowRBAC. Before enabling this feature, please read this guide and the knowledgebase article RBAC Azure App Configuration Guide as there are a few things that need to be considered and configured before you are ready to enable this feature fully.

Select [Yes] for Enable Role Based Access Control (Azure) to enable the option.

Doing so will show an additional field below called ‘Number of days a RBAC Person can be inactive before the Person is deleted in Resource Central’. This field determines the number of days that a RBAC person can be inactive (meaning he/she does not log in RC backend). If the number of inactive days exceeds the specified amount, the person will be deleted from RC.

When you are done, click [Save] on the toolbar to start activating the option. It will ask for verification to make sure that the SSO login is working correctly:

Click [Yes] to proceed testing the SSO by logging in the Azure user account that has an access token claim containing the App role matching ‘SysAdmin’ role in RC.

If the SSO is unsuccessful, the activation of RBAC will be aborted and the ‘Enable Role Based Access Control {Azure)’ will be reverted back to [No].
If the SSO is successful, RBAC option will finally be enabled. A message will also be shown notifying the successful configuration:

With this, the configuration is now completed.

How Role Based Access Control works

Creating Persons in RC for AAD users

NOTE: For this process to work, the AAD users need to be given App roles that match the Roles available in RC backend. For more details on assigning App roles to AAD users, refer to the guide RBAC Azure App Configuration Guide.

When AAD users log in RC backend with SSO for the first time, RC will automatically create Persons for them and assign them the Roles in RC based on their mapped App roles in AAD. If there are unknown App roles in AAD, the RC system will ignore them.

The created Persons will also be automatically assigned Locations and Access Control Levels configured in RC Role details corresponding to the Roles of the logged in Person (found in RC backend ➔ SECURITY ➔ Roles. Refer to RC Administrator Guide for more details). E.g.:

You can edit Locations and Access Control of a Role. And the changes will be applied to AAD users who have the respective App role when they log into Resource Central based on their given RC Roles.

When configuring your Azure App Roles, it is important to consider your current set of Roles and Persons and which locations the different Persons need to have access to. If there are e.g., catering roles on different locations where the different catering Persons today cannot see each other’s orders, then it is important to create the app roles with the locations in mind as the location is defined on the RC Role and not the Person.

In case the AAD users do not have any App role that matches RC Roles, they will NOT be able to log in RC backend. Also, the following error message will be shown on RC login page:

In case the AAD users do have App role that matches RC Role, yet the RC Role is not assigned with any location (which can be done in RC backend ➔ Security ➔ Roles ➔ Role Details); they will NOT be able to log in RC backend. Also, the following error message will be shown on RC login page:

In both of these cases, the AAD users need to have matching Roles that does exist in RC and they are already assigned to a location in order to log in with SSO and have their Persons created in RC.

Checking AAD users when logging in RC with SSO

In case of AAD users who already have their Persons created in RC, their App roles will still be checked to see if they still match with RC Roles.

Scenario 1: The App roles and RC roles are unchanged.

In this case, the AAD users can log in RC normally using SSO with the same RC Roles as before.

Scenario 2: There is no App role, or all the available App roles do NOT match with RC.

In this case, the AAD users will not be able to log in RC, and they will receive the following error message on the RC login page:

Scenario 3: The AAD users still have App roles matching with RC, yet their respective RC Roles are not assigned to any location.

In this case, the AAD users will not be able to log in RC, and they will receive the following error message on the RC login page:

Additional changes to RC when RBAC enabled

When RBAC feature is enabled, certain changes to RC are applied:

In SECURITY ➔ Persons, the following changes are applied:

[New] button is disabled, meaning Persons cannot be created manually from RC backend.
In Person Details, [Set Password] and [Save Configuration] buttons are disabled.

Also, the following fields can no longer be edited: Login name, Display name, SMTP address, and Locations due to these fields’ values are taken from their AAD access token claims and their roles.

For example: