Support for web services security (WS-Security)

Web services security support provides dynamic authentication of users on a per-message basis.

When WS-Security is enabled for a web service, SOAP Gateway extracts the user information from the WS-Security header and propagates the information to IMS. When WS-Security is not enabled, user ID and password information is provided by the connection bundle on a per-web service basis.

You can enable the WS-Security feature by using the SOAP Gateway management utility. The information that you specify in the SOAP Gateway management utility overrides the WS-Security setting in the WSDL file that is generated by Rational® Developer for System z®.

Dynamic authentication compared to static authentication

When WS-Security is enabled for a web service, user identity is dynamically determined at run time on a per-message basis. When WS-Security is not enabled for a web service, the user identity information is specified in the web service connection bundle. User information is statically defined at deployment time on a per-web service basis. All clients that access the web service use the same user identity and password to be authenticated by IMS Connect.

WS-Security through secured transport

SOAP Gateway accepts only secured HTTPS requests when WS-Security is enabled for a web service. Because the user information is in clear text, you must configure Secure Sockets Layer (SSL) security on both the web service client and the server to provide data encryption over TCP/IP.

SOAP Gateway supports security tokens in the WS-Security header as part of the SOAP request message. SOAP Gateway extracts the user identity information (User ID) and sends it over to IMS Connect, which propagates the information to IMS. The WS-Security token is also accessible by custom authentication modules, if such a module is enabled.

UsernameToken Profile Version 1.0

For a user name security token, a SOAP Gateway client must provide the user ID and password to SOAP Gateway in the SOAP message security header. SOAP Gateway extracts this user ID and password from the SOAP message and passes them with the payload data to IMS Connect for authentication.

Server authentication or client authentication is recommended. Otherwise the user ID and passsword are transmitted in clear text.

Security Assertion Markup Language (SAML) Version 1.1 and Version 2.0 sender-vouches tokens

SAML is an XML-based OASIS standard for exchanging user identity and security attribute information. The sender-vouches confirmation method is used when a server (SOAP Gateway) needs to further propagate the client identity and attributes on behalf of the client (to IMS Connect and OTMA). An attesting entity uses the sender-vouches confirmation method to assert that it is acting on behalf of the subject of the SAML statements attributed with the sender-vouches SubjectConfirmation element.

SAML support requires an SSL connection with client authentication to enable sender-vouches security tokens. You must configure client authentication to use the SAML sender-vouches confirmation method. The SOAP response message does not carry any security token information.

A SAML assertion is a sender-vouches assertion if it includes the sender-vouches <saml:ConfirmationMethod> element, as defined in the OASIS Web Services Security specifications. A SAML Version 1.1 sender-vouches assertion must contain the following SubjectConfirmation element:

<saml:SubjectConfirmation>
  	 <saml:ConfirmationMethod>
  		urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
 	 </saml:ConfirmationMethod>
</saml:SubjectConfirmation>

A SAML Version 2.0 sender-vouches assertion must contain the following SubjectConfirmation element:

<saml:SubjectConfirmation
  	 Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches">
</saml:SubjectConfirmation>

A SAML token can be signed or unsigned:

When the token is unsigned, the request contains a minimal sender-vouches SAML assertion with no optional elements included. There are no signatures or certificates required. The response does not contain a security header.
When the token is signed, the request contains a sender-vouches SAML assertion. The assertion element is signed. A reference to the certificate used to verify the signature is provided in the header. The response does not contain a security header.