Understand IBM InfoSphere MDM Server security, Part 1: Overview of Master Data Management Server security

Authentication, authorization, and audit in MDM Server 8

The ultimate goal of a Master Data Management (MDM) solution is to be the authoritative source of all important shared data across the enterprise. As such, the security of this information is of utmost concern. There are aspects of security that IBM InfoSphere MDM Server addresses directly and those that are addressed by the environment in which it operates. Part 1 of this series focuses on the former of these two aspects and details the components that comprise this view. Subsequent articles in this series will detail how to use and configure these components to solve real-world business problems.


Miguel A Ortiz, Jr. (maortiz@us.ibm.com), Software Engineer, Systems Documentation, Inc. (SDI)

Author Photo: Miguel OrtizMiguel A. Ortiz, Jr. is a software engineer on the Information Platform and Solutions team at the IBM Austin Lab. His focus is on MDM Server security, IPS product integration, and third-party product integration.

Lee McCallum (lmccallu@ca.ibm.com), Advisory IT Architect, Systems Documentation, Inc. (SDI)

Author Photo: Lee McCallumLee McCallum is an advisory IT architect at the IBM Toronto Lab who works for the Information Management Technology Ecosystem (IMTE) Team. After designing and leading the development of many MDM Server features for over five years, he is now focused on enabling IBM Business Partners around the world on MDM Server, and to an increasing extent, the rest of IBM's InfoSphere MDM product portfolio. With a strong and passionate development background, he still finds time to dabble in other technologies, most recently prototyping MDM Server demo widgets with Dojo.

11 September 2008

Also available in Chinese


InfoSphere MDM Server security landscape

IBM InfoSphere MDM Server provides a central architecture to solve enterprise master data management issues; which include account, customer, and product data. In such an environment, the protection of the data's confidentiality, integrity, and availability is of utmost importance and the risk of improper information security measures can result in corrupted business intelligence (BI), credit card theft, privacy violation, and law suits.

Software stack for all articles in this series

All discussions of MDM Server are related to the InfoSphere MDM Server 8.0 release and its related stack. This article assumes a familiarity with MDM Server and the terminology used within it's product manuals.

Borrowing from the logical SOA security architecture described in "Enterprise Master Data Management: An SOA Approach to Managing Core Information" (found in the Resources section of this article), you can see that there are three tiers of security services:

  • Business security services: Responsible for fulfilling the security and privacy goals of the enterprise, which includes non-repudiation services, compliance, and reporting to name a few.
  • Security policy management: Responsible for ensuring that the security policies are consistently defined and managed across the enterprise. This tier can be thought of as the link between business security services and IT security services and includes areas such as policy administration and distribution.
  • IT security services; Responsible for providing the core security services required by the enterprise. Areas of concern for this tier include authentication and confidentiality services.

This article focuses on the components of MDM Server that address the authentication, authorization, and audit aspects of IT security services for MDM. At a high level, these three areas address the establishment of the identity of the consumer, access rights to services, and finally provide a trail of who did what respectively. This article also provides an overview of security environment considerations when designing your MDM solution.

InfoSphere MDM Server security illustrated

For simplicity, this article references a basic MDM transaction scenario depicted in Figure 1.

Figure 1. Simple MDM scenario
Simple MDM scenario

The scenario involves an end user, in this case Jane Doe, interacting with an MDM client application, a call center for example. The client application in time uses MDM Server as the master data source. Figure 1 is an example of the end user, Jane, updating information of a customer named Maria.

Authentication and identity assertion

End user vs. system user identities

In an MDM architecture, there is a distinction between an end user and a system user. An end user refers to the entity that indirectly generates MDM transactions through the use of a system user. This entity could be a person or system. In this case, the end user is Jane, a customer service representative, who is interacting with a call center application. Jane may not even be aware that many of these interactions results in calls to the MDM Server.

