Create and configure Privileges to set data access permissions for Workbench users

Overview

In your Thentia Cloud environment, you can create Privileges to define data access permissions and apply them to the authorized users of your Workbench. Each individual Privilege is a self-contained permission set that defines:

  • The entity in your Thentia Cloud environment that the access permissions apply to
  • The group of Workbench users (Privilege Group) that the access permissions apply to
  • The data access permissions themselves, specified separately as:
    • Read Access: Whether the permission grants access to view data
    • Write Access: Whether the permission grants access to create or edit data
    • Delete Access: Whether the permission grants access to delete data

For each data access permission, you can also optionally specify a more granular access level, which allows you to scope the permission to either the entity level (the permission grants access to all records in the entity) or the record level (the permission grants access to only specific records in the entity).

 Note

To learn more about how data access permissions work in Thentia Cloud, see Get started with Privileges & Privilege Groups.

 

To learn more about creating Privilege Groups, see Create and manage Privilege Groups to apply Privileges to Workbench users.

In this article, you’ll learn:

  • How to create and configure Privileges to set and enforce data access permissions for users of your Thentia Cloud Workbench
  • How to configure a Privilege to restrict access at the record level (and how to set up your Thentia Cloud environment to enable this functionality)
  • How Thentia Cloud resolves conflicts between Privileges

Before you begin

  • To follow the instructions in this article, you must have access to:
    • The Workbench for the Thentia environment in which you want to work.
    • The Security module within that environment.
    • The Workflow module within that environment (if you want to complete the optional setup steps).
  • Before you can configure Privileges, you must first have created at least one Privilege Group. For instructions, see Create and manage Privilege Groups to apply Privileges to Workbench users.

Optional: Enable record-level access permissions

If you would like to be able to control access to the data in your Thentia Cloud environment at the record level (i.e. allow users to read, write, or delete only specific records in an entity, rather than all records), you must first enable this functionality by adding a new key in the System Settings of your environment.

If you do not want to use record-level access permissions, you can skip this step.

 Note

Enabling record-level access permissions is optional. If you do not enable this feature, you will only be able to configure access permissions at the entity level, i.e. you can only configure Privileges to apply read, write, or delete access permissions to all records in an entity.

To enable record-level access permissions in your environment, follow these steps:

  1. Log in to Workbench and go to any module.
  2. Click on the Profile menu (your initials) in the menu bar, then click on System Settings:
    syssettings.png

  3. In the System Settings menu, click on Configuration:
    sysconfig.png

  4. In the menu bar, click on the  Create a new connected record button to create a new settings key, which will open in a new tab.

  5. Under Configuration Option Details, configure the settings with the following values:

    • Key: Enter record.level.permission into the field.
    • Value: Enter true into the field.
      newkey.png

  6. Click on  Save this record in the menu bar to finish creating the key.

  7. Close the tab and return to the System Settings > Configuration menu, where you should see the new key you just created listed in the table:
    keytable.png

  8. The change will take effect immediately, and you will see Access Level settings within the Access Settings section when configuring a Privilege.

Create and configure a Privilege

By default, all authorized users of a Thentia Cloud environment have full Read Access, Write Access, and Delete Access to all entities. Privileges are subtractive, which means they are generally used to remove or limit access to data.

Each individual Privilege defines both access permissions for a specified entity, and links those permissions to a particular Privilege Group. As a result, we recommend creating a set of Privileges for each Privilege Group, consisting of one Privilege for each entity that contains sensitive data.

 Note

If needed, you can create multiple Privileges for the same entity-plus-Privilege Group combination. This can be useful if you want to create record-level access permissions with multiple conditions. However, be careful to avoid Privilege conflicts.

 Important

Privileges do not apply to Workbench users who are set as Administrators (users whose System User record has the attribute Is Administrative? set to Yes), even if those users are members of Privilege Groups. If an Administrator user is added to a Privilege Group, they will still have full Read Access, Write Access, and Delete Access permissions to all entities, and the system will ignore all Privileges associated with any Privilege Group the user belongs to.

