Introduction

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.

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.

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.

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.

				

<?xml version="1.0" encoding=UTF-8"?>
<TCRMService>
	<RequestControl>
		<requestID> 504000</requestID>
		
		<DWLControl>
			<requesterName>jdoe</requesterName>
			<userRole>CallCentAppUser</userRole>
			<userRole>CstSuppRepL2</userRole>
		</DWLControl>
		
	</RequestControl>
	<TCRMTx>
		<TCRMTxType>updatePerson</TCRMTxType>
		<TCRMTxObject>TCRMPersonBObj</TCRMTxObject>
		<TCRMObject>
			<TCRMPersonBObj>
				<PersonPartyId>111</PersonPartyID>
				<TCRMPersonNameBObj>
					<GivenNameOne>Maria</GivenNameOne>
				</TCRMPersonNameBObj>
			</TCRMPersonBObj>
		</TCRMObject>
	</TCRMTx>
</TCRMService>
			

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.

Authorization

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.

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.

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.

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.

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.

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.

Audit

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

History

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.

Conclusions

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.

Resources

Learn

• Understand IBM InfoSphere MDM Server security, Part 2: Introduction to authentication services" provides detailed configuration and implementation instructions for two scenarios: a Java application client and a Web service application client.
  
  
• Understanding IBM InfoSphere MDM Server security, Part 3: Using LDAP to implement transaction authorization" provides an example showing how to implement a transaction authorization provider using an LDAP server.
  
  
• Understanding IBM InfoSphere MDM Server Security, Part 4: Using SAML in MDM Server" provides an overview of identity propagation in MDM Server.
  
  
• Understanding IBM InfoSphere MDM Server Security, Part 5: Integrating Master Data Management Server with Tivoli Federated Identity Manager" provides configuration instructions to extend identity propagation capabilities and facilitate client application development.
  
  
• "Enterprise Master Data Management: An SOA Approach to Managing Core Information": Get an authoritative, vendor-independent, MDM technical reference for practitioners such as architects, technical analysts, consultants, solution designers, and senior IT decision makers.
  
  
• "IBM InfoSphere MDM Server Information Center" Find a wealth of information on the security features of the product, including detailed configuration information for each of the components described above.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• developerWorks Information Management zone: Learn more about DB2. Find technical documentation, how-to articles, education, downloads, product information, and more.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  

Get products and technologies

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

Discuss

• Participate in the discussion forum.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Miguel 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 is an advisory IT architect at the IBM Toronto Lab. His main responsibility is to design and lead the development of features for MDM Server with a focus on the Product Domain. Although most of his career has been spent building products for the J2EE platform, he has been known to dabble in other technologies in his spare time, most recently Ruby on Rails.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Authentication and identity assertion
• Authorization
• Audit
• Conclusions
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Information Management on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers