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).
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.
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
The steps of the flow are as follows:
- The AAP passes the authData element, which contains the LTPA token, to the TfimMdmIdentityMediator class (mediator class).
- The mediator class extracts the client component of the authData element (in this case the LTPA token).
- The mediator class creates a WS-Trust Request Security Token message that includes the extracted element and sends the request to the configured STS.
- The STS validates the received security token.
- STS applies any required identity mapping (group retrieval, attribute retrieval).
- STS issues a SAML 1.1 Assertion in the format that the MDM Server supports.
- STS returns the SAML Assertion.
- 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.
- 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.
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
- Copy com.ibm.tivoli.fimmdm.jar into the MDM-App.ear directory.
- 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.
- Copy tfim-mdm.properties into the lib/ext directory for WebSphere Application
The default directory for Linux is: /opt/ibm/websphere/AppServer/lib/ext
- 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.
- From your Web browser, log in to the Administration application:
- Create a group:
- Go to the Add User Group page: Security -> User Groups.
- Click the Add button.
- At the Add User Group page, enter a User Group Name and optionally a Description.
- Click the Submit button.
Figure 2. Add User Group page
- Associate the transactions to be tested with the
group you just created. For this example, use the searchPerson transaction.
- Go to the Transaction Association page: Security -> Transaction Associations.
- Select the group from the Select User Group to Assign Transactions menu and click the GO button.
Figure 3. Transaction Association page
- On the Assign Transaction to a User Group page, select searchPerson from the Select Transaction to Assign menu and click the ADD button.
- After the page refreshes, click the SUBMIT button.
Figure 4. 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.
- Start the MDM Server management agent.
- Navigate to the management agent directory located at:
MDM Home Directory/ManagementAgent
- Run the startAgent.sh script.
- Navigate to the management agent directory located at:
- Start the MDM Server Management Console.
- Navigate to the Management Console directory located at:
MDM Home Directory/ManagementConsole
- Run the console.sh script.
- Navigate to the Management Console directory located at:
Follow the menus to change parameter values.
- 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
- 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.
- From your Web browser, open the TFIM management console:
- Go to the Trust Service Chains panel: Tivoli Federated Identity Manager -> Configure Trust Service -> Trust Service Chains.
Click the Create... button.
Figure 5. Trust Service Chains panel
- On the Introduction panel of the Trust Service Chain Mapping Wizard, click the
Figure 6. Trust Service Chain Mapping Wizard — Introduction
- 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
- 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.
- 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
- On the Chain Assembly panel, construct a chain with the following modules:
Figure 9. Trust Service Chain Mapping Wizard — Chain Assembly
- Use the LTPA Token Module Configuration panel to configure the STSLTPATokenModule
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
- Use the Default Map Module panel to configure the STSMapDefault module.
Select the XSLT file you want to use for
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
- 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
- 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
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.
- Extract the SearchPersonWithLTPA.xml file from the TFIM-MDMS.zip file in Download.
- Edit SearchPersonWithLTPA.xml and make any necessary modifications to match your environment, including updating the BinarySecurityToken with a fresh LTPA token.
- Copy the SearchPersonWithLTPA.xml file
into the following directory:
MDM Install Directory/IVT/xml/
(for example, /opt/ibm/infosphere/MDMServer/IVT/xml)
- Navigate to the IVT directory located at:
MDM Install Directory/IVT
- Run the verify.sh (or verify.bat for Windows®) script to initiate a test.
- 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.
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.
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.
|Sample files for this article||TFIM-MDMS.zip||11.8MB|
- 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 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.
- 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 decision makers.
- IBM InfoSphere Master Data Management Server Information Center contains documentation for MDM Server
- Tivoli Federated Identity Manager Information Center contains documentation for TFIM.
- Visit the InfoSphere area on developerWorks to read articles and tutorials and connect to other resources to expand your InfoSphere skills.
- developerWorks Information Management zone: Learn more about Information Management. 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.
- Participate in the discussion forum.
- Check out developerWorks blogs and get involved in the developerWorks community.
Dig deeper into Information management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.