In this scenario, the call center application, also known as the MDM client application, is the system user. The system user serves as the bridge between the end user and the data stored in MDM Server. It serves as an interface application to the end user and translates the end user's requests into a set of MDM Server transactions. Note that the system user and MDM Server share a trusted relationship.

Figure 2. Simple MDM authentication flow
Simple MDM authentication flow

End user authentication

When considering end user authentication in an MDM architecture, keep in mind the following:

  • The end user never directly interacts with the MDM Server. They interact indirectly through the system user.
  • The MDM Server and system user share a trusted relationship

Given the facts above, the MDM Server trusts the system user to perform adequate authentication and credential validation. Samples of the latter are: a username and password pair, a certificate, or a token.

System user authentication

In order for the system user to access any of the MDM Server components, it needs to authenticate to the J2EE container and establish a trusted channel. The J2EE container refers to the application server used to host MDM Server. Currently, Web Logic and WebSphere Application Server are supported.

The system user should also be included in the ServiceConsumer role, which grants limited access to MDM components. The roles is explained later in the Authorization section of this article

Identity assertion

Although the MDM Server entrusts end user authentication to the system user, it is necessary for it to know the identity of the end user in order to provision transactional and data authorization. In this environment, the system user asserts the identity of the end user in a per transaction basis.

The end user information is sent to the MDM Server within the DWL Control stub, located in the body of the transaction message. This data is highlighted, in the sample XML transaction message below, which would represent step 4 in Figure 2.

Listing 1. DWL Control in XML transaction message
<?xml version="1.0" encoding=UTF-8"?>
		<requestID> 504000</requestID>
Figure 3. Authentication assertion parser
Authentication assertion parser

Upcoming articles on the authentication assertion parser

Future articles in this series will further explain the capabilities of the authentication assertion parser (AAP). Article 5 of this series will show how to extend the AAP to support a number of other tokens and validate them using Tivoli Federated Identity Manager.

Aside from the standard DWL Control XML nodes, MDM Server also allows for identity tokens to be inserted in the DWL Control stub. The token is then parsed by the AAP and necessary information is extracted. The default implementation of AAP supports SAML 1.1. However, this is a point of customization that can be replaced to support other tokens, validation of tokens, or external services. It is important to note that by default, the assertion is not validated once inside MDM Server.


EJB component authorization

EJB component authorization is managed and enforced in the application server where the MDM Server is hosted. Client applications that access the MDM Server through Web services or RMI, and successfully authenticate to the application server, are given the role of ServiceConsumer.

In situations where an MDM client application is accessing MDM Server through Java Messaging Services (JMS) and WebSphere MQ (JMS/MQ), the JMS/MQ utility is responsible for authenticating to the application container so the utility itself asserts the role of Service Consumer. The WebSphere MQ utility may need to be further secured to only allow MDM client applications to access MDM Server.

ServiceConsumer vs. ServiceProvider roles

There are two user roles of concern to MDM Server, that of ServiceConsumer and ServiceProvider. Every MDM Entry Point Component (including Web service, service controller and process control) is configured to only grant access to system users that are of the ServiceConsumer role. Each of these entry points then proceed to use the ServiceProvider role as the Run As security role when forwarding the transaction to the internals of MDM Server for processing.

The ServiceConsumer role grants a limited amount of access to MDM Server's components. It is important to note that by default, the ServiceConsumer role is assigned to All Authenticated in the security domain in which MDM Server is part of. It is suggested that you configure this role to include only the particular system users that would have a valid reason for accessing MDM Server.

Transaction authorization

Transaction security is the first level of authorization enforced within MDM Server. This process is performed by the Transaction Authorization Provider component and it determines if the end user is allowed to invoke the requested transaction. By default, MDM Server is configured with the MDM Security Manager as the Transaction Authorization Provider. The MDM Security Manager is quite an extensive component of MDM Server, complete with a data model containing user and group profile information. This model ties directly into MDM Server's metadata model, identifying the transactions that the users and groups are entitled to invoke.

Figure 4. Transaction authorization
Transaction authorization

The Transaction Authorization Provider component can be configured to utilize an LDAP server or a custom built solution instead of MDM Security Manager. In fact, multiple transaction authorization providers can be configured, allowing for the implementation of complex provisioning schemes.

Figure 5. Transaction authorization implementation options
Transaction authorization implementation options

If the end user is not authorized to invoke this service, an error is surfaced and the transaction is marked for rollback.

Persistency entitlements

Persistency entitlements, the second level of authorization enforced by MDM Server, are validated to ensure that the user has the authority to change the data they are changing, just before the controller level transaction is called. For example, the end user (Jane Doe), may be able to view Maria Gutierrez's record, but Jane may not be allowed to change Maria's priority field. This constraint is configured within the Persistency Entitlements component.

Figure 6. Flow to persistency entitlements
Flow to persistency entitlements

In this particular scenario, Jane is attempting to update Maria's name, in which case a check on Jane's authority to modify the name field is launched. If Jane is indeed authorized, the transaction continues on. If she is not authorized, an error is raised and the transaction is marked for rollback.

Extensive configuration is available within MDM Server on how to determine which attributes and entities the end user is allowed to persist. Consult the MDM Developer's Guide for further information.

Rules of Visibility (RoV)

RoV is the third level of authorization within MDM Server. It enforces an authorization process that may limit the end user on the amount of records it can view after the controller level transaction is called.

Figure 7. Flow to RoV
Flow to RoV

For example, Jane being a level 2 customer service representative, is allowed to see high priority customers as well as lower priority customers. Where as a lower level customer service representative may not be able to see high priority customers. This is an especially important feature for master data management due to the varying sensitivity of kept data and the various roles within an organization.

Access token

Access tokens are a variation of RoV and offer a coarser grained authorization level and better performance. The concept of an access token is very similar to label-based authorization controls. Tokens are assigned to particular end users or groups and to the records that the particular user is allow to access. In case of a request, the end user can only access the records to which an equivalent token has been assigned to.

Figure 8. Flow to access tokens
Flow to access tokens

For example, Jane may have a list of customers she is in charge of. In this case, a token can be assigned to Jane as well as to her customer records. When Jane requests to see all customers, only her customer list will show.

As opposed to the end user's group membership, token information is not passed within the DWL Control. The token information is kept in the MDM Server database and accessed with every transaction. Also, the assignment of tokens to groups or records is outside of the MDM Server's responsibilities.


Transaction audit information log (TAIL)

At the point in which the transaction is fully authorized, a log entry is recorded by TAIL. Out of the box, MDM Server is configured to log all external (controller level) and internal (component level) transactions and key conceptual information (such as entity IDs) to the application's operational tables. Events logged can be configured from the Transaction Audit Information screen, within the MDM Server Administration service. Services are provided to retrieve this information based on criteria like user type, transaction type, entity, and date ranges. The transactions and data that are logged are configurable within the TAIL data model.

For more information on TAIL refer to the "IBM InfoSphere Master Data Management Server (MDM Server) System Management Guide."


Finally, after the transaction is committed, one or more database triggers are invoked, which update the corresponding history tables with a record of the change and who changed it (among other things). Keeping track of the changes as they are made allows for a reconstruction of the record at a point in time and gives a full audit trail of a given record.


MDM Server provides many capabilities to address a master data architecture's authentication, authorization, and audit needs. MDM Server's highly customizable nature provides a platform that makes it possible to configure existing components and services (such as use of access tokens) as well as to replacing them entirely for more sophisticated and proprietary needs (such as providing a custom authentication parser that integrates with LDAP to provide transactional end-user authentication). The many different ways you can customize and configure the security aspects of the application will be covered in subsequent parts of this series.



Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Information management on developerWorks

Zone=Information Management
ArticleTitle=Understand IBM InfoSphere MDM Server security, Part 1: Overview of Master Data Management Server security