Objectives

By the end of this article, you should be able to:

• Understand the value of a joint deployment of InfoSphere MDM Server and DataPower SOA Appliances to protect your master data solution
• Demonstrate an ability to create Web Service Proxy and security policies using DataPower SOA Appliances
• Create and deploy a demo scenario showing how a security policy is enforced by DataPower protecting MDM Server

Back to top

Prerequisites

This article is written for IT architects and IT specialists with an interest to learn more about securing an InfoSphere Master Data Management Server deployment. Having any of the following skills is a plus, making it easier to understand this article; however, they are not necessary, as this article introduces all things needed to assure your understanding:

• Experience and skills at J2EE development
• Familiarity with MDM Server Web services
• Familiarity with MDM and security architecture
• Familiarity with DataPower SOA Appliances

Back to top

System requirements

This article is designed to be run in a distributed environment consisting of at least the following systems connected through a TCP/IP network infrastructure:

• Your laptop hosting an MDM Server development environment should have:
  • 2GB memory or more.
  • 10GB free disk space.
  • Any operating system on which InfoSphere MDM Server V8.5 and IBM Rational® Software Architect 7.0 can be installed. This article may also work with previous versions of the product, but the scenario hasn't been tested with them. An MDM Server service is used to show how the call to this service can be protected with the DataPower SOA Appliance.
• The WebSphere DataPower Integration Appliance XI50 as an example device of the DataPower SOA Appliance family. The scenario also works with WebSphere DataPower XML Security Gateway XS40. However, it doesn't work with the WebSphere DataPower XML Accelerator XA35.

Back to top

Introduction

This article has four major areas:

• A brief introduction to Master Data Management (MDM) in general and a discussion of the importance of security for an MDM solution from a high-level architecture perspective, followed by the introduction of the InfoSphere Master Data Management Server (MDM Server) and the DataPower SOA Appliances.
• A description of the demo scenario in this article.
• The first portion of the implementation, showing how the key concept of a Web service proxy can be configured in a DataPower Appliance.
• The implementation of a security policy for security aspects such as authentication and authorization.

The article then concludes with a section on testing.

What is master data management?

A detailed introduction of master data management (MDM) is beyond the scope of this article. This article provides a very short introduction to the theme, explaining why companies that are introducing or have already deployed an MDM system should secure their MDM environment. (For a comprehensive discussion of master data management, see Resources.)

Master data is the core data of an enterprise. It represents entities such as customer, product, account, contract, and location, which are certainly among the most valuable and critical information assets an enterprise has. For example the loss of customer information typically delivers a serious blow to the reputation of a company. Master Data Management is a discipline that consists of:

• Information architecture
• Technology (software products used to deploy an MDM solution)
• Processes and data governance for operating an MDM solution, which includes an organizational change introducing an enterprise-wide horizontal Data Governance Board if not previously established
• People

Thus, MDM is not just a technology question for an enterprise; it affects many other aspects as well. This article introduces a couple of key concepts from the technology perspective. MDM software can be characterized within three key dimensions:

• Master data domains, such as customer, supplier, product, account, contract, or location with cross-domain relationships such as customer-product or product-supplier
• Methods of use:
  • Collaborative method of use characterized by people from different departments or with different job roles collaborating through workflows when working with master data; the New Product Introduction (NPI) process is a typical example
  • Operational method of use characterized by real-time, request-response based interaction with the MDM System; creation or update of customer information is a typical example
  • Analytical method of use characterized by either performing analytics within the MDM System itself (for example, to find out how many new customers where acquired over the last week) or by operationalizing analytical insight from Data Warehouses (for example, derived, aggregated insight into who are the profitable customers) or Identity Analytics systems (for example, discovered hidden non-obvious relationships to fight fraud)
• Implementation styles that provide different levels of value for the master data consumers and have different characteristics regarding deployment complexity:
  • Registry Implementation Style
  • Coexistence Implementation Style
  • Transactional Hub Implementation Style

With an MDM solution, companies address business problems such as lost revenue opportunities, inaccurate revenue reports for customers and products, supply chain inefficiencies, or non-compliance with legal regulations. On the technical side, companies address master data quality issues to many point-to-point connections and similar complexities between systems and security issues for master data.

Master Data Management and security

Introducing MDM in an enterprise creates a paradox. On one side of the coin, the value of the master data is significantly improved by having it with a high-quality, managed, and centralized system, enabling a business to see master data instances with a 360-degree view. However, on the flip side of the coin, the risk of master data compromise is significantly increased. Now an attacker (external or internal) needs to compromise only a single system to get access to all master data. Compare this to when the MDM system was not yet introduced. An attacker would have needed to comprise multiple systems (in large enterprises, likely dozens to a few hundreds of systems) to get access to all master data entities with lower data quality because cleansing, such as standardization and de-duplication, was not yet done.

This increased risk can only be prevented with proper, well-defined security. The good news is that with a centralized system managing master data, such as the MDM Server, there is now a single place to enforce security, reducing costs and complexity. To secure an MDM Server solution, appropriate security measures need to be applied to certain areas, as shown in Figure 1:

