Header Based Authentication for webservices within MII

[Former Member]

MII has the Webservice action block to communicate with Web services. Currently the authentication mechanism supported by the action block are:

1. Basic authentication
2. Certificate authentication
3. SSO authentication

In other words MII authentication is currently SOAP specification 1.0 compliant.

Support for header based authentication

Web Services Security (WS-Security, WSS) is an extension to SOAP to apply security to Web services. The WS-Security specification defines a new SOAP header. The element definition is as below:

<xs:element name="Security">

    <xs:complexType>

        <xs:sequence>

        <xs:any processContents="lax"

            minOccurs="0" maxOccurs="unbounded">

        </xs:any>

        </xs:sequence>

        <xs:anyAttribute processContents="lax"/>

    </xs:complexType>

  </xs:element>

Details about the specification can be found here:

  https://www.oasis-open.org/committees/download.php/13392/wss-v1.1-spec-pr-UsernameTokenProfile-01.ht...

The Security header element allows any XML element or attribute to live within it. This allows the header to adapt to whatever security mechanisms the application needs. The Security element is the child element of <soap:Header> element which in turn is an optional child of <soap:Envelope> element.

MII does not include the <soap:Header> element within the request it creates by default. A sample MII request to a webservice looks like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

-<soap:Body>-

<GetProductionPerformance xmlns="urn:Proficy:ProductionPerformance:2009

-<ApplicationArea xmlns="http://www.wbf.org/xml/B2MML-V0401">

<BODID>

<Value/>

<schemeAgencyID/>

<schemeAgencyName/>

<schemeDataURI/>

<schemeID/>

<schemeName/>

<schemeURI/><

schemeVersionID/>

</BODID>-

<CreationDateTime><Value>2000-01-01T00:00:00</Value>

<format/>

</CreationDateTime>

</soap:Body>

</soap:Envelope>

MII (as of MII 14.0 Sp05 patch 3) include an option for the user to specify whether he wants to send across authentication information as request properties or an SOAP header. The UI in the configuration dialog will now include a checkbox:

If the user selects this checkbox, the request XML would be modified to include a <SOAP:header> element which will include authentication information. The sample request would look like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

-<soap:Body>-

-<soap:Header>

-<security:Security xmlns:security="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">

-<security:UsernameToken>

<security:Username>I053669</security:Username>

<security:Password>abcd1234</security:Password>

</security:UsernameToken>

</security:Security>

</soap:Header>

<GetProductionPerformance xmlns="urn:Proficy:ProductionPerformance:2009

-<ApplicationArea xmlns="http://www.wbf.org/xml/B2MML-V0401">

<BODID>

<Value/>

<schemeAgencyID/>

<schemeAgencyName/>

<schemeDataURI/>

<schemeID/>

<schemeName/>

<schemeURI/><

schemeVersionID/>

</BODID>-

<CreationDateTime><Value>2000-01-01T00:00:00</Value>

<format/>

</CreationDateTime>

</soap:Envelope>

</soap:Body>

</soap:Envelope>

If the check box is selected, the credentials are not set in request properties. They are simply added to SOAP header. The user id and password can be specified as credential alias or through the link editor.

In case the user does not want to use header based authentication mechanism, he can simply leave the check box unchecked.

This makes MII partially SOAP 1.1 specification compliant as far as request XML properties are concerned. If a user wishes to use this feature he has to make sure that the server who has exposed the web service does not expect BASIC authentication in addition to header based authentication.

Also, for the purpose of security it is best that this feature be used in case the communication channel is secured via SSL. In other words the request should ideally be sent over https rather than http.