Understanding IBM InfoSphere MDM Server Security, Part 4: Using SAML in MDM Server Security

Allen Zhang (zhanga@ca.ibm.com), Application Architect, IBM

Allen Zhang is an Application Architect at the IBM Toronto Lab. Allen is one of the original senior developers of WCC, formerly known as DWL Customer. He spearheaded the design and development of the leading CDI product offering in the marketplace. Right now his main focus is on the Party Domain and Product Domain in MDM server development.

Summary: The IBM® InfoSphere™ Master Data Management (MDM) Server allows you to provide your own security data format to integrate into MDM security framework. This article describes how to use Security Assertion Markup Language (SAML) assertions in MDM security.

View more content in this series

Tag this!

Date: 18 Dec 2008
Level: Intermediate
PDF: A4 and Letter (73KB | 10 pages)Get Adobe® Reader®
Activity: 1738 views

Introduction

The IBM InfoSphere MDM Server allows you to pass in your own format of security data and process it within the MDM security framework. This article briefly describes how to use this mechanism to support SAML assertions. It refers back to the Authentication and Identity Assertion Section in the first article of this series, "IBM InfoSphere MDM Server Security Overview."

Tivoli Federated Identity Manager

The Federated Identity Manager can be used to validate tokens through a custom authentication assertion parser, further highlighting the options available for extending the authentication capabilities of the MDM Server. This option will be covered in the next article of this series.

SAML authentication and identity attribute statements are allowed to be passed into the MDM Server using the control object. Within the MDM Server, these SAML assertions are parsed to extract the user identity and its group membership. These statements are retained as XML content to be available for extensions (business proxies, data extensions or behavior extensions).

Define SAML

SAML stands for Security Assertion Markup Language. It is defined in Wikipedia, as "an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee".

Pass the user identity into the MDM Server

MDM Server provides multiple options for clients to invoke a service operation:

Directly on the service controller via RMI/IIOP
As a web service operation via HTTP
Asynchronously via JMS

Regardless of the interface chosen, all invocations eventually end up at the service controller. The service controller acts as an entry point of the request and response framework. A request parser is chosen based on the transaction context to parse out the request business object which contains a control object as the header and a transaction object as the body.

MDM Server requires that a user identity be passed within the control object either as clear text values or as a SAML assertion.

Clear text value

The user identity can be passed in to MDM Server as clear text values using the requesterName and userRoles properties of the control object. A user can have multiple user roles which can be passed in one after another.

Listing 1 shows a sample request for user Jane Doe with requesterName as 'jdoe' and two roles, CallCentAppUser and CstSuppRelL2.

Listing 1. User identity passed in as clear text

<?xml version="1.0" encoding="UTF-8"?>
<TCRMService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="myTCRM.xsd">
	<RequestControl>
		<requestID>123501</requestID>
		<DWLControl>
. . .

			<requesterName>jdoe</requesterName>
			<userRole>CallCentAppUser</userRole>
			<userRole>CstSuppRepL2</userRole>

. . .
		</DWLControl>
	</RequestControl>
	<TCRMTx>
. . .
</TCRMTx>
</TCRMService>

SAML assertion

The user identity can alternatively be passed into the MDM Server as an authentication assertion about the identity and its attributes (roles).

It is the Service Consumer's responsibity to pass in the SAML assertions to the MDM Server. The Service Consumer can either obtain them directly from an Identity Provider, or it can obtain the data in a different form and convert it to a SAML representation.

The SAML assertion statements are passed through the lifecycle of the transaction, allowing them to also be used by extensions. Out of the box, the MDM Server provides the ability to retrieve the requesterName and userRoles in control object out of AuthenticationData. The information derived from the SAML assertions is to take precedence over that passed as immediate attributes of the control object. The requesterName and userRoles properties of the control object have been used in earlier versions of the MDM Server -- before the SAML assertion integration feature was introduced. Even if the user identity are passed in as SAML assertion, the requesterName and userRoles are still transparently used in different areas in MDM Server.

