The <authentication>
element
Specifies the use of security tokens in the headers of inbound and outbound SOAP messages.
Used in:
- Service provider
- Service requester
Contained by:
Attributes:
Attribute | Description |
---|---|
trust and mode | 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. The identity token holds the asserted identity, that is, the user ID under which the request is run. 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 these attributes, and their meanings, are described in Table 1 and Table 2. |
trust | mode | Meaning |
---|---|---|
none | none | No credentials are added to the message |
none | basic | Invalid combination of attribute values |
none | 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. |
blind | none | Invalid combination of attribute values |
blind | basic | Asserted identity is not used. CICS adds an identity token to the message, but does not provide a trust token. The identity token is a user name with no password. The user ID placed in the identity token is the contents of the DFHWS-USERID container (which, by default, contains the running task's user ID). |
blind | signature | Invalid combination of attribute values |
basic | none | Invalid combination of attribute values |
basic | basic | Invalid combination of attribute values |
basic | signature | Invalid combination of attribute values |
signature | none | Invalid combination of attribute values |
signature | basic | Asserted identity is used. CICS adds the following tokens to the message:
<certificate_label> .
The user ID placed in the identity token is the contents of the DFHWS-USERID
container (which, by default, contains the running task's user ID). |
signature | 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 checks that any signed elements are correctly signed. |
none | basic | Inbound messages must contain a user name security token with a password. CICS puts the user name in the DFHWS-USERID container. |
none | basic-ICRX | Invalid combination of attribute values |
none | basic-kerberos | Invalid combination of attribute values |
none | signature | Inbound messages must contain an X.509 security token that has been used to sign the message body. |
blind | none | Invalid combination of attribute values |
blind | basic | Inbound messages must contain an identity token, where the identity token contains a user ID and optionally a password. CICS puts the user ID in the DFHWS-USERID container. If no password is included, CICS uses the user ID without verifying it. If a password is included, the security handler DFHWSSE1 verifies it. |
blind | basic-ICRX | Inbound messages must contain an ICRX identity token. CICS resolves the identity, puts the user ID in the DFHWS-USERID container, and puts the ICRX in container DFHWS-ICRX. Authentication, if required, uses client-certified SSL or another security protocol. |
blind | basic-kerberos | Invalid combination of attribute values |
blind | signature | Inbound messages must contain an identity token, where the identity token is the first X.509 certificate in the SOAP message header. The certificate does not need to have signed the message. The security handler extracts the matching user ID and places it in the DFHWS-USERID container. |
basic | none | Invalid combination of attribute values |
basic | basic | Inbound messages must use asserted identity:
|
basic | basic-ICRX | Inbound messages must use asserted identity:
|
basic | basic-kerberos | Inbound messages must use asserted identity. One token is required, a Kerberos Version 5 token with one of the following format types:
|
basic | signature | Inbound messages must use asserted identity:
|
signature | none | Invalid combination of attribute values |
signature | basic | Inbound messages must use asserted identity:
|
signature | basic-ICRX | Inbound messages must use asserted identity.
|
signature | basic-kerberos | Invalid combination of attribute values |
signature | signature | Inbound messages must use asserted identity:
|
- The combinations of the trust and mode attribute values are checked when the PIPELINE is installed. The installation fails if the attributes are incorrectly coded.
- CICS uses password verification to verify a user ID during the processes described here. By default, password verification does not cause RACF® to record that the user ID has been used for a sign-on. If you require this information for audit purposes, or if your system is set up to revoke unused user IDs, specify the system initialization parameter SECVFYFREQ=USRDELAY for the CICS region. When you set this system initialization parameter, CICS enforces a full verification request at least once a day for each user ID that is used to log on to the CICS region. The full verification request makes RACF record the date and time of last access for the user ID, and write user statistics.
Contains:
- An optional, empty
<suppress/>
element.If this element is specified in a service provider pipeline, the handler does not attempt to use any security tokens in the message to determine under which user ID the work runs.
If this element is specified in a service requester pipeline, the handler does not attempt to add to the outbound SOAP message any of the security tokens that are required for authentication.
- In a requester pipeline, an optional
<algorithm>
element that specifies the URI of the algorithm that is used to sign the body of the SOAP message. You must specify this element if the combination of trust and mode attribute values indicate that the messages are signed. You can specify only the RSA with SHA1 algorithm in this element. The URI ishttp://www.w3.org/2000/09/xmldsig#rsa-sha1
. - An optional
<certificate_label>
element that specifies the label that is associated with an X.509 digital certificate installed in RACF. If you specify this element in a service requester pipeline and the<suppress>
element is not specified, the certificate is added to the security header in the SOAP message. If you do not specify a<certificate_label>
element, CICS uses the default certificate in the RACF key ring.This element is ignored in a service provider pipeline.
Example
<authentication trust="signature" mode="basic">
<suppress/>
<algorithm>http://www.w3.org/2000/09/xmldsig#rsa-sha1</algorithm>
<certificate_label>AUTHCERT03</certificate_label>
</authentication>