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
- 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.
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: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. |
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.