Security access control

InfoSphere® MDM Reference Data Management Hub provides role-based security control over the reference data sets, mappings, and managed systems. The InfoSphere MDM Reference Data Management Hub authentication is designed to work with standard authentication mechanisms in place in the enterprise, such as LDAP.

The security logic within InfoSphere MDM Reference Data Management Hub considers three criteria in determining the create, read, update, and delete access control rights for a user. These criteria are:

The user’s role
The ownership group that is associated with the entity
The lifecycle state of the entity

For a particular user interacting with an entity in the application, depending on the three variables previously mentioned, the user has a combination of create, read, update, and delete access to that entity. Create, update, and delete access rights over an entity allow a user to do as follows:

Sets

For delete and update permissions to apply, the user must belong to one of the owner groups.

Create

Create sets.

Delete

Delete existing sets.

Update

Create a version.
Copy to a set.
Change the set level fields.
Add, delete, and update values.
Add, delete, and update translations.
Add, delete, and update subscriptions.
Add, delete, and update hierarchies.

Mappings

For delete and update permissions to apply, the user must belong to one of the owner groups.

Create

Create mappings.

Delete

Delete existing mappings.

Update

Create a version.
Change mappings fields.
Add, delete, and update value mappings.

Managed systems

For delete and update permissions to apply, the user must belong to one of the owner groups.

Create

Create managed systems.

Delete

Delete existing managed systems.

Update

Copy a managed system.
Change managed systems fields.
Add, delete, and update managed system properties.

Data types

There is no ownership for this entity. The permissions apply to all instances.

Create

Create data types.

Delete

Delete existing data types.

Update

Copy a data type.
Change data type fields.
Add, delete, and update data type properties.

Folders

For delete and update permissions to apply, the user must belong to one of the owner groups.

Create

All users can create folders.

Delete

Delete a folder and its contents.

Update

Copy a folder.
Rename a folder.
Change the folder’s owner groups.

Attribute Level Security (Field Level Security) considerations

Attribute Level Security (or Field Level Security) has three levels of checks that it performs:

Role and Owner Group level
Role level
No Specification or default

If permissions are found at either level 1 or level 2 then the lower levels are not checked.

Within a level you can specify the field name explicitly, or you can use a wildcard character * to represent all columns. You can also use a comma separated list of Fields.

Within a role for a level, specifying the Column name explicitly has priority over using a wildcard character.

At the same level if a user has different permissions for multiple roles, then VISIBLE takes precedence over READ-ONLY, and READ-ONLY takes precedence over HIDDEN.

Certain fields (SET type, SET state, VALUE code and VALUE name) cannot be hidden. If the logic in the configuration file defines these to be hidden, then they will be converted to READ-ONLY.

For example, you could use the following in the permissions file for a set:

VALUE_DRAFT_DATA_STEWARD_HIDDEN = Description
VALUE_DRAFT_DATA_STEWARD_READ_ONLY = Prop1
VALUE_DRAFT_DATA_STEWARD_VISIBLE = *

VALUE_DRAFT_ADMINISTRATOR_HIDDEN = Prop1
VALUE_DRAFT_ADMINISTRATOR_READ_ONLY = 
VALUE_DRAFT_ADMINISTRATOR_VISIBLE = *

Using those settings, you would see the following results for these users:

Table 1. Example Attribute Level Security settings
Users by roles	Description field	Reason	Prop1	Reason
Data Steward	HIDDEN	Level 2 - Explicitly specifying Description as HIDDEN, overrides the wildcard for VISIBLE.	READ-ONLY	Level 2: Explicitly specifying Description as READ-ONLY, overrides the wildcard for VISIBLE.
Admin	VISIBLE	Level 2 - Wildcard for VISIBLE	HIDDEN	Level 2: Explicitly specifying Description as HIDDEN, overrides the wildcard for VISIBLE.
Approver	VISIBLE	Level 3 default permission for no specification in the file is VISIBLE.	VISIBLE	Level 3: default permission for no specification in the file is VISIBLE.
Data Steward + Admin	VISIBLE	VISIBLE for Admin role takes precedence over HIDDEN for the Data Steward role.	READ-ONLY	Level 2: READ-ONLY for the Data Steward role takes precedence over HIDDEN for the Admin role.
Data Steward + Approver	HIDDEN	HIDDEN for the Data Steward role in Level 2 overrides VISIBLE in level 3.	READ-ONLY	READ-ONLY for Data Steward in level 2 overrides VISIBLE in level 3.

As another example, you could add the following to the example property file:

VALUE_DRAFT_DATA_STEWARD_CRM_VISIBLE = *

This is equivalent to the first level check for Role and Owner Group level. This check occurs first, and it indicates that a user who is in the CRM group and is a Data Steward will see all fields; it also means that the Description field will not be hidden for that user.

Last updated: 22 Mar 2017