A X.509 V3 public key certificate is required for X.509 based authentication for an outbound GWWS SOAP message. The public key certificate used for this purpose can be configured as either one certificate for all the requests targeted for the same Web Service or per request invocation if Tuxedo SECURITY is set at USER_AUTH or higher. In the later case, the certificate must have the same name as the Tuxedo user identification or the mapped remote user name if identity mapping plug-in is installed.

The configured X.509 public key certificate will be used for:

1. Mutual Authentication for Transport Layer security (that is,TLS).
2. Message signing.
3. Part of the SOAP message that can be used to authenticate user at message-level (as oppose to transport layer).

Whether all 3 tasks will be performed or only partial of the 3 tasks depends on the WS policy used by the Web Service.

Since message encryption will not be supported as it is not required it is recommended to use TLS as the preferred transport mechanism to protect the integrity and privacy of the message. The X.509 Public Key certificate used for TLS can be different from the one used for signing depends on how user configure it.

When GWWS received a request from client it will process the message, optionally it will sign the message and attach the certificate as the binary security token to the SOAP request message if WS policy requires it; and then send the request to remote Web Service through TLS. Depends on the WS policy this TLS connection can be either one-way or two-way TLS.

During the TLS connection establishing process the application server will validate the client certificate if the connection is two-way TLS; and forward the request to Web Service.

When Web Service received the request it will validate the certificate, verify the signature if Web Service requires it. If the request is good it will send reply back. The reply send back by Web Service may be also signed depends on WS policy.

When GWWS received the reply it will forward reply back to actual SALT client. In the case that reply is signed GWWS will validate the certificate and verify the signature before forwarding the reply back to SALT client.

<S11:Envelope xmlns:S11="…" >
<S11:Header>
<wsse:Security xmlns:wsse="…" xmlns:wsu="…">
<wsse:BinarySecurityToken
wsu:id="binarytoken"
ValueType="wsse:X590v3"
EncodingType="wsse:Base64Binary">
MIIEzzCCA9CgAwIBAgIQEmtJZc0…
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:Reference URI="#body">…</ds:Reference>
<ds:Reference URI="#binarytoken">…</ds:Reference>
</ds:SignedInfo>
…
</ds:Signature>
</wsse:Security>
</S11:Header>
<S11:Body wsu:Id="body" xmlns:wsu="…">
…
</S11:Body>
</S11:Envelope>

For user to successfully access Web Service through GWWS user must configure a valid client certificate and private key that is accessible to GWWS at runtime. This certificate and private key can be used by transport level security or message level security, or even both depend on Web Service' requirement.

Currently Tuxedo SALT only support single certificate which is configured through the "System" element in the deployment descriptor, with this limitation all the requests going through different instances of GWWS gateway 1 will use same certificate to establish TLS connection. Invariably, in the eyes of the Web Service they all come from the same user; thus same access privilege. This new feature will remove this constraint and make it possible to use different certificate to represent different client or gateway.

SALT configuration consists of a deployment descriptor (DEP) and multiple web service definition files (WSDF). This new feature will use "Property" to configure default user identity to be used for this purpose, or to instruct GWWS to how to use filters/mappers to map Tuxedo user identity to a X.509 certificate. The "Property" which is used for configuration is an XML element that is available as configurable child element to both "GWInstance" and "Service". "GWInstance" is configured in SALT deployment descriptor while "Service" is configured in SALT web service definition file.

When a Web Service' WS-Security policy requires message level security, GWWS will use the private key to perform message signing, and attach the certificate to the SOAP message as Binary Security Token to be used by target Web Service to validate the message and authenticate the user. Otherwise, it will only use the certificate and private key to create a secured transport layer connection, i.e. TLS.

• Certificate Sources
  
• Properties