To create and configure a new Privilege, follow these steps:

  1. Log in to Workbench and open the Security module ( Modules button > Security).
    Security.png
  2. Click on the  Menu button to open the navigation menu.

  3. In the navigation menu, find the RBAC section, then click on Privilege Groups to open the All Privileges Record List in a new tab:
    privileges.png

     Note

    You can also access this Record List from the Workflow module by opening the Privileges entity (tc_privilege) and clicking on Open Records.

  4. Click on the  Create a new record button in the menu bar to open the New Privilege page in a new tab.

     Tip

    Instead of creating a new Privilege, you can also modify any existing Privilege by double-clicking its record.

  5. Configure the settings under This Record > Privilege Details to start setting up your new Privilege:

    • Group: Use the dropdown menu to select the Privilege Group to which this Privilege will be applied (linked).
    • Entity: Use the dropdown menu to select the entity for which this Privilege will set data access permissions.
  6. Under This Record > Access Settings, configure the data access permissions that this Privilege will apply.
  7. When you have finished configuring the new Privilege Group’s details, click on the  Save this record button in the menu bar.

  8. The new Privilege Group will be created, and will be displayed in the All Privileges Record List. The access permissions defined in the Privilege will take effect immediately for Workbench users belonging to the specified Privilege Group.

Reference: Privilege Access Settings configuration

While creating (or modifying) a Privilege, use the settings under the Access Settings section to configure the data access permissions that the Privilege enforces.

Within each Privilege, you can separately configure three permission types which control read (view), write (create/modify) and delete access on the data (records) within a given entity.

You can configure each of these permission types at two levels:

  • Entity-level: The user has access (or no access) of the specified type to all records in the entity.
    • Example: The user can view all records in the Profile entity.
  • Record-level: The user has access of the specified type to only records that meet specified criteria in the entity.
    • Example: The user can only delete records in the Profile entity that they own, and cannot delete records that other users own.

Access permissions at the entity level

Under the Access Settings section of a Privilege, the following settings control data access at the entity level:

  • Read Access?: Controls the ability to view records belonging to the entity.
    • If set to Yes: Users with this Privilege will be able to view any existing record in the entity (unless further restricted at the record level).
    • If set to No: Users with this Privilege will not be able to view any records in the entity.
  • Write Access?: Controls the ability to create or modify records belonging to the entity.
    • If set to Yes: Users will be able to create new records in the entity, and will be able to modify any existing record in the entity (unless further restricted at the record level).
    • If set to No: Users will not be be able to create new records in the entity or modify any existing records.
  • Delete Access?: Controls the ability to delete records belonging to the entity.
    • If set to Yes: Users will be able to delete any existing record from the entity (unless further restricted at the record level).
    • If set to No: Users will not be able to delete any records from the entity.

Access permissions at the record level

 Note

The settings described in this section are only available if you have enabled record-level permissions in your environment. For instructions, see the section Optional: Enable record-level access permissions.

If you set any of entity-level access permission settings (Read Access?, Write Access? or Delete Access?) to Yes, the default behavior is for the permission to grant access to all records in the entity. If needed, you can further limit access of each type at the record level, so that users only have access to specific records in the entity.

Record-level access permissions work by specifying a condition (or requirement) that a record must meet (fulfill): if the record meets the condition, the access type is granted; if it does not, the access type is not granted.

For example, say you set up a Privilege on the Licenses entity, and set the condition that the attribute License Type must be equal to the value Class A on on the Read Access permission. A user with this Privilege would be able to view records where License Type is set to Class A (condition met) but would not be able to view records where License Type is set to Class B.

To set access permissions at the record level, use the access level settings. There are three settings, one for each access type:

  • Read Access Level: Sets the condition that a record must satisfy for the Read Access? permission to allow the user to view the record.
  • Write Access Level: Sets the condition that a record must satisfy for the Write Access? permission to allow the user to edit the record.

     Important

    The Write Access Level setting does not apply to the ability to create records. A user who has a Privilege with Read Access? set to Yes will be able to create new records in the specified entity, regardless of any condition set with the Write Access Level setting.

  • Delete Access Level: Sets the condition that a record must satisfy for the Delete Access? permission to allow the user to delete the record.

Each access level setting has five options, ranked in order from largest scope/least restrictive to smallest scope/most restrictive (click an option to expand it and view more details):

1. All Records

Grants the user the access type for all records in the entity.

This is the default option, i.e. if nothing is selected under the Access Level setting, the system will behave as if this option is selected.

2. Criteria Based

Grants the user the access type only for records where a specified attribute has a specified value.

Selecting this option will display further settings:

  • Lookup Field: Use this dropdown to select the attribute to use as the basis for the condition.
  • Value Equal To: Use this dropdown to select the value of the attribute you want a record to match for the access type to be granted.
3. Group Owner and Subordinates

Grants the user the access type only for records where the Group Owner of the record is set as either (1) the Privilege Group the user belongs to, or (2) a Privilege Group that is at any level below the user’s Privilege Group in the hierarchy.

Example:

  • Manager Group is set as the Group Owner of Example Record A.
  • Staff Group is set as the Group Owner of Example Record B.
  • IT Group is set as the Group Owner of Example Record C.
  • In the hierarchy, Manager Group is a parent of Staff Group. Manager Group does not have a hierarchical relationship with IT Group (is neither a parent nor a child).
  • As a result, Manager Group can access Example Record A (owned by itself) and Example Record B (owned by a subordinate), but cannot access Example Record C (neither owned by itself nor by a subordinate).

This option is intended to be used in conjunction with a Privilege Group hierarchy. For details, see the section Set up a Privilege Group Hierarchy in the article Create and manage Privilege Groups to apply Privileges to Workbench users.

To use this option with an entity, you must also configure that entity to use the Group Owner attribute. For details, see Optional: Configure an entity with a Group Owner attribute.

4. Group Owner

Grants the user the access type only for records where the Group Owner of the record is set as the Privilege Group the user belongs to.

Example:

  • Staff Group is set as the Group Owner of Example Record.
  • As a result, members of Staff Group can access Example Record, but members of other Privilege Groups cannot.

To use this option with an entity, you must also configure that entity to use the Group Owner attribute. For details, see Optional: Configure an entity with a Group Owner attribute.

5. Owner

Grants the user the access type only for records where the Owner of the record is the user themselves.

Example:

  • William L. is set as the Owner of Example Record.
  • As a result, William L. can access Example Record, but Tony S. cannot.

 Note

The Group Owner and Subordinates and Group Owner options only reference the Group Owner field on records, and do not consider the Owner field. This means that these access level options do not give a Privilege Group access to records where the Owner is a member of the Privilege Group — to grant access, the Group Owner field must be specifically set to the name of the Privilege Group.

Optional: Configure an entity with a Group Owner attribute

The attribute Group Owner is not a default attribute on any Thentia Cloud entity, so you must first configure it on any entity where you want to use the Group Owner and Subordinates or Group Owner access level options.

Additionally, these access level options will not grant access to any record where the Group Owner attribute is empty (has no value). As a result, you must also ensure the Group Owner attribute is set to the appropriate values on all records within the entity.

If you do not want to use the Group Owner and Subordinates or Group Owner access level options, you can skip this step.

 Note

Adding the Group Owner attribute to an entity is optional. If you do not add this attribute to an entity, you will not be able to use the Group Owner and Subordinates or Group Owner access level options with that entity.

To configure an entity to use the Group Owner attribute, follow these steps:

  1. Log in to Workbench and open the Workflow module ( Modules button > Workflow).
    Workflow.png
  2. In the All Entity Metadata Record List, find the entity where you want to add the Group Owner attribute. Double-click on the entity to view its metadata page.
  3. The entity’s metadata page will open in a new tab. Click on Attributes in the menu bar:
    Workflow 1.png

  4. In the table under the Attributes section, double-click on Main Form to open it in a new tab.

    • If you have multiple forms listed in the table, open the currently active form, i.e. the one where Is Default? is set to Yes.

  5. Under Design Elements, click-and-hold on Lookup, then drag-and-drop it anywhere under the Main Form section:
    lookupdrag.png
  6. The New Form Item dialog will open. Configure the following fields with the values specified:
    • Attribute Name: Enter tc_groupownerid into this field.
    • Display Label: Enter Group Owner into this field.
    • Connected Space: Use the dropdown to select Privilege Group (tc_group)
    • You can leave all other fields and settings (Enable Link, Filter Query, etc.) empty, or configure them as you prefer.
  7. Click on Save:
    savelookup.png

  8. The dialog will close, and you should see the new lookup field in the form.
    newfield.png

    • If the field appears in the Administrative Details section, click-and-drag it to any other section in the form to ensure it is displayed when a record is created or edited.
  9. Click on the  Save button in the menu bar to save your changes.

  10. The Group Owner field should now appear on all records in the entity. To check, click on Open Records in the menu bar to view the entity’s records, then double-click on any record to open its Record View. Under This Record, scroll to the section of the form where you added the lookup, and you should see the Group Owner field is visible and can be set:
    groupowner.png

 Important

After adding the Group Owner field to an entity, remember to set it to the appropriate value on all records in the entity to ensure that your Privileges using the Group Owner and Subordinates or Group Owner access level options are applied properly.

Reference: Privilege conflicts

If you create multiple Privileges for the same entity-Privilege Group combination, or when a System User is a member of two or more Privilege Groups, this can cause multiple separate Privileges on a given entity to be applied to a user at the same time. In this situation, conflicts may occur between the access permissions configured in each Privilege.

Should a conflict occur, the system will automatically resolve it according to the rules outlined in this section. However, as this may have unintended effects that can be complex to troubleshoot, we strongly recommend that you anticipate possible conflicts when designing your Privileges, and avoid them wherever possible.

Scenarios

There are three main scenarios in which a conflict can arise:

  • Scenario 1: If the same access permission is set to Yes in one Privilege, but to No in another.
    • Example: One Privilege sets Read Access: Yes for an entity, while another sets Read Access: No for the same entity.
  • Scenario 2: If two or more access permissions are set to Yes, but are configured with different access levels.
    • Example: One Privilege sets the Write Access Level to All Records, while another sets it to Owner.
  • Scenario 3: If two or more access permissions are set to Yes and use the Criteria Based access level option, but set different conditions.
    • Example: One Privilege for the License Applications entity sets the Read Access Level condition Application Status = Approved, while another for the same entity sets the Read Access Level condition Application Status = Rejected.

Resolution

When a conflict occurs, the system will resolve it as follows:

  • Scenario 1: The system will apply the more restrictive access permission. Specifically, if any of the conflicting access permissions is set to No, the system will apply that permission (even if all of the other conflicting access permissions are set to Yes).
  • Scenario 2: The system will apply the access level with the smallest scope. For this purpose, the ranking of access levels by scope, from largest scope (1) to smallest scope (5), is:
    • (1) All Records
    • (2) Criteria Based
    • (3) Group Owner and Subordinates
    • (4) Group Owner
    • (5) Owner
  • Scenario 3: The system will apply all of the applicable conditions, using a logical OR operator between them.
    • Example: A user has two Privileges for the License Application entity. One Privilege has the Read Access Level condition Application Status = Approved, and the other Privilege has the Read Access Level condition Application Status = Rejected. As a result, this user will be able to view records that meet at least one of the two conditions, i.e. any records where the Applicaton Status is either Approved OR Rejected.
Was this article helpful?
0 out of 0 found this helpful
  • Submit a request

    Still have questions? Submit a request and our support team will be happy to help!

Comments

0 comments

Please sign in to leave a comment.