Listing 2 below shows a sample request for user Jane Doe, with identity as 'jdoe' and two roles, CallCentAppUser and CstSuppRelL2. Notice that 'jdoe' is passed in as NameIdentifier in AuthenticationStatement, and the two roles CallCentAppUser and CstSuppRelL2 are passed in as AttributeValue in AttributeStatement.

Listing 2. User identity passed in as a SAML assertion

<?xml version="1.0" encoding="UTF-8"?>
<TCRMService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="myTCRM.xsd">
	<RequestControl>
		<requestID>123501</requestID>
		<DWLControl>
. . .

<authData><![CDATA[


<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
  MajorVersion="1" MinorVersion="1" AssertionID=". . ."
  Issuer=". . ." IssueInstant="2008-11-21T10:35:18.796Z"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="urn:oasis:names:tc:SAML:1.0:assertion
    oasis-sstc-saml-schema-assertion-1.1.xsd">
  <saml:Conditions NotBefore=". . ." NotOnOrAfter=". . .">. . .</saml:Conditions>
  <saml:AuthenticationStatement
    AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
    AuthenticationInstant="2008-11-21T10:35:08.707Z">
    <saml:Subject>
      <saml:NameIdentifier 
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName">
          jdoe
      </saml:NameIdentifier>
    </saml:Subject>
  </saml:AuthenticationStatement>
  <saml:AttributeStatement>
    <saml:Subject>
      <saml:SubjectConfirmation>
        <saml:ConfirmationMethod>. . .</saml:ConfirmationMethod>
      </saml:SubjectConfirmation> 
	  </saml:Subject>
    <saml:Attribute AttributeName="urn:wcc:dir:attribute-def:userRoles"
      AttributeNamespace="urn:wcc:attributeNamespace:uri">
      <saml:AttributeValue>
        CallCentAppUser 
      </saml:AttributeValue>
      <saml:AttributeValue>
        CstSuppRepL2
      </saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

]]></authData>

. . .
		</DWLControl>
	</RequestControl>
	<TCRMTx>
. . .
</TCRMTx>
</TCRMService>

Integrate the SAML assertion into the MDM Server security framework

The MDM Server security framework defines the interface required to parse the authentication assertion included in the transaction requests. The format of the authentication assertion can be externalized. The MDM Server comes with a default authentication assertion parser that supports the use of SAML. By default, SAML 1.1 assertions are supported.

The following class diagram shows the relationship between the SAML assertion, security data parser, and control object.

Figure 1. SAML11parser is used to parse out user identity

The following steps show how to integrate the use of SAML assertions into the MDM Server.

The Request Parser calls method setAuthData() in the control object to set the SAML assertion coming from the value of authData tag in the transaction request.
SAML11Parser is chosen to parse the SAML assertion. The parser implements the ISecurityDataParser interface.
The SAML11Parser populates the AuthenticationData object with the userId and/or userRoles parsed from the SAML assertion. The original SAML assertion is also stored in AuthenticationData.
The control object contains AuthenticationData. Control object, as a transaction context object, is passed through the whole transaction process from beginning to the end. Therefore, the SAML assertion is available to the MDM Server and extensions all through the transaction.

Sample request and response

Listing 3 is an XML sample request for addContract transaction. From the sample request XML, user identity is passed in as SAML assertion.

Listing 3. addContract transaction request, user identity passed as a SAML assertion

<?xml version="1.0" encoding="UTF-8"?>
<TCRMService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="myTCRM.xsd">
	<RequestControl>
        <requestID>123501</requestID>
        <DWLControl>
            <requesterLanguage>100</requesterLanguage>

