Understand IBM InfoSphere MDM Server Security, Part 5: Integrating Master Data Management Server with Tivoli Federated Identity Manager

Facilitating identity propagation in an MDM Server environment

This article builds on Part 4 of this series, "Using SAML in MDM Server Security," and shows how the integration of IBM® InfoSphere™ Master Data Management (MDM) Server and IBM Tivoli® Federated Identity Manager (TFIM) can extend MDM Server’s identity propagation capabilities and facilitate client application development. Learn how to use and configure these components to solve real-world business problems.

Miguel A Ortiz, Jr. (maortiz@us.ibm.com), Software Engineer, IBM China

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.



Patrick Wardrop (pwardrop@us.ibm.com), Senior Software Engineer, IBM

Patrick WardropPatrick Wardrop is a developer on the Tivoli Federated Identity Manager team. He holds a Bachelor of Arts in Computer Information Science from the University of Guelph, Guelph, Ontario, Canada.



26 February 2009

Also available in Chinese

Introduction

InfoSphere Master Data Management (MDM) Server is frequently implemented in complex environments. In such environments, you may find that integration with external security products reduces your cost, minimizes the complexity of your environment, and provides you with a more secure architecture.

By integrating MDM Server with Tivoli Federated Identity Manager (TFIM), you can improve the security environment for your MDM Server and improve your compliance with current Web security standards. This article gives you step-by-step instructions for extending the default authentication parser (SAML11Parser) provided with MDM Server V8.0.1 with a custom TFIM V6.2 authentication parser (TfimMdmIdentityMediator).

Software stack for all articles in this series

In this series, "MDM Server" refers to the InfoSphere MDM Server 8.0 release and related stack. This article assumes you are familiar with MDM Server and the terminology used in its product manuals.

This integration solution utilizes the current environment’s security framework. By doing so, it minimizes your development effort to modify current applications for MDM Server security compatibility and facilitate rapid development of new applications.

Scenario

As discussed in the fourth article of this series, "Using SAML in MDM Server Security," MDM Server is natively capable of accepting SAML 1.1 tokens as an alternate authentication assertion containing the user’s identity and group membership. (DWL Control token is the default.) The MDM Client application is responsible for assembling the security information needed by MDM Server and adding it to the corresponding transaction.

If the security architecture in which the MDM Client resides uses SAML 1.1 tokens, then this feature is a major benefit. However, there are many other standards and proprietary security tokens that are used in different environments. For example, Kerberos tokens are the native security token for Microsoft®, PassTickets are generally used in mainframe environments, Lightweight Third-Party Authentication (LTPA) is used in WebSphere® Application Server environments, and iv_creds are used in Tivoli Access Manager environments.

In cases where the security architecture does not use SAML 1.1 tokens, the MDM Client needs to either parse and extract user information from the default environment token and properly build a DWL Control token, or acquire the user information by accessing a user repository. However, with both of these options you end up introducing extra complexity into your application development process and security architecture.

A third option is to extend MDM Server so that it understands the environment’s native token and consumes it as a valid authentication assertion, which makes it comparable to the native SAML 1.1 support. This article demonstrates an example of this approach by showing you how you can broaden MDM Server's token support by extending it to integrate with TFIM’s Security Token Service (STS). By integrating with TFIM, MDM Server gains the ability to consume any, or a combination of, tokens understood by TFIM’s STS.

By integrating MDM Server with TFIM, you gain wider standards compatibility along with other benefits, including:

  • Validation of a token’s digital signature
  • Capability of accepting encrypted token content
  • Ability to map the identity in a token to MDM Server's local identity

Integration design and architecture

As a security token located in the DWLControl arrives at the MDM Entry Point, the MDM Server forwards the message to the Authentication Assertion Parser (AAP) component. The AAP delegates the process to the parser class configured in the /IBM/DWLCommonServices/Security/SAML/security_data_parser MDM configuration table parameter. The SAML11Parser class is set by default. The key to integrating the two products is the capability to extend the MDM SAML 1.1 Assertion Parser to include an STS client that utilizes the WS-Trust protocol to communicate with an STS server. In this scenario, the parser class is called TfimMdmIdentityMediator.

Security token flow

Figure 1 shows the token flow that occurs as the AAP component receives a client request with an embedded LTPA token.

Figure 1. Security token flow
Security Token Flow

The steps of the flow are as follows:

  1. The AAP passes the authData element, which contains the LTPA token, to the TfimMdmIdentityMediator class (mediator class).
  2. The mediator class extracts the client component of the authData element (in this case the LTPA token).
  3. The mediator class creates a WS-Trust Request Security Token message that includes the extracted element and sends the request to the configured STS.
  4. The STS validates the received security token.
  5. STS applies any required identity mapping (group retrieval, attribute retrieval).
  6. STS issues a SAML 1.1 Assertion in the format that the MDM Server supports.
  7. STS returns the SAML Assertion.
  8. When the mediator class receives the returned SAML 1.1 Assertion from the STS server, it passes it down to the default MDM SAML 1.1 Assertion Parser.
  9. The SAML 1.1 Assertion is parsed and the resulting authData is returned all the way back to the AAP.

