Introduction

One aspect of the InfoSphere MDM Server security module is to provide transaction authorization based on the user, or the group to which the user belongs. This authorization determines whether the user of the request is granted or denied the use of a transaction. This is referred to as the transaction authorization of the InfoSphere MDM Server security module. By default, transaction authorization is disabled.

To use transaction authorization, you configure InfoSphere MDM Server to use a transaction authorization provider class. The provider class interfaces with the system of your choice for managing transaction authorization.

A transaction authorization provider class has to implement the com.dwl.base.security.AuthorizationProvider interface. Out of the box, InfoSphere MDM Server provides a transaction authorization provider class that interfaces with the InfoSphere MDM Server Security Manager and another one that interfaces with a Lightweight Directory Access Protocol (LDAP) server. You can also implement your own provider class.

This article provides details on how to configure the LdapTransactionAuthorizationProvider class and enable transaction authorization on InfoSphere MDM Server. This provider class uses an LDAP server to manage transaction authorization. This sample provider class uses a simple directory structure to manage user, group, and transaction authorization.

Assumptions

This article uses Tivoli Directory Server version 6.1 as the LDAP server. It is assumed that you have general LDAP knowledge and experience with Tivoli Directory Server.

This article includes sample transactions submitted to an InfoSphere MDM Server version 8.0. You should know how to:

• submit transactions to InfoSphere MDM Server
• use the Configuration and Management component to configure InfoSphere MDM Server

Back to top

Specifying user and group in an InfoSphere MDM Server Transaction

For any InfoSphere MDM Server transaction, you specify the user or the group to which the user belongs in the DWLControl object that accompanies the transaction. Assuming that the user or group is successfully authenticated, transaction authorization checks whether the user or group is granted access to the transaction that is being requested.

Listing 1 is an example of the XML representation of the DWLControl object:

<DWLControl>
  <requesterName>myUserName</requesterName>
  <userRole>myGroup1</userRole>
  <userRole>myGroup2</userRole>
</DWLControl>

The <requesterName> element corresponds to the user, and the <userRole> element corresponds to the group to which the user belongs. The DWLControl object must contain one user name, and optionally zero or more group names per transaction. The user name and the group names are checked by the transaction authorization provider through the com.dwl.base.security.AuthorizationProvider interface to ensure transaction access is granted.

Back to top

LDAP transaction authorization provider

Generally, you may choose to use an LDAP transaction authorization provider for the following reasons:

• Your organization already has an LDAP server infrastructure.
• Your organization's users and groups are already set up on the LDAP server. In that case, you only need to add the InfoSphere MDM Server transactions that you want to associate with the users and groups.

The com.dwl.base.security.provider.LdapTransactionAuthorizationProvider class is just one implementation that uses an LDAP server to implement transaction authorization. It uses a simple directory structure to manage the relationships between users, groups and transaction names. Of course, you can implement your own LDAP transaction authorization provider class as long as your class implements the com.dwl.base.security.AuthorizationProvider interface.

Back to top

Using the LDAP transaction authorization provider from InfoSphere MDM Server

InfoSphere MDM Server provides an LdapTransactionAuthorizationProvider class that you can use against an LDAP server. The high-level steps of using this class are as follows:

• Design your authorization requirements
• Implement your authorization requirement on the LDAP server
• Configure the LdapTransactionAuthorizationProvider class to interface with the LDAP server

The following sections describe these steps in more details.

Designing authorization requirements

Authorization requirements should be based on your business needs. To illustrate how to use the LdapTransactionAuthorizationProvider class, let's assume your NewBusiness division has these three groups: DirectSales, CSRs and DataStewards. Your NewBusiness division decides to give these three groups access to the following transactions.

Users belonging to any of these groups can use the addPerson transaction to add a customer. For customer privacy reasons, only users belonging to the CSRs or DataStewards group can use the getPerson transaction to view customer information. And for data integrity reasons, only users belonging to the DataStewards group can use the updatePerson transaction to update customer information.

Assume in the NewBusiness division, Fred is a user of the DirectSales group, Sue is a user of the CSRs group, and Thomas is a user of the DataStewards group.

Based on the business needs above, you can set up your LDAP server to manage the following transaction authorization data:

An MDM_LADP.ldif file is provided to show how these users, groups, and transactions can be set up on the LDAP server. You can examine this file for details (see Downloads).

Configuring Tivoli Directory Server

Based on the MDM_LADP.ldif file provided, we assume the directory begins from the NewBusiness division. You need to create the following suffix in the Tivoli Directory Server instance. If you use the Tivoli Directory Server Instance Administration Tool, you can create the suffix o=NewBusiness,c=us as follows:

Creating the Directory Structure for transaction authorization

After the suffix is created, you can create the directory structure, as described in Table 1, on the Tivoli Directory Server instance.

Using the Tivoli Directory Server Administration Tool, you can import the MDM_LADP.ldif file provided to create the directory structure (see Downloads).

After you add the suffix and import the data, start the Tivoli Directory Server instance. You can also start the Tivoli Directory Server Web Admin if you want to verify the data is successfully imported. You should see three entries under the o=NewBusiness,c=us suffix. Refer to Tivoli Directory Server documentation to find out how to start the instance and the Web Admin.

Back to top

Configuring the LDAP transaction authorization provider class

After the data is loaded on the Tivoli Directory Server instance, you can configure the InfoSphere MDM Server LdapTransactionAuthorizationProvider class. You do this by configuring several InfoSphere MDM Server Configuration and Management settings. The settings are:

• /IBM/DWLCommonServices/Security/enabled

  This setting determines whether security is enabled for transaction authorization.

  Set this setting to true.

• /IBM/DWLCommonServices/Security/transaction_authorization_provider_class_name_1

  This setting specifies the transaction authorization provider class.

  Set this setting to com.dwl.base.security.provider.LdapTransactionAuthorizationProvider.

• /IBM/DWLCommonServices/LdapSecurityProvider/LdapSearch/jndiFactoryClass

  This setting specifies the JNDI factory class to look up the LDAP server.

  You can use the default setting of com.sun.jndi.ldap.LdapCtxFactory.

• /IBM/DWLCommonServices/LdapSecurityProvider/LdapSearch/jndiProviderUrl

  This setting specifies the URL pointing to the LDAP server.

  Assuming you configure the Tivoli Directory Server instance on port 389 on the localhost, set this setting to ldap://localhost:389.

• /IBM/DWLCommonServices/LdapSecurityProvider/LdapSearch/base

  This setting specifies the base object from which to start the search.

  In Figure 3, we set up the users and groups starting from the o=NewBusiness,c=us suffix. Therefore, set this setting to o=NewBusiness,c=us.

• /IBM/DWLCommonServices/LdapSecurityProvider/LdapSearch/Filter/user

  This setting specifies the search filter to apply to an LDAP server to search for transactions authorized for the user. The LdapTransactionAuthorizationProvider class externalizes three tokens at runtime to replace the actual values. They are:

  %t to replace the transaction name

  %u to replace the user name

  %g to replace the group name

  Therefore, based on the directory structure you implement in Table 1, set this setting to (&(objectClass=groupOfNames)(cn=%t)(member=uid=%u,*)).

  At runtime, if the addPerson transaction is requested by user Fred, a search string (&(objectClass=groupOfNames)(cn=addPerson)(member=uid=Fred,*)) is constructed to search against the LDAP server.

• /IBM/DWLCommonServices/LdapSecurityProvider/LdapSearch/Filter/group

  This setting specifies the search filter to apply to an LDAP server to search for transactions authorized for the group. Again, the LdapTransactionAuthorizationProvider class externalizes the three tokens %t, %u and %g.

  Therefore, based on the directory structure you implement in Table 1, set this setting to (&(objectClass=groupOfNames)(cn=%t)(member=cn=%g,*)).

  At runtime, if the addPerson transaction is requested by group CSRs, a search string (&(objectClass=groupOfNames)(cn=addPerson)(member=cn=CSRs,*)) is constructed to search against the LDAP server.

When these settings are configured, InfoSphere MDM Server retrieves the user and group information from the <requesterName> and <userRole> values respectively from the DWLControl object in a transaction, to determine whether that user is authorized to use the transaction. If a user is not authorized, the following error message will be returned in the response:

<TxResult>
  <ResultCode>FATAL</ResultCode>
  <DWLError>
    <ComponentType>108</ComponentType>
    <ErrorMessage>Security violation occurred.</ErrorMessage>
    <ErrorType>DIERR</ErrorType>
    <LanguageCode>100</LanguageCode>
    <ReasonCode>4934</ReasonCode>
    <Severity>0</Severity>
  </DWLError>
</TxResult>

The attached RequestResponseSamples.zip file contains the request and response samples for the test data (see Downloads.)

Back to top

Creating your own transaction authorization provider

You can also create your own transaction authorization provider. To do so, you need to create a class that implements the com.dwl.base.security.AuthorizationProvider interface. This interface includes the following method:

public boolean authorize(AuthenticationData authData, String resourceName)
                         throws SecurityProviderException;

The AuthenticationData argument is created from the DWLControl object when the transaction is submitted to InfoSphere MDM Server. The AuthenticationData argument contains the user and group information from the DWLControl object. The String argument is the resource name that you want to determine whether the user is authorized to use. In this case, it is the transaction name. Therefore, in your provider class, you need to use these two arguments to determine whether authorization is allowed or not. If authorization is allowed, this method should return true.

After you create the class, you configure it on InfoSphere MDM Server by setting the following Configuration and Management settings:

• /IBM/DWLCommonServices/Security/enabled

  Set this setting to true.

• /IBM/DWLCommonServices/Security/transaction_authorization_provider_class_name_1

  Set this setting to the name of your provider class.

Back to top

Conclusion

This article shows you several options of implementing transaction authorization on InfoSphere MDM Server. It shows the steps to set up the LdapTransactionAuthorizationProvider class provided by InfoSphere MDM Server. InfoSphere MDM Server also provides an interface to give you the flexibility to implement your own transaction authorization provider.

Back to top

Downloads

Information about download methods

Resources

Learn

• Understand IBM InfoSphere MDM Server Security, Part 1: Overview of Master Data Management Security" provides an overview of MDM Server's security features and how they work.
  
  
• 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 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" provides an authoritative, vendor-independent MDM technical reference for practitioners: architects, technical analysts, consultants, solution designers, and senior IT decisionmakers.
  
  
• The IBM InfoSphere MDM Server Information Center provided with the product provides a wealth of information on the security features of the product, including detailed configuration information for each of the described components above.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Discuss

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

About the author

Alan Li is an Application Architect on the InfoSphere MDM Server development team. His focus on this team is on the Party Domain and Account Domain.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Specifying user and group in an InfoSphere MDM Server Transaction
• LDAP transaction authorization provider
• Using the LDAP transaction authorization provider from InfoSphere MDM Server
• Configuring the LDAP transaction authorization provider class
• Creating your own transaction authorization provider
• Conclusion
• Downloads
• Resources
• About the author
• 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