Secure the data hub

This document explains the security model of Semarchy xDM used to protect data stored in a data hub.

Introduction to security in Semarchy xDM

There are two levels of security in Semarchy xDM:

  • Platform-Level Security defines access to features in the platform. This type of security is configured at platform-level.

  • Model-Level Security defines security privileges to access and modify data in the data location into which the model is deployed.

Both levels of security are role-based:

  • Privileges are granted to Roles defined in Semarchy xDM.

  • Roles are given to Users in Semarchy xDM or in a third-party identity provider.
    Semarchy xDM may store users and roles associations, or entirely delegate user and role assignement to a third-party identity provider.

Understanding model security

Model privilege grants

Model Privileges Grants define the access privileges for users via their roles.
A Model Privilege Grant is associated to a role and contains a set of Entity Privileges granted to this role. You can only define a single Privilege Grant for each role in a model.

Entity privileges

An Entity Privilege defines the privilege of a role for an entity (or a subset of the entity records) and its attributes.

Entity and attribute-level privileges

An Entity Privileges includes privileges defined at:

  • Entity-level: Such a privilege is the default privilege for all the attributes of the entity.

  • Attribute-level: Such a privilege overrides the default entity-level privilege, allowing specific privileges per attribute.

Examples:

  • Entity-Level Privileges: Users with the Finance role can edit (read/write) cost centers; other users can only see them (read). Users with the Contractor role cannot see (none) this entity.

  • Attribute-Level Privileges: All users can see (read) general information from the employee entity, but they cannot see (none) sensitive information (Personal Email, SSID, Salary, etc. attributes). Only users with the HR role can see these attributes.

Privilege types

The types of privilege are listed in the table below:

Privilege type Entity-level Attribute-level Description

None

Yes

Yes

No privilege is granted to the user for the entity or attribute.

Read

Yes

Yes

Allows the user to view the entity or attribute.

Read/Write

Yes

Yes

Allows the user to view the entity or attribute. In addition, the user can edit the values in data authoring. Note that this privilege only allows modifying data. To create new records in a stepper, the Creation privilege is needed.

Allow Export

Yes

N/A

Allows the user to mass-export records from this entity in Excel format. Note that exported columns are filtered using the privileges granted on attributes. If a user can Export an entity, but does not have read or read/write privileges on certain attributes, these attributes will not appear in the export.

Allow Creation

Yes

N/A

Allows the user to create new records for this entity in steppers.

Allow Checkout

Yes

N/A

Allows the user to edit records for this entity in steppers. This privilege is required to delete records.

Allow Removal

Yes

N/A

Allows the user to remove records for this entity in steppers.

Allow Delete

Yes

N/A

Allows the user to delete records for this entity. The Allow Checkout privilege is also required to delete records. Note that the entity must have Delete Enabled selected.

If a user has read or read/write privileges on one attribute of an entity, then he also has read privileges to see the built-in attributes managed by the platform (for example: publisher, update date, etc.).

Privilege precedence

Privileges apply in order of precedence: Read/Write then Read then None. As a consequence, a user always has the best privileges associated to his roles

For example: John has several roles given to him:

  • Finance has Read privileges on the Customer entity.

  • HR has None privileges on the Customer entity.

  • Sales has Read/Write and Creation privileges on the Customer entity.
    The resulting privilege for John is Read/Write and Creation on the Customer entity.

Make sure you take into account all the roles of a user when reviewing his privileges. Any given role may grant this user additional privileges.

Row-level filtering

Entity privileges support Row-Level Filtering, to apply privileges only to a subset of the records of the entity. The subsets are defined using SemQL filters.

To define different privileges for different subsets of records in the same entity, it is possible to create several entity privileges for the same entity. Each privilege will address a subset of the records, defined by a Filter.

Row-level security filters can use model variables to customize the data access privileges for the connected user’s session.

For example, the Privilege Grant for the GenericUser role contains:

  • A first Entity Privilege allowing Read access to the employee entity.

  • A second privilege grant for the same employee entity, allowing Read/Write for certain attributes. This second privilege grant contains the following SemQL filter: employeeName=:V_USERNAME.
    Both these grants apply to the same employee entity and the same GenericUser role. The second one only applies to the filtered subset of records in this entity passing this filter. This subset corresponds to the connected user’s employee record.

Row-Level Filtering is not supported for duplicate management. A user who performs duplicate management operations for an entity must be granted privileges on all the records of the entity. Read privilege is required on all records of a duplicate manager, and write privilege is required to manipulate these duplicates.

Built-in roles

The following roles are built in within the platform:

  • semarchyConnect: This role must be granted for a user to log in. It should be granted by default to all users connecting to Semarchy xDM. This role is hard-coded and cannot be modified or used in the model.

  • semarchyAdmin: This role has full access to all the features of the platform. This role is hard-coded and cannot be modified. It can be used in the model, for example in privilege grants.

When creating a new model, a model-level privilege grant is automatically created for the semarchyAdmin role with Grant full access to the model selected. By modifying this privilege grant, the model designer can reduce the privileges of the semarchyAdmin role on the data, and prevent platform administrators from accessing data in the hub.

How are privileges applied?

The Semarchy data management applications user interface layout and actions are automatically modified depending on the user privileges:

  • Entities/Attributes/Records with no read privilege do not appear.

  • Entities/Attributes/Records with no read/write privilege cannot be modified in authoring.

  • Records cannot be added in steppers without the creation privileges.

  • Records cannot be removed from steppers without the removal privileges.

  • Exporting Data (Excel) is not possible without the export privilege.