Specifies the use of security tokens in the headers of inbound and outbound SOAP messages.
Attribute | Description |
---|---|
trust | Taken together, the trust and mode attributes
specify:
When asserted identity is used, messages contain a trust token and an identity token. The trust token is used to check that the sender has the correct permissions to assert identities, and the identity token holds the asserted identity, that is, the user ID under which the request is executed. Use of asserted identity requires that a service provider trusts the requester to make this assertion. In CICS®, the trust relationship is established with security manager surrogate definitions: the requesting identity must have the correct authority to start work on behalf of the asserted identity. The allowable combinations of the these attributes, and their meanings, are described in Table 1 and Table 2. |
mode |
trust | mode | Meaning |
---|---|---|
none | none | No credentials are added to the message |
basic | Invalid combination of attribute values | |
signature | Asserted identity is not used. CICS uses a single X.509 security token which is added to the message, and used to sign the message body. The certificate is identified with the <certificate_label> element, and the algorithm is specified in the <algorithm> element. | |
basic | (any) | Invalid combination of attribute values |
signature | none | Invalid combination of attribute values |
basic | Asserted identity is used. CICS adds the following tokens to the message:
|
|
signature | Invalid combination of attribute values |
trust | mode | Meaning |
---|---|---|
none | none | Inbound messages need not contain any credentials, and CICS does not attempt to extract or verify any credentials that are found in a message. However, CICS will check that any signed elements have been correctly signed. |
basic | Inbound messages must contain a username security token with a password. CICS puts the username in container DFHWS-USERID. | |
signature | Inbound messages must contain an X.509 security token. | |
basic | none | Invalid combination of attribute values |
basic | Inbound messages must use asserted identity:
|
|
signature | Inbound messages must use asserted identity:
|
|
signature | none | Invalid combination of attribute values |
basic | Inbound messages must use asserted identity:
|
|
signature | Inbound messages must use asserted identity:
|
< > : ! =
This element is ignored in a service provider pipeline.
If this element is specified in a service provider pipeline, the handler will not attempt to use any security tokens in the message to determine under which user ID the work will run.
If this element is specified in a service requester pipeline, the handler will not attempt to add to the outbound SOAP message any of the security tokens that are required for authentication.
Algorithm | URI |
---|---|
Digital Signature Algorithm with Secure Hash Algorithm 1 (DSA with SHA1) | http://www.w3.org/2000/09/xmldsig#dsa-sha1 |
Rivest-Shamir-Adleman algorithm with Secure Hash Algorithm 1 (RSA with SHA1) | http://www.w3.org/2000/09/xmldsig#rsa-sha1 |
The DSA with SHA1 signature algorithm is supported on inbound SOAP messages only. If you are using basic authentication on inbound SOAP messages, you must still specify the <algorithm> element.
<authentication trust="signature" mode="basic">
<certificate_label>AUTHCERT03</certificate_label>
<suppress/>
<algorithm>http://www.w3.org/2000/09/xmldsig#dsa-sha1</algorithm>
</authentication>