<authData><![CDATA[
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
  MajorVersion="1" MinorVersion="1" AssertionID=". . ."
  Issuer=". . ." IssueInstant="2008-11-21T10:35:18.796Z"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="urn:oasis:names:tc:SAML:1.0:assertion
    oasis-sstc-saml-schema-assertion-1.1.xsd">
  <saml:Conditions NotBefore=". . ." NotOnOrAfter=". . .">. . .</saml:Conditions>
  <saml:AuthenticationStatement
    AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
    AuthenticationInstant="2008-11-21T10:35:08.707Z">
    <saml:Subject>
      <saml:NameIdentifier 
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName">
          jdoe
      </saml:NameIdentifier>
    </saml:Subject>
  </saml:AuthenticationStatement>
  <saml:AttributeStatement>
    <saml:Subject>
      <saml:SubjectConfirmation>
        <saml:ConfirmationMethod>. . .</saml:ConfirmationMethod>
      </saml:SubjectConfirmation> 
	  </saml:Subject>
    <saml:Attribute AttributeName="urn:wcc:dir:attribute-def:userRoles"
      AttributeNamespace="urn:wcc:attributeNamespace:uri">
      <saml:AttributeValue>
        CallCentAppUser 
      </saml:AttributeValue>
      <saml:AttributeValue>
        CstSuppRepL2
      </saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>
]]></authData>

    	</DWLControl>
    </RequestControl>
    <TCRMTx>
        <TCRMTxType>addContract</TCRMTxType>
        <TCRMTxObject>TCRMContractBObj</TCRMTxObject>
        <TCRMObject>
            <TCRMContractBObj>
                <ContractIdPK/>
                <LineOfBusiness>life ins</LineOfBusiness>
                <CurrencyType>1</CurrencyType>
                <FrequencyModeType>1</FrequencyModeType>
                <BillingType>5</BillingType>
                <PremiumAmount>200</PremiumAmount>
                <NextBillingDate>2009-01-01</NextBillingDate>
                <CurrentCashValueAmount>300.00</CurrentCashValueAmount>
                <BrandName>ul</BrandName>
                <ServiceOrgName>KLM</ServiceOrgName>
                <ServiceProvId>1991</ServiceProvId>
                <BusOrgunitId>444</BusOrgunitId>
            </TCRMContractBObj>
        </TCRMObject>
    </TCRMTx>
</TCRMService>

Listing 4 is a XML sample response for the transaction. From the sample response XML, it shows that the SAML assertion was returned in the response XML.

Listing 4. addContract transaction response, the passed in SAML assertion returns in the response

<?xml version="1.0" encoding="UTF-8"?>
<TCRMService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="tCRMResponse.xsd">
    <ResponseControl>
        <ResultCode>SUCCESS</ResultCode>
        <ServiceTime>125</ServiceTime>
        <DWLControl>
            <requesterLanguage>100</requesterLanguage>
            <requesterLocale>en</requesterLocale>
            <requesterName>jdoe</requesterName>
            <requestID>123501</requestID>
            <userRole>CallCentAppUser</userRole>
            <userRole>CstSuppRepL2</userRole>

<authData><![CDATA[
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
  MajorVersion="1" MinorVersion="1" AssertionID=". . ."
  Issuer=". . ." IssueInstant="2008-11-21T10:35:18.796Z"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="urn:oasis:names:tc:SAML:1.0:assertion
    oasis-sstc-saml-schema-assertion-1.1.xsd">
  <saml:Conditions NotBefore=". . ." NotOnOrAfter=". . .">. . .</saml:Conditions>
  <saml:AuthenticationStatement
    AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
    AuthenticationInstant="2008-11-21T10:35:08.707Z">
    <saml:Subject>
      <saml:NameIdentifier 
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName">
          jdoe
      </saml:NameIdentifier>
    </saml:Subject>
  </saml:AuthenticationStatement>
  <saml:AttributeStatement>
    <saml:Subject>
      <saml:SubjectConfirmation>
        <saml:ConfirmationMethod>. . .</saml:ConfirmationMethod>
      </saml:SubjectConfirmation> 
	  </saml:Subject>
    <saml:Attribute AttributeName="urn:wcc:dir:attribute-def:userRoles"
      AttributeNamespace="urn:wcc:attributeNamespace:uri">
      <saml:AttributeValue>
        CallCentAppUser 
      </saml:AttributeValue>
      <saml:AttributeValue>
        CstSuppRepL2
      </saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>
]]></authData>

    	</DWLControl>
    </ResponseControl>
    <TxResponse>
        <RequestType>addContract</RequestType>
        <TxResult>
            <ResultCode>SUCCESS</ResultCode>
        </TxResult>
        <ResponseObject>
            <TCRMContractBObj>
                <BillingType>5</BillingType>
                <BillingValue>Payroll Deduction</BillingValue>
                <BrandName>ul</BrandName>
                <BusOrgunitId>444</BusOrgunitId>
                <ContractIdPK>938122728173367195</ContractIdPK>
                <ContractLastUpdateDate>2008-11-21 10:35:33.671</ContractLastUpdateDate>
                <ContractLastUpdateTxId>430122728173365655</ContractLastUpdateTxId>
                <ContractLastUpdateUser>jdoe</ContractLastUpdateUser>
                <CurrencyType>1</CurrencyType>
                <CurrencyValue>U.S. Dollar</CurrencyValue>
                <CurrentCashValueAmount>300.00</CurrentCashValueAmount>
                <FrequencyModeType>1</FrequencyModeType>
                <FrequencyModeValue>Annual</FrequencyModeValue>
                <LineOfBusiness>life ins</LineOfBusiness>
                <NextBillingDate>2009-01-01 23:59:59.0</NextBillingDate>
                <PremiumAmount>200</PremiumAmount>
                <ServiceOrgName>KLM</ServiceOrgName>
                <ServiceProvId>1991</ServiceProvId>
                <DWLStatus>
                    <Status>0</Status>
                </DWLStatus>
            </TCRMContractBObj>
        </ResponseObject>
    </TxResponse>
</TCRMService>

Use other security data formats

As described above, security data formats are externalized. Clients pass in their security data within the authData tag as CDATA format. The request parser in the request and response framework leaves the authData as is and set the control object. The customized security data parser parses userId and userRole(s) out of the input authData. The constructor in the request and response framework constructs the response and returns the authData in the original format as passed in the request.

The following steps outline how to use another security data format:

Create a parser implementing ISecurityDataParser interface
Configure the item /DWLCommonServices/Security/SAML/security_data_parser in the configuration repository with the name of this newlycreated class
Package the new class in the jar and make the jar available to the MDM Server enterprise application
Add the jar name in the MANIFEST.MF file of DWLCommonServices EJB project
Restart server to test using the new security data format.

Conclusion

The InfoSphere MDM Server security framework provides a flexible mechanism to allow the clients to pass in the user identity in their own format. Out of the box, SAML assertions are supported in MDM Server, and it is easy to use other security data formats as needed.

Resources

Learn

Understand IBM InfoSphere MDM Server Security, Part 1: Overview of Master Data Management Security" provides an overview of MDM Server's security features and how they work.
Understand IBM InfoSphere MDM Server security, Part 2: Introduction to authentication services" provides detailed configuration and implementation instructions for two scenarios: a Java application client and a Web service application client.
Understanding IBM InfoSphere MDM Server security, Part 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 5: Integrating Master Data Management Server with Tivoli Federated Identity Manager" provides configuration instructions to extend identity propagation capabilities and facilitate client application development.
"Enterprise Master Data Management: An SOA Approach to Managing Core Information": Get an authoritative, vendor-independent, MDM technical reference for practitioners such as architects, technical analysts, consultants, solution designers, and senior IT decision makers.
"IBM InfoSphere MDM Server Information Center" Find a wealth of information on the security features of the product, including detailed configuration information for each of the components described above.
Browse the technology bookstore for books on these and other technical topics.
developerWorks Information Management zone: Learn more about DB2. 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.
Check out developerWorks blogs and get involved in the developerWorks community.

About the author

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=Information Management, XML

ArticleID=360106

ArticleTitle=Understanding IBM InfoSphere MDM Server Security, Part 4: Using SAML in MDM Server Security

publish-date=12182008

author1-email=zhanga@ca.ibm.com

author1-email-cc=

Introduction
Define SAML
Pass the user identity into the MDM Server
Integrate the SAML assertion into the MDM Server security framework
Sample request and response
Use other security data formats
Conclusion
Resources
About the author
Comments

Next steps from IBM

WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.