Security support in SOAP Gateway

SOAP Gateway supports HTTPS communication with its clients, and SSL communications with its host, IMS Connect.

You can configure SOAP Gateway with standards that are specified by the US Department of Commerce National Institute of Standards and Technology (NIST) to define security requirements for encryption.
  • Federal Information Processing Standards (FIPS) 140-2 requires that the Transport Layer Security (TLS) protocol and the cryptographic modules are certified.
  • SP800-131a requires stronger cryptographic algorithms and key lengths that are used in FIPS 140-2 cryptographic modules.

Server authentication, client authentication, and basic authentication

When an IMS application is enabled as a web service provider or a consumer, SOAP Gateway supports both server authentication and client authentication.
  • Server authentication is the provision of server authentication information (digital certificate), from the server to the client, that binds the server identify to subsequent communications.
  • Client authentication is the provision of authentication information from the client to the server. Client authentication is also referred to as mutual authentication, because server authentication is required in order to support client authentication.

Certificates are exchanged at the transport level to establish trust before the connection is established or a web service is invoked.

For the web service consumer scenario, SOAP Gateway supports basic authentication where the server that hosts the web service requires SOAP Gateway, the client, to have appropriate basic authentication credentials in order to call a service.

WS-Security and custom authentication modules for the web service provider scenario

For the provider scenario, SOAP Gateway supports authentication of users on a per-web service or per-message basis. When the user ID and password information is provided by the connection bundle, the authentication is performed on a per-web service basis. All requests use the same user ID to access IMS. Security certificates can be sent at the transport level for server authentication and client authentication. When users are authenticated on a per-message basis, user ID and password information is enclosed as tokens in the WS-Security header in each message. Requests might come from different user IDs. This feature is known as web service security or WS-Security.

SOAP Gateway supports the following security tokens for WS-Security:
  • UsernameToken Profile 1.0 user name tokens
  • Security Assertion Markup Language (SAML) 1.1 and 2.0 unsigned sender-vouches tokens
  • SAML 1.1 and 2.0 signed sender-vouches tokens with two trust types:
    Trust any
    Any valid security certificate in the SOAP header is allowed.
    Trust one
    The security certificate in the SOAP header must be configured with the server truststore path and password.

Only one security token type is allowed per web service. When WS-Security is enabled, you can also provide your own custom authentication module to perform additional checking by using a Java™ Authentication and Authorization Service (JAAS) module.

WS-Security and custom authentication modules for the synchronous callout scenario

For the synchronous callout scenario, SOAP Gateway supports callout requests to web services that require authentication of users on a per-web service or per-message basis. When users are authenticated on a per-message basis, user ID is enclosed as a token in the WS-Security header in each message. SOAP Gateway supports the following for WS-Security security tokens for the synchronous callout scenario:
  • SAML 1.1 unsigned sender-vouches tokens
  • SAML 2.0 unsigned sender-vouches tokens

Only one security token type is allowed per callout request. When WS-Security is enabled, you can also provide your own custom authentication module to perform additional checking by using a JAAS module.