Managing the Security

The application uses role-based security and privilege grants for accessing the Convergence for MDM features as well as the data contained in the MDM hub.

Understanding the Security Model

Platform-Level and Model-Level Security

There are two levels of security in Semarchy Convergence for MDM:

Role-Based Security

Both levels of security are role-based:

Depending on the application server hosting the Semarchy Convergence for MDM application, the roles/user association may be made through a concept of group: A user belongs to a group and the role is granted to the group.
Depending on its configuration, the application server may delegate user authentication and management in general to a security provider (SSO, LDAP, etc...).

Note: Note that roles are not only used for security purposes. They are also used as email aliases for email notifications.

Security Context

When you log in to the Semarchy Workbench:

  1. You enter the user and password in the Semarchy Convergence for MDM login window.
  2. This information is passed to the application server.
  3. The application server itself or its security provider (SSO, LDAP, etc.) authenticates the user, gets the list of roles associated to this user (possibly via groups) and returns this list of roles in the session’s Security Context.
  4. Semarchy Convergence for MDM starts a session with this security context, allowing:

Warning: Semarchy Convergence for MDM enforces security at several layers in the application. Insufficient privileges for a user will reflect in the user interface as missing elements or disabled menus. For example, a user with no privileges on Data Location will not see any of the Data Location links in his Overview perspective.

Note: Semarchy Convergence for MDM does not store the users, password and and user/roles associations. All this critical information remains in the application sever or in the enterprise security provider.

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: The user John has two user-defined roles granted to him:

The resulting privileges for John are Read/Write for both Job and Job Log Administration and Model Design.

Privileges Description

The following table describes the platform privileges that you can grant to a role:

Platform Privilege Description
Data Location Grants access to all components of the Data Locations perspective and to the Notification Servers and the Variable Value Providers in the Administration Console perspective. Write privileges are needed to create data editions, deploy new model editions and create data editions. Write privileges are also required to create and modify variable value providers and notification servers.
Model Design Grants access to all the components of the Model Administration (to manage model editions/version control) and Model Edition (to design models) perspective. Write privileges are needed to modify models and create new model editions.
Execution Engine Grants access to the Execution Engine, Integration Batch Poller and Web Services Manager components in the Administration Console Perspective. Write privileges are needed to start/stop and configure these components.
Job and Job Log Administration Grants access to Job Logs and Job Definitions in the Administration Console Perspective. Write privileges are needed to purge the logs. Note that you need the Execution Engine privileges to restart jobs in queues.
Logging Configuration Grants access to the Logging Configuration component in the Administration Console Perspective. Write privileges are needed to modify this configuration.
Plug-ins Administration Grants access to the Plug-ins component in the Administration Console Perspective. Write privileges are needed to add new plug-ins.

Built-in Roles

The following roles are built in the platform:

Important: Be cautious when granting the semarchyAdmin role. This role defines a super user who can create roles, grant privileges and update the license information.

Managing Roles and Privileges

Creating the Roles and Users in the Application Server Security Realm

Before declaring a new role in Semarchy Convergence for MDM, make sure that this role is defined in the application server and that a user is granted with this role and the semarchyConnect role to log in to Semarchy.

Note: The role/user creation procedure depends on the application server hosting Semarchy Convergence for MDM. Please refer to your application server documentation for more information.

An example is given below for creating a role and a user for Apache Tomcat.

To configure a new role and user for Semarchy:

  1. Stop the Apache Tomcat Server using the stop the Apache Tomcat server using <tomcat>/bin/shutdown.bat (Windows) or <tomcat>/bin/shutdown.sh (UNIX/Linux), where <tomcat> is the Apache Tomcat installation folder.
  2. Edit the <tomcat>/conf/tomcat-users.xml file.
  3. In the <tomcat-users> section, add the following lines ( <password> is the password for this user):
  4. Save the file.
  5. Restart the Apache Tomcat server using <tomcat>/bin/startup.bat (Windows) or <tomcat>/bin/startup.sh (UNIX/Linux).

A new role semarchyDev is created. The user john is also created with the semarchyConnect built-in role and the semarchyDev role.

Declaring the Roles in Semarchy Convergence for MDM

To create new role:

  1. Open the Administration Console perspective.
  2. In the Administration View, double click the Roles node.
  3. In the Roles editor, right-click Roles table and select New Role. The Install Role wizard opens.
  4. Enter the following information:
  5. Click Next.
  6. Select the privileges to grant to this role. For example: Model Design: Read/Write, Job and Job Log Administration: Read.
  7. Click Finish.

The role is created. You can connect a user with this role to test the set of privileges.

Warning: Make sure to use a role name that matches exactly (with the same case) a role name defined in the application server configuration.

Sample Roles

You can use the following role examples in a typical Semarchy Convergence for MDM configuration:

Platform Privilege Dev Operator Deployer
Data Location Read Read Read/Write
Model Design Read/Write None Read
Execution Engine Read Read/Write Read
Job and Job Log Administration Read Read/Write Read
Logging Configuration None Read/Write None
Plug-ins Administration None Read Read/Write

Note: These roles are given as examples and should be adapted to your environment’s requirements.