The functional areas include, at minimum, the following:

• Firewalls separating networks—internal and external (1)
• Authentication—slave and master LDAP repositories (2)
• Authorization—MDM Server on WebSphere Application Server (3a and 3b)
  • Who can call which service?
  • Who can read/write an attribute of a master data record?
• Audit—ESB and MDM Server on WebSphere Application Server (4)
• Data masking (for example, for master data used in development and test, if regulations require it); not shown in Figure 1
• Encryption of data at rest (for example, backups)—File server (5)

A comprehensive discussion of security architecture for MDM solutions can be found in Chapter 4 of the book Enterprise Master Data Management: An SOA Approach to Managing Core Information (IBM Press, 2008). (See Resources.) The services of MDM Server are available as Web services (in addition to other protocols, such as remote method invocation), which includes not only the data exchanged but also the protocol layer for invocation using SOAP/HTTP or SOAP/HTTPS is an XML structure. The security measures therefore need to include efficient protection against XML attacks. On a high level, there are at least the following four types of XML threats:

• Single- and multiple-message XML Denial of Service (XDoS) using techniques such as recursive elements, megatags, coercive parsing, and XML flood
• Unauthorized access using techniques such as dictionary attack and falsified message
• Date integrity and data confidentiality attacks using mechanisms such as message and data tempering, XPath, XSLT and SQL injection, or message snooping
• System compromise using methods such as memory space breach or XML virus

(The individual techniques mentioned for each of the four threats are not a complete list.) For more details on these attacks see the article "Bill Hines: The (XML) threat is out there..." (developerWorks, March 2006).

The good news is that you can protect MDM Server against many of these threats using the DataPower Appliances, such as the WebSphere DataPower XML Security Gateway XS40, which also works for the scenario detailed in this article.

InfoSphere Master Data Management Server

The IBM InfoSphere Master Data Management Server is a comprehensive, leading-edge solution capable of supporting multiple master data domains, methods of use, and implementation styles supporting all critical business demands for master data management. The MDM Server on a very high level consists of four major pieces:

• The MDM Server itself, which is a pure J2EE application that is deployed on a J2EE application server such as WebSphere Application Server, exploiting horizontal and vertical clustering capabilities provided by WebSphere Application Server for scale-out and high availability
• A relational database engine for persistence, such as IBM DB2® on Linux®, UNIX®, and Windows® or DB2 on z/OS®
• Web-based UIs to perform tasks such as administration and data stewardship
• The MDM Workbench for model-driven development of new services or enhancement of existing services, which is available through the Rational Software Architect tool

The MDM application, which is pure J2EE, is developed using SOA principles and on a very high level consists of the following capabilities:

• An SOA service interface for more then 800 business services supporting the invocation of the business services through various technologies, where Web Services, JMS, CICS, and Remote Method Invocation (RMI) are the most well-known examples.
• An MDM solution that offers more then 800 out-of-the-box business services to support simple and complex business processes on master data such as Cross- and Up-sell or New Product Introduction. The data model is based on a proven, comprehensive data model; and the business services are open and easy to extend using the MDM Workbench.
• MDM business services with stringent data integrity capabilities, such as duplicate prevention built in to enforce master data integrity rules, since master data needs to be maintained with high quality. Furthermore, due to the open and standard-based architecture, the business services can easily consume additional data integrity capabilities if needed from comprehensive information integration platforms such as IBM InfoSphere Information Server.
• Business services that support event-based business rules, such as notifications, since master data has to be actionable to be useful for intelligent exploitation. An example from the banking industry could be notification that a customer might need a mortgage due to the detection of a life event based on a master data change indicating that someone got married.
• Business services that are enabled to implement authorization on service and attribute level, supporting privacy and security aspects of the master data since it needs to secured and governed.
• MDM data governance—functions built into the MDM business services that allow authorization on service and attribute level, thus enabling privacy and security of data.

The Understand IBM InfoSphere MDM Server security article series (developerWorks) provides an introduction to the MDM Server security features, where you can find, for example, how MDM Server interfaces with LDAP providers for authentication in basic security scenarios.

WebSphere DataPower SOA Appliances

The WebSphere DataPower SOA Appliances is a family of products containing:

• WebSphere DataPower XML Security Gateway XS40
• WebSphere DataPower Integration Appliance XI50
• WebSphere DataPower XML Accelerator XA35
• WebSphere DataPower B2B Appliance XB60
• WebSphere DataPower Low Latency Appliance XM70

These products are key elements supporting the comprehensive SOA strategy of IBM, particularly in the ESB area. They represent specialized, easy-to-deploy network hardware appliances for securing and simplifying XML and Web service deployments as part of an SOA implementation. XML processing is hardware-accelerated increasing throughput and processing speed.

With the rapid adoption of SOA, the following key challenges arise:

• Consumability: Complex middleware stacks supporting Web services are not easy to maintain over time due to their interdependencies. Achieving consumability while retaining maintainability is thus not easy.
• Security: As outlined above, Web services are heavy users of XML, and there are many different attack forms known for XML today.
• Performance: From a computational perspective, processing data represented in XML is more expensive then data representations in native data types. Thus, conversion from XML to native data types understood by the CPU costs processing cycles. Putting on top ever-increasing amounts of data that needs to be processed and exchanged between systems adds measurably to the demand for more computing power and speed.

These three challenges are addressed by the DataPower SOA Appliances, and a typical use case is shown in Figure 2. A typical use case includes a De-Militarized Zone (DMZ) to separate external as well as internal clients from the back-end systems. As part of the DMZ, including a Reverse Proxy, firewalls are needed, which could be implemented using the DataPower XS40 appliance, for example. If there is a back-end application that offers an XML-based interface, such as Web services, the DataPower XI 150 can be used.

From a high-level perspective, DataPower SOA Appliances provide the following capabilities:

• Rack-mountable network appliances
• XML/SOAP firewall features and XML security on attribute level with data validation
• Full access control to XML Web services, including service virtualization
• Message brokerage and the ability to bridge important transaction networks to SOAs and ESBs
• Hardware-accelerated high performance, multi-step, wire-speed message processing for XML-, XSLT-, and XPath-based transformations and XML schema validation
• Policy and service-level management for Web services that is centralized
• Full support for many Web services (WS) standards such as SOAP, WSDL, UDDI, WS-Security, SAML, WS-Federation, WS-Trust, WS-SecureConversation, WS-Policy, WS-SecurityPolicy, WS-ReliableMessaging XKMS, Radius, XML Digital Signature, and XML-Encryption
• Support for many transport protocols, such as MQ, SSL, HTTP, HTTPS, and FTP
• Message transformations at wire-speed and high scalability with any-to-any message transformations supporting formats such as text, binary, flat, CICS, CORBA, or EDI

For more details about what the DataPower SOA Appliances can do and how to use them, see Resources.

With this basic understanding of MDM Server and DataPower SOA Appliances, let's summarize where DataPower SOA Appliances can help to protect your MDM solution based on MDM Server. First, it enables you to prevent XML-based attacks. Second, you can deploy them when firewalls are needed to built a DMZ, for example. Third, they provide you the capabilities to implement powerful authentication, authorization, and audit facilities for your MDM solution. Let's now explore this in more detail using a concrete scenario and implementation.

Back to top

The demo scenario

To demonstrate how MDM Server can leverage the security services provided by the DataPower Appliances, let's configure a Web service proxy component that will enforce the authentication and authorization policies on incoming MDM Web service requests. By doing this you can achieve:

• Support for MDM deployments beyond enterprise boundaries by providing first-level authorization and identity mapping in DataPower.
• Support for trusted context, which is a good approach to secure MDM services. You can use DataPower to restrict what MDM services can be called by specific applications asserting a limited set of identities. Today, MDM allows any authorized internal application to call any service with any asserted identity from MDM Server.
• Support for policy-driven authorization. DataPower can enforce authorization policies written in standard languages like eXtensible Access Control Markup Language (XACML) or distributed by other tools like IBM Tivoli Security Policy Manager.
• Deploy an XML-aware firewall in front of MDM Server, which protects MDM Server from XML threats like XDoS, XML flood, and recursive XML elements.

The general flow of the scenario described in this article is shown in Figure 3:

The following list provides a step-by-step description of the scenario:

• Step 1: An MDM Client Application sends an MDM Web service request to the URL of the proxy component configured at DataPower appliance. As a part of the request, the client application sends a user id and password wrapped in the WS-Security Username Token.
• Step 2: The DataPower appliance receives the request, retrieves user credentials from the token, and authenticates the requester on an external, LDAP-compliant directory server.
• Step 3: The DataPower appliance checks if the user is allowed to call the requested service by evaluating the access control policy written in XACML.
• Step 4: The DataPower Appliance maps the id of the user to the identity recognized by MDM Server. Remember that currently MDM Server provides a simple form of authorization using a single J2EE role called ServiceConsumer for all of its services. It makes it possible for the adversary to assert any identity and execute any transaction once he is authenticated with the ServiceConsumer role. To eliminate this weakness, you can hide the actual MDM identity from an MDM Client Application and do the service authorization outside of MDM Server.
• Step 5: If the user is authenticated and authorized to call the MDM service, the DataPower Appliance performs the last step. It creates an LTPA (Lightweight Third-Party Authentication) token and inserts it into the original request in order to authenticate itself at MDM Server as a valid service caller. To generate the token, the DataPower Appliance uses the identity created in Step 4 and encryption keys of the WebSphere Application Server where the targeted MDM Server is deployed.
• Step 6: DataPower sends the MDM Request with injected LTPA token to the back-end MDM Server.
• Step 6': If the user is not listed in the LDAP registry or is not authorized to call the requested MDM Service, then an access denied response is sent to the MDM Client Application.
• Step 7: WebSphere Application Server authenticates the Web service call by verifying the LTPA token.
• Step 8: MDM Server executes the request and returns the response to the DataPower Appliance.
• Step 9: DataPower Appliance passes the response back to the MDM Client Application.

