Understanding IBM InfoSphere MDM Server security, Part 3: Using LDAP to implement transaction authorization

IBM® InfoSphere™ Master Data Management Server allows you to plug in your transaction authorization provider. In this article, learn about the default transaction authorization provider and explore an example showing how to implement a transaction authorization provider using an LDAP server. Other articles in this series detail how to use and configure various other MDM Server security components to solve real-world business problems.

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.

Figure 1. Transaction authorization
InfoSphere MDM Server 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.

Figure 2. Transaction authorization implementation options
InfoSphere MDM Server Transaction authorization implementation options

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

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:

Listing 1. XML representation of DWControl 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.


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.


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.

TransactionGroup
addPersonDirectSales, CSRs, DataStewards
getPersonCSRs, DataStewards
updatePersonDataStewards

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:

Table 1. Transaction Authorization By User/Group
 addPersongetPersonupdatePerson
DirectSales (Fred)AllowNot allowNot allow
CSRs (Sue)AllowAllowNot allow
DataStewards (Thomas)AllowAllowAllow

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:

Figure 3. Add o=NewBusiness,c=us Suffix
Add suffix

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

Figure 4. Import LDIF file
Import LDIF file

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.

Figure 5. Directory entries
Directory Entries

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:

Listing 2. Error message for unauthorized user
<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.)


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.


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.


Downloads

DescriptionNameSize
Sample LDAP import file for user/group/transactionMDM_LDAP.zip1KB
Sample Transaction requests and responsesRequestResponseSamples.zip16KB

Resources

Learn

Discuss

Comments

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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=353137
ArticleTitle=Understanding IBM InfoSphere MDM Server security, Part 3: Using LDAP to implement transaction authorization
publish-date=11202008