What is TFIM?

IBM Tivoli Federated Identity Manager (TFIM) provides a simple, loosely-coupled model for managing identity and access to resources that span companies or security domains. Rather than replicate identity and security administration at both companies or domains, TFIM provides a simple model for managing identities and providing access to information and services in a trusted fashion.

For companies deploying Service Oriented Architecture (SOA) and Web services, TFIM provides policy-based integrated security management for federated Web services. The foundation of TFIM is trust, integrity, and privacy of data. For Web-based applications, TFIM supports the most common user-centric and enterprise-centric federated single sign-on protocols, such as InfoCard, OpenID, SAML 1.0/1.1/2.0, and WS-Federation.

This article shows you how to utilize TFIM's Security Token Service (STS), which is typically used in SOA scenarios for identity mediation. The STS is used to help two or more parties securely exchange security credentials by establishing "trust" in a brokered trust relationship. Clients communicate remotely to the STS via WS-Trust, which is an extension to the WS-Security standard. The STS provides the ability to validate, exchange, and issue security credentials, which are typically in the form of XML security tokens. Some of the most commonly used security token types are SAML Assertion 1.0/1.1/2.0, GSS Kerberos V5 AP_REQ, PassTickets, and Lightweight Third-Party Authentication (LTPA).

Configuring MDM Server

Step 1: Prepare the MDM Server environment

To perform this step, you first need to obtain the TFIM-MDMS.zip file from the Download section of this article. The files described below are contained in the zip file.

  1. Decompress tfimmdm.tar into the MDM-App.ear EARs directory.
    The default directory for Linux® is: /opt/ibm/websphere/AppServer/profiles/profile name/installedApps/cell name/MDM-App.ear
  2. Copy com.ibm.tivoli.fimmdm.jar into the MDM-App.ear directory.
  3. Copy DWLCommonServicesEJB.jar into the MDM-App.ear directory.
    Note: If you install fix packs to MDM Server, be sure to verify this integration still works.
  4. Copy tfim-mdm.properties into the lib/ext directory for WebSphere Application Server.
    The default directory for Linux is: /opt/ibm/websphere/AppServer/lib/ext
  5. Update tfim-mdm.properties to point to the appropriate STS endpoint.

Step 2: Configure and authorize a user group for testing

In this step, you use the MDM Server’s Administration application to create a group and assign the proper transactions to the group.

  1. From your Web browser, log in to the Administration application:
    http://server-name:port/CustomerBusinessAdminWeb/
  2. Create a group:
    1. Go to the Add User Group page: Security -> User Groups.
    2. Click the Add button.
    3. At the Add User Group page, enter a User Group Name and optionally a Description.
    4. Click the Submit button.
      Figure 2. Add User Group page
      Add User Group page
  3. Associate the transactions to be tested with the group you just created. For this example, use the searchPerson transaction.
    1. Go to the Transaction Association page: Security -> Transaction Associations.
    2. Select the group from the Select User Group to Assign Transactions menu and click the GO button.
      Figure 3. Transaction Association page
      Transaction Association page
    3. On the Assign Transaction to a User Group page, select searchPerson from the Select Transaction to Assign menu and click the ADD button.
    4. After the page refreshes, click the SUBMIT button.
      Figure 4. Assign Transaction to a User Group page
      Assign Transaction to a User Group page

Step 3: Update MDM Server configuration

In this step, you set the MDM Server SAML/security_data_parser parameter to the name of the extension class and assure that security is enabled in the environment.

  1. Start the MDM Server management agent.
    1. Navigate to the management agent directory located at:
      MDM Home Directory/ManagementAgent
    2. Run the startAgent.sh script.
  2. Start the MDM Server Management Console.
    1. Navigate to the Management Console directory located at:
      MDM Home Directory/ManagementConsole
    2. Run the console.sh script.
  3. Follow the menus to change parameter values.
    1. Set the /IBM/DWLCommonServices/Security/SAML/security_data_parser configuration element to the name of your class. For this example, use the class: com.ibm.tivoli.fim.mdm.TfimMdmIdentityMediator
    2. Set the /IBM/DWLCommonServices/Security/enabled configuration element to true (if it is not already true).

Configuring TFIM Security Token Service (STS) Chains

Step 4: Configure STS with the TFIM management console

