Secure the data hub

This page 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 user and role associations, or entirely delegate user and role assignment to a third-party identity provider.

Understanding model security

Model privilege grants

Model privilege grants define a user’s access privileges based on their roles.
A model privilege grant is associated with a role and includes 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 privilege includes privileges defined at:

  • The entity-level: default privilege for all the attributes of the entity.

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

Example

  • 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, or salary attributes, etc.). Only users with the HR role can see these attributes.

Privilege types

The types of privileges 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 (e.g., publisher, update date, etc.).

Privilege precedence

Privileges apply in order of precedence: Read/Write, then Read, then None. As a consequence, users always have the best privileges associated with their roles.

Example

John has been assigned several roles:

  • The Finance role has Read privileges on the Customer entity.

  • The HR role has None privileges on the Customer entity.

  • The Sales role has Read/Write and Creation privileges on the Customer entity.

The resulting privileges 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.

Example

The privilege grant for the GenericUser role contains:

  • A first entity privilege granting Read access to the Employee entity.

  • A second privilege on the same Employee entity, granting a Read/Write privilege 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 the privilege grants.

When creating a new model, a model-level privilege grant is automatically created for the semarchyAdmin role with the Grant full access to the model option 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 user interface layout of the Semarchy data management applications and the available 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.