Back to top

Creating a proxy for MDM Server Web services

To create a Web service proxy in the WebSphere DataPower Integration Appliance XI50 used in this article, two steps are necessary. First, you must import the MDM Web services descriptions; and, second, you must configure the proxy. These two steps are described in detail in the next two sections.

Importing the MDM Web services descriptions

The main DataPower component you need to create is the Web Service Proxy, which will process the MDM Web services request before sending them to the back-end MDM Server. But before creating a new Web Service Proxy, you first need to make the services descriptions available to the DataPower Appliance. MDM Server delivers its Web services descriptions in several interrelated WSDL and XSD files. This article describes an example of using a service from the Party domain of MDM Server. This article therefore uses Party services descriptions to build the Web Service Proxy. Figure 4 shows the list of required WSDL and XSD files uploaded to the DataPower Appliance:

• AccessDateValue.xsd
• Business.xsd
• BusinessIntf.xsd
• Common.wsdl
• Common.xsd
• CommonIntf.xsd
• Extensions.xsd
• Hierarchy.xsd
• Party.xsd
• PartyBinding.wsdl
• PartyBusiness.xsd
• PartyIntf.xsd
• PartyPort.wsdl
• PartyService.wsdl

Creating the proxy

To create a new Web Service Proxy using DataPower WebGUI, you need to do the following:

1. Log in to the DataPower WebGUI as a user with access level of a developer for the underlying domain.
2. Click on the Web Service Proxy icon, and then click on the Add button to add a new Web service proxy with the name of your choice (MDM8_WSProxy in the example).
3. Select a WSDL file of the MDM service you want to protect using the proxy. In the example, the WSDL file is local://PartyService.wsdl. When adding a service declaration, turn off the usage of WS-Policy References; otherwise, you might get a warning message when the proxy is created.
4. Add a new or use an existing HTTP Front Side Handler to define which of the DataPower ports should be used for MDM Service requests. In most of the cases, the Web service will be invoked using HTTP. Therefore, your handler must be able to accept HTTP1.1 requests sent using the POST method.
5. Specify the host name and port number of the back-end MDM Server.

The result window of the initial configuration of the Web Service Proxy should look similar to the one shown in Figure 5:

Back to top

Building a security policy for MDM Server

In order to implement the security requirements targeted in this article, you need to create a new Authentication, Authorization, and Audit (AAA) Policy. AAA Policy is a fairly powerful and flexible mechanism for implementing the security requirements. The article example uses AAA Policy to achieve the following:

• Authenticate the incoming MDM requests using external LDAP directory
• Authorize the requests based on the user credentials from the request header and called MDM service, where a policy expressed in XACML is used as a basis for the authorization decision making
• Map the credentials of authorized users to the credentials used by MDM Server
• Replace the security token in the request with the one that can be authenticated by the MDM Server

Using a Web Service proxy configured in DataPower, as shown in Figure 6, policies such as authentication policies or authorization policies can be enforced by DataPower sitting between a client calling MDM services and the InfoSphere MDM Server. Thus, whenever an MDM service is called, DataPower enforces the appropriate security policies before routing the call to MDM Server.

To create an AAA Policy, go to the DataPower objects list and find AAA Policy. Add a new policy with a name of your choice (MDM8_AAAPolicy in the article example).

Back to top

Authentication

The scenario in this article uses the DataPower Appliance to authenticate MDM requests using an LDAP-compliant directory server. To implement this requirement, you should properly configure the identification and authentication of a user identity. For identification, you can use WS-Security Username token embedded into the header of the SOAP message sent by the client application. It is the responsibility of the client application to build a correct WS-Security Username token and include it into the Web service call, which is using an encrypted communication channel such as SSL to protect the password. Listing 1 shows an example of a WS-Security Username token embedded into the MDM Web service request:

        
<soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header>
    <wsse:Security soapenv:mustUnderstand="1"
      xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
                  secext-1.0.xsd">
      <wsse:UsernameToken>
        <wsse:Username>ivan</wsse:Username>
        <wsse:Password
          Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
                token-profile-1.0#PasswordText">secret</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <p388:SearchPerson 
        xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
      <control>
        <requestId>1</requestId>
        <requesterName>ivan</requesterName>
        <requesterLanguage>100</requesterLanguage>
      </control>
      <personSearch>
        <givenNameOne>%</givenNameOne>
        <lastName>Carlos</lastName>
      </personSearch>
    </p388:SearchPerson>
  </soapenv:Body>
</soapenv:Envelope>
    

To make sure that DataPower Appliance accepts this kind of token, you should select the Password-carrying UsernameToken Element from WS-Security Header check box on the Identity tab of the AAA Policy configuration screen. To enable LDAP-based authentication, you need to select the Bind to Specified LDAP Server authentication method on the Authenticate tab of the AAA Policy configuration screen, as shown in Figure 7. You also need to fill in other LDAP parameters (Host, Port, LDAP DN Prefix, LDAP DB Suffix, LDAP Search attribute) specific to the particular LDAP server.