This example uses an incoming LTPAv1 token type.

  1. From your Web browser, open the TFIM management console:
    http://console.tfim.domain.com:9060/ibm/console
  2. Go to the Trust Service Chains panel: Tivoli Federated Identity Manager -> Configure Trust Service -> Trust Service Chains.
  3. Click the Create... button.
    Figure 5. Trust Service Chains panel
    Trust Service Chains panel
  4. On the Introduction panel of the Trust Service Chain Mapping Wizard, click the Next button.
    Figure 6. Trust Service Chain Mapping Wizard — Introduction
    Trust Service Chain Mapping Wizard - Introduction
  5. On the Chain Mapping Identification panel, enter a Chain Mapping name and optionally a Description. Click the Next button.
    Figure 7. Trust Service Chain Mapping Wizard — Chain Mapping Identification
    Trust Service Chain Mapping Wizard - Chain Mapping Identification
  6. On the Chain Mapping Lookup panel, enter an AppliesTo Address (for example, http://mdm.ibm.com/saml11) and an Issuer Address (for example, http://ibm.com/ldap).

    Note: The AppliesTo Address and Issuer Address you use should match what you specified in the tfim-mdm.properties file in Step 1 above.

  7. On the Chain Identification panel, enter a Chain Name for the new chain and optionally a Description. Click the Next button.
    Figure 8. Trust Service Chain Mapping Wizard — Chain Identification
    Trust Service Chain Mapping Wizard - Chain Identification
  8. On the Chain Assembly panel, construct a chain with the following modules:
    • com.tivoli.am.fim.trustserver.sts.modules.STSLTPATokenModule
    • com.tivoli.am.fim.trustserver.sts.modules.STSMapDefault
    • com.tivoli.am.fim.trustserver.sts.modules.SAMLTokenSTSModule
    Figure 9. Trust Service Chain Mapping Wizard — Chain Assembly
    Trust Service Chain Mapping Wizard - Chain Assembly
  9. Use the LTPA Token Module Configuration panel to configure the STSLTPATokenModule module. Import an LTPA exported key (you can export the LTPA key using a WebSphere Application Server security management panel). Once the key has been imported, enter the password for the key and click the Next button.
    Figure 10. Trust Service Chain Mapping Wizard — LTPA Token Module Configuration
    Trust Service Chain Mapping Wizard - LTPA Token Module Configuration
  10. Use the Default Map Module panel to configure the STSMapDefault module. Select the XSLT file you want to use for identity mapping. You can use the ltpa_saml_1x.xsl file contained in the TFIM-MDMS.zip file from the Download section, but be sure to change the user role from ALLOWEDGROUP to the correct role. The example only includes a single group for the user, but you can modify it to include additional groups. Alternatively, you can use the DirectoryIntegratorSTSModule (TDI Module) as a mapping module. The TDI module has the capability to query external data sources to retrieve attributes and user's groups.

    After you make a selection, click the Next button.

    Figure 11. Trust Service Chain Mapping Wizard — Default Map Module
    Trust Service Chain Mapping Wizard - Default Map Module
  11. Use the SAML Module Configuration panel to configure the SAMLTokenSTSModule to issue the assertions that the MDM server can consume. Enter a value for the name of the organization issuing the assertions and clear the option Sign SAML Assertion checkbox (the MDM server does not validate signed assertion).

    Once the configuration options are set, click the Next button.

    Figure 12. Trust Service Chain Mapping Wizard — SAML Module Configuration
    Trust Service Chain Mapping Wizard - SAML Module Configuration
  12. On the Summary panel, review the chain you have defined. After reviewing, click the Finish button to create the chain.
    Figure 13. Trust Service Chain Mapping Wizard — Summary
    Trust Service Chain Mapping Wizard - Summary

Testing

Use the following test to verify your integration of MDM Server with TFIM. The test uses the Installation Verification Testing (IVT) tool provided by MDM Server.

  1. Extract the SearchPersonWithLTPA.xml file from the TFIM-MDMS.zip file in Download.
  2. Edit SearchPersonWithLTPA.xml and make any necessary modifications to match your environment, including updating the BinarySecurityToken with a fresh LTPA token.
  3. Copy the SearchPersonWithLTPA.xml file into the following directory:
    MDM Install Directory/IVT/xml/
    (for example, /opt/ibm/infosphere/MDMServer/IVT/xml)
  4. Navigate to the IVT directory located at:
    MDM Install Directory/IVT
  5. Run the verify.sh (or verify.bat for Windows®) script to initiate a test.
  6. Once the verify.sh script completes, check the results in the ResponseSearchPersonWithLTPA.xml file located at:
    MDM Install Directory/IVT/xml/response/

    If the file does not contain any error messages, your integration was successful.

Possible enhancements

You may want to consider making the following enhancements to the TfimMdmIdentityMediator class:

  • You can add caching to prevent the re-validation of identical tokens in sub-sequent transactions.
  • You can enable introspection of the provided security token to allow for multiple token types per MDMS instance.

Conclusion

Leveraging the flexible security framework provided by the IBM InfoSphere MDM Server and the security capabilities of the IBM Tivoli Federated Identity Manager can result in a more secure, compliant, and adaptable Master Data Management Server environment.


Download

DescriptionNameSize
Sample files for this articleTFIM-MDMS.zip11.8MB

Resources

Learn

Get products and technologies

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

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. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. 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, Tivoli, Security
ArticleID=372883
ArticleTitle=Understand IBM InfoSphere MDM Server Security, Part 5: Integrating Master Data Management Server with Tivoli Federated Identity Manager
publish-date=02262009