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

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.

Share:

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

Allen ZhangAllen 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.



18 December 2008

Also available in Chinese

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
SAML11Parser is used to parse out user identity

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

  1. 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.
  2. SAML11Parser is chosen to parse the SAML assertion. The parser implements the ISecurityDataParser interface.
  3. 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.
  4. 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:

  1. Create a parser implementing ISecurityDataParser interface
  2. Configure the item /DWLCommonServices/Security/SAML/security_data_parser in the configuration repository with the name of this newlycreated class
  3. Package the new class in the jar and make the jar available to the MDM Server enterprise application
  4. Add the jar name in the MANIFEST.MF file of DWLCommonServices EJB project
  5. 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

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. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management, XML
ArticleID=360106
ArticleTitle=Understanding IBM InfoSphere MDM Server Security, Part 4: Using SAML in MDM Server Security
publish-date=12182008