Back to top

Transactional authorization

This section describes how to configure an AAA Policy instance for use by DataPower to do the authorization based on the MDM service name. This functionality is essentially equivalent to the transactional authorization provided by the MDM Server and described in the article "Understanding IBM InfoSphere MDM Server security, Part 3: Using LDAP to implement transaction authorization" (developerWorks, November 2008). But there is an essential difference. The authorization mechanism demonstrated in this article is policy-based. It means that authorization rules can be declared in a policy using standard language like XACML and then distributed to DataPower Appliance for enforcement. Policies can be created manually as one or several XML documents or can be authored using specialized policy management software like IBM Tivoli® Security Policy Manager. This way, both policy management and enforcement can be externalized from MDM Server.

XACML policy for MDM transactional authorization

To implement an XACML-based authorization, you first need to write a policy. XACML is a flexible standard and allows policy authors to build complex access control policies. But in this scenario, you don't need the full power of XACML and will build a fairly simple policy. Independently from the way or format you use to declare the access control policy, you always need to identify two things:

• Access control subject
• Resource governed by the policy

Not surprisingly, in this article's example, the subject of access control is the user calling an MDM service. The example define the called MDM service as the resource (the term MDM transaction is equivalent—that's why it's called a transactional authorization). In the example, we define a simple policy that gives two different access levels to users dmitriy and ivan (see MDM8-tx-policy.xml in the resources.zip file in the Download section). According to the policy, user ivan is allowed to call any transaction and user dmitriy can only call one of the following transactions: SearchPerson, GetPerson, AddPerson, and UpdatePerson. In order to enforce this policy using DataPower Appliance, you need to upload the policy file to the appliance and then create an XACML Policy Decision Point (PDP) component, which will use the policy file to evaluate the make the access control decisions.

Creating an XACML Policy Decision Point

To create an XACML PDP using the WebGUI of DataPower, you need to find XACML Policy Decision Point in the list of DataPower objects. When configuring PDP, make sure that it has a unique name (MDM8_TX_PDP in the example) and uses the policy file you just created. Figure 8 shows an example of XACML PDP configuration:

Authorization in an AAA Policy

After XACML PDP is created, you need to configure an AAA Policy to use it for the authorization. In order to accomplish this, you need to do the following:

1. Select Local Name of Request Element on the Resource tab of the AAA Policy configuration screen. This way you declare that DataPower Appliance must use the name of the MDM service as a resource for the authorization.
2. Select Use XACML Authorization decision as an authorization method on the Authorize tab of the AAA Policy. You also need to select the newly created XACML PDP in the list of Policy Decision Points.

SOAP-to-XACML transformation

Finally, you need to define how Web services requests should be transformed into XACML requests. The XACML standard (see Resourcesfor more information) requires all the authorization requests to be defined according to the XACML request and response schema. Otherwise, the XACML engine, which is embedded into DataPower in this case, does not know how to evaluate the requests. Therefore, you need to define an XSLT stylesheet transforming incoming SOAP packages into XACML requests. In the example, this stylesheet is declared in the file called MDM8-soap-to-xacml.xsl (see MDM8-soap-to-xacml.xsl in the resources.zip file in the Download section). Its implementation is fairly simple and can be easily reused. The interesting detail about this stylesheet is that it uses some variables provided by DataPower XSLT extension.

      
<Subject>
  <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" 
    DataType="http://www.w3.org/2001/XMLSchema#string">
    <AttributeValue>
      <xsl:value-of select="dp:variable('var://context/WSM/identity/username')" />
    </AttributeValue>
  </Attribute>
</Subject>
<Resource>
  <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" 
    DataType="http://www.w3.org/2001/XMLSchema#string">
    <AttributeValue>
      <xsl:value-of select="dp:variable
        ('var://context/WSM/resource/extracted-resource')"/>
    </AttributeValue>
  </Attribute>
</Resource>
    

For example, the XSLT snippet shown in Listing 2, if applied to the MDM request shown on Listing 1 will generate the XACML request provided in Listing 3:

        
<Subject>
  <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" 
    DataType="http://www.w3.org/2001/XMLSchema#string">
    <AttributeValue>dmitriy</AttributeValue>
  </Attribute>
</Subject>
<Resource>
  <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" 
    DataType="http://www.w3.org/2001/XMLSchema#string">
    <AttributeValue>SearchPerson</AttributeValue>
  </Attribute>
</Resource>
    

When XACML PDP sees a request like the one on Listing 3, it applies it to the underlying policy and returns a response, which is basically a simple answer to whether access should be granted or denied. If access is denied, DataPower Appliance sends the access denied response to MDM Client Application and leaves the MDM Server untouched. Pointing AAA Policy to the transformation stylesheet is the last piece of configuration you need to do to implement the transactional authorization, as shown in Figure 9. Select and configure parameters such as the XACML version, as well as the location of the transformation script.

Back to top

Authentication on the back-end MDM Server

The last step in the scenario is the authentication on the back-end MDM Server. One of the goals of this article is to demonstrate that MDM Server security can be totally externalized to an external provider like DataPower. Our DataPower configurations take care of user authentication and policy-based authorization of user requests. But even in this scenario, you need a certain level of security on the side of MDM Server. You need to at least make sure that MDM Server talks to the right security provider. In other words, you need to authenticate the DataPower Appliance at MDM Server. In order to accomplish this, you must do the following:

• Choose the authentication mechanism. Being a compliant J2EE application, MDM Server can leverage the authentication capabilities of the underlying J2EE Application Server infrastructure. The article scenario uses WebSphere Application Server and IBM Lightweight Third-Party Authentication (LTPA) mechanism.
• Configure authentication requirements on MDM Server side. Certain changes must be made to the deployment of MDM Server to make sure that it understands LTPA authentication. (See the LTPA sidebar.)
• Map the identity of requests coming into the DataPower Appliance to identities expected by MDM Server. Identity mapping is not a required approach but is generally recommended in cases when user and service authorization happens outside of the service provider. It allows the separation of the identities used by the back-end server and client applications, which can be considered an extra level of security.
• Configure a DataPower Appliance complying with the authentication mechanism required by the MDM Server. In the case of LTPA and Web services, you need to make sure that DataPower Appliance generates correct LTPA tokens and inserts them into the service request before sending them to the back-end MDM Server.

LTPA-based authentication in MDM Server and WebSphere

In order to make sure that MDM Server accepts LTPA tokens and can authenticate them, some changes to the MDM Server deployment are required. These changes can be made before or after the MDM Server is deployed. The article "Web services security with WebSphere Application Server V6, Part 4" (developerWorks, July 2006) describes how to configure a Web service deployed at WebSphere Application Service to consume LTPA tokens. In the case of MDM Server, configurations are absolutely the same. In the article example, we changed the deployment descriptors only for MDM PartyServices (see the WebSphere binding files ibm-webservices-ext.xmi and ibm-webservices-bnd.xmi in the resources.zip file in the Download section).

Another aspect of LTPA authentication is encryption key sharing. The article example wants DataPower Appliance to generate correct LTPA tokens, and this is only possible if the appliance and WebSphere Application Server share the set of encryption keys. We assured this by exporting the keys from the application server and uploaded them to the DataPower Appliance. To export the LTPA keys from WebSphere Application Server 6.1, you can follow the instructions provided in the "Exporting Lightweight Third Party Authentication keys" section of WebSphere Application Server Information Center (see Resources). When keys are exported, they can be uploaded to the DataPower Appliance as any other file.

Identity mapping

As previously mentioned, identity mapping adds an additional layer of security to the scenario. When client applications and back-end servers use different identity sets and only intermediary security component or ESB knows how to map one to another, it becomes more problematic for malicious users on a client side to circumvent the intermediary and compromise the back-end server.

One possibility to implement identity mapping in a DataPower Appliance is to create a new AAA info file and attach it to the AAA Policy. The AAA info file is an XML document including different aspects of AAA policy configuration. Developers do not need to know the format of the file because all the changes can be made using DataPower WebGUI. The article example uses AAA info file to define the identity mapping rules. In order to create an AAA info file, go to the MapCredentials tab of the AAA policy configuration screen, and select AAA Info File as a method for the mapping. Then click on the + (plus/add) button and go through a set of screens defining different aspects of AAA policy. AAA info file can be used not only for identity mapping, but also for authentication and authorization. The article example does not require that. The only configuration needed is to declare the incoming identities (see Figure 10) and how they should be mapped (see Figure 11). Notice that as a mapping target, we use the identity used by the IBM WebSphere Application Server, and it will be encrypted into the LTPA token. You can find an example of the AAA Info File used in this scenario included with the article download (see MDM8_AAAInfoFile.xml in the resources.zip file).

LTPA token generation

After identity mapping is configured and MDM Server is ready to consume LTPA tokens, there is one last step to do, which is to configure DataPower Appliance to generate LTPA tokens and insert them in all the incoming MDM Web service calls. This can be done on the PostProcessing tab of the AAA Policy configuration screen, as shown in Figure 12. In order to accomplish this, you need to perform the following steps:

1. Select on for Generate LTPA Token.
2. For the LTPA Token version, select WebSphere version 2 for IBM WebSphere Application Server 6.1 and later.
3. Specify the LTPA key file, exported previously from the WebSphere Application Server.
4. Enter the LTPA password, which must be the same password used to export the keys from WebSphere Application Server.
5. Select on for Wrap Token in a WS-Security Security Header. If this option is on, DataPower will wrap LTPA token into WS-Security BinarySecurity Token and insert it in a Web service request. This option is critical in this scenario. Because of the changes to the MDM Server configurations, it will only accept requests with embedded LTPA tokens.

Back to top

Attaching the security policy to the proxy component

After AAA Policy is created, it can be attached to one or many of the Web Service Proxy components. To do this, go to the Web Service Proxy configuration screen and drag and drop a new AAA Action to the request rule of your proxy. The request rule configuration can be found on the Policy tab of the proxy configuration screen, as shown in Figure 13. According to this configuration, DataPower Appliance will enforce the AAA Policy for each and every incoming Web service request.

Back to top

Test run

To demonstrate the security capabilities of the demo solution, let's execute several MDM Web service calls and analyze the results. Let's first take a look at the request shown in Listing 1. As you can see, this request contains user credentials of user named ivan. Listing 4 shows the interim SOAP package, which is constructed by DataPower Appliance after enforcing the security policies and before sending it to the back-end MDM Server. You can see that it contains the embedded LTPA token, instead of the original Username token..

        
<soapenv:Envelope
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse=
    "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <wsse:BinarySecurityToken 
          wsu:Id="SecurityToken-ff960367-3c49-4913-b0a7-9f8358943297" 
          EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
          message-security-1.0#Base64Binary" 
          ValueType="wsst:LTPA" 
          xmlns:wsst="http://www.ibm.com/websphere/appserver/tokentype/5.0.2" 
          xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
          wssecurity-utility-1.0.xsd">
          Ac1aDJ17IJSJ5aaaG390MM6Ys9eOzxiVmaXDVA5pe3qV89602u3Ssmraa3oykgNzHhvEOZa2GHbRMj2
          K3RJWLuD8KB3eH1s8uMLfvNo9hS4Yj9hFKzC8oi1vzTdEwhwMcde6VXXXH+SsZJ4p0YpEKClg7rcukb
          feJ+/cOjfZNkcWwCNtj9TginFPWx5iwDBRZ8fmX+8LHd3ZEepS8U1+WZ2CpYqNDYZr+6h19lINyDvBj
          hiOStn6bKbAf+u/mHJ7Yd2ISoZHfXnyQ2Nr60FcWuv7uvbc+g5JJ9ZjQhFqLtWcyd4/5ehRoOIXA3tT
          x1Vc/7ajy11SKwwaNrOzsNtyEl2qoOglAeTDYR8LZgjW7WSln+kwdM+ZN3jrfgC0FClw
      </wsse:BinarySecurityToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <p388:SearchPerson 
        xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
      <control>
        <requestId>1</requestId>
        <requesterName>ivan</requesterName>
        <requesterLanguage>100</requesterLanguage>
      </control>
      <personSearch>
        <givenNameOne>%</givenNameOne>
        <lastName>Carlos</lastName>
      </personSearch>
    </p388:SearchPerson>
  </soapenv:Body>
</soapenv:Envelope>
            

Listing 5 shows the final result of the execution of this MDM request:

        <
<soapenv:Envelope
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header />
  <soapenv:Body>
    <p388:SearchPersonResponse 
             xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
      <result>
        <control>
          <requestId>1</requestId>
          <requesterName>ivan</requesterName>
          <requesterLanguage>100</requesterLanguage>
          <requesterLocale>en</requesterLocale>
        </control>
        <serviceTime>P0Y0M0DT0H0M7.203S</serviceTime>
        <status>
          <processingStatus code="0">SUCCESS</processingStatus>
        </status>
        <searchResult>...</searchResult>
        <searchResult>...</searchResult>
      </result>
    </p388:SearchPersonResponse>
  </soapenv:Body>
</soapenv:Envelope>
    

Let's, for the sake of experiment, change the Username token in the initial request to the one shown in Listing 6 (user miguel is not authorized to call any transactions by our XACML policy):

        
<wsse:UsernameToken>
  <wsse:Username>miguel</wsse:Username>
  <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
                       token-profile-1.0#PasswordText">secret</wsse:Password>
</wsse:UsernameToken>
            

You will get a failure response, as shown in Listing 7, which means the authorization policy was successfully enforced:

        
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Body>
    <env:Fault>
      <faultcode>env:Client</faultcode>
      <faultstring>Rejected by policy. (from client)</faultstring>
    </env:Fault>
  </env:Body>
</env:Envelope>

      

Back to top

Conclusion

This article showed you how the DataPower SOA Appliance can be used and configured to protect the MDM Server managing the core business entities—the master data in an SOA environment. With the leading edge DataPower SOA Appliance, it is easy to protect your MDM Server deployment and appropriately apply authentication, authorization, and audit policies for consistent enforcement.

Acknowledgment

We would like to thank our colleague and mentor Ivan Milman for his suggestions and feedback on this article.

Back to top

Download

Information about download methods

Resources

Learn

• Enterprise Master Data Management: An SOA Approach to Managing Core Information (IBM Press, 2008): This book provides an authoritative, vendor-independent MDM technical reference for practitioners: architects, technical analysts, consultants, solution designers, and senior IT decision makers.
  
  
• "Comment lines: Bill Hines: The (XML) threat is out there..." (developerWorks, March 2006): New technologies mean new types of attacks on systems and data. Get to know what kinds of attacks are possible, and start protecting your environment from them.
  
  
• InfoSphere Master Data Management Server Information Center: Find detailed instructions on how to complete the tasks required to establish and maintain your master data information using MDM Server.
  
  
• InfoSphere Master Data Management Server: Get more details on the MDM Server offering and MDM solutions.
  
  
• Understand IBM InfoSphere MDM Server Security series (developerWorks):
  • "Understand IBM InfoSphere MDM Server Security, Part 1: Overview of Master Data Management Security" (developerWorks, September 2008): Get an overview of MDM Server's security features and how they work.
  • "Understand IBM InfoSphere MDM Server security, Part 2: Introduction to authentication services" (developerWorks, November 2008): Follow detailed configuration and implementation instructions for two scenarios: a Java application client and a Web service application client.
  • "Understand IBM InfoSphere MDM Server security, Part 3: Using LDAP to implement transaction authorization" (developerWorks, November 2008): Follow an example showing how to implement a transaction authorization provider using an LDAP server.
  • "Understand IBM InfoSphere MDM Server Security, Part 4: Using SAML in MDM Server" (developerWorks, December 2008): Get an overview of identity propagation in MDM Server.
  • "Understand IBM InfoSphere MDM Server Security, Part 5: Integrating Master Data Management Server with Tivoli Federated Identity Manager" (developerWorks, February 2009): Get an overview of how InfoSphere MDM Server and Tivoli Federated Identity Manager can be jointly deployed to deliver improved security.
  
  
• DataPower SOA Appliances: Find more details on the DataPower offerings and solutions.
  
  
• "WebSphere DataPower SOA Appliance: The XML Management Interface" (IBM, September 2008): Get details of the DataPower technologies from an implementation perspective (Redpaper publication).
  
  
• "IBM WebSphere DataPower SOA Appliances Part I: Overview and Getting Started" (IBM, April 2008): Get an introduction to DataPower appliances (Redpaper publication).
  
  
• "IBM WebSphere DataPower SOA Appliances Part II: Authentication and Authorization" (IBM, April 2008): Follow a detailed discussion on authentication and authorization with DataPower (Redpaper publication).
  
  
• "IBM WebSphere DataPower SOA Appliances Part III: XML Security Guide" (IBM, April 2008): Get an introduction to XML security from a DataPower perspective (Redpaper publication).
  
  
• "IBM WebSphere DataPower SOA Appliances Part IV: Management and Governance" (IBM, April 2008): Understand governance and management aspects (Redpaper publication).
  
  
• XACML Standard: Get more information about XACML Standard.
  
  
• "IBM WebSphere Developer Technical Journal: Web services security with WebSphere Application Server V6, Part 4" (developerWorks, July 2006): Learn how to use the Lightweight Third Party Authentication (LTPA) token to secure a Web service using WebSphere Application Server V6.
  
  
• WebSphere Application Server Information Center: Find the documentation for various editions of the application server.
  • Exporting Lightweight Third Party Authentication keys: Learn how to export the LTPA keys from WebSphere Application Server 6.1.
  
  
• 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.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Participate in the discussion on MDM Server and on MDM Workbench.
  
  
• Participate in developerWorks blogs and get involved in the My developerWorks community; with your personal profile and custom home page, you can tailor developerWorks to your interests and interact with other developerWorks users.
  
  

About the authors

Dmitriy Fot is working as a software engineer in the Advanced Architecture for Information Management department in Austin, Texas. Dmitriy has worked in the area of Master Data Management since he joined the Center of Excellence for MDM team based in the IBM Boeblingen Lab in Germany. His experience includes numerous integration projects involving MDM Server and other IBM and non-IBM systems. After joining IBM Austin Lab, Dmitriy changed his focus towards information security and participated in several projects in the area of access control, policy-based security, and database security.

Martin Oberhofer joined IBM in the IBM Silicon Valley Labs in the USA at the beginning of 2002 as a software engineer. In an architect role for Enterprise Information Integration and Master Data Management, he currently works with large enterprises around the globe shaping the information architecture foundation, solving information-intense business problems. His areas of expertise are Master Data Management, Enterprise Information Integration, database technologies, Java development, and IT system integration. The synchronization and distribution of master data into the operational IT environment is his focus area, particularly master data exchange with SAP application systems. He provides Enterprise Information Architecture and Solution workshops to customers and major system integrators. In a Lab Advocate role he provides expert advise for Information Management to very large IBM clients. He holds a Masters degree in mathematics from the University of Constance, Germany.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Objectives
• Prerequisites
• System requirements
• Introduction
• The demo scenario
• Creating a proxy for MDM Server Web services
• Building a security policy for MDM Server
• Authentication
• Transactional authorization
• Authentication on the back-end MDM Server
• Attaching the security policy to the proxy component
• Test run
• Conclusion
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into Information Management on developerWorks

Try IBM Cognos 8 Business Intelligence

Use reports, analysis, dashboards and scorecards to monitor business performance, analyze trends and measure results.

Special offers