CICS® conditionally
complies with Web Services Security: SOAP Message Security and related
specifications by supporting the following aspects.
Compliance with Web Services Security: SOAP Message
Security
- Security header
- The <wsse:Security> header provides a mechanism
for attaching security-related information targeted at a specific
recipient in the form of a SOAP actor or role. This could be the ultimate
recipient of the message or an intermediary. The following attributes
are supported in CICS:
- S11:actor (for an intermediary)
- S11:mustUnderstand
- S12:role (for an intermediary)
- S12:mustUnderstand
- Security tokens
- The following security tokens are supported in the security header:
- User name and password
- Binary security token (X.509 certificate)
- Token references
- A security token conveys a set of claims. Sometimes these claims
reside elsewhere and need to be accessed by the receiving application.
The <wsse:SecurityTokenReference> element provides
an extensible mechanism for referencing security tokens. The following
mechanisms are supported:
- Direct reference
- Key identifier
- Key name
- Embedded reference
- Signature algorithms
- This specification builds on XML Signature and therefore has the
same algorithms as those that are specified as required in the XML
Signature specification. CICS supports:
Algorithm type |
Algorithm |
URI |
Digest |
SHA1 |
http://www.w3.org/2000/09/xmldsig#sha1 |
Signature |
DSA with SHA1 (validation only) |
http://www.w3.org/2000/09/xmldsig#dsa-sha1 |
Signature |
RSA with SHA1 |
http://www.w3.org/2000/09/xmldsig#rsa-sha1 |
Canonicalization |
Exclusive XML canonicalization (without comments) |
http://www.w3.org/2001/10/xml-exc-c14n# |
- Signature signed parts
- CICS allows the following
SOAP elements to be signed:
- the SOAP message body
- the identity token (a type of security token), that is used as
an asserted identity
- Encryption algorithms
- The following data encryption algorithms are supported:
Algorithm |
URI |
Triple Data Encryption Standard algorithm (Triple DES) |
http://www.w3.org/2001/04/xmlenc#tripledes-cbc |
Advanced Encryption Standard (AES) algorithm with a
key length of 128 bits |
http://www.w3.org/2001/04/xmlenc#aes128-cbc |
Advanced Encryption Standard (AES) algorithm with a key length of
192 bits |
http://www.w3.org/2001/04/xmlenc#aes192-cbc |
Advanced Encryption Standard (AES) algorithm with a key length of
256 bits |
http://www.w3.org/2001/04/xmlenc#aes256-cbc |
The following key encryption algorithm is supported:Algorithm |
URI |
Key transport (public key cryptography) RSA Version 1.5: |
http://www.w3.org/2001/04/xmlenc#rsa-1_5 |
- Encryption message parts
- CICS allow the following
SOAP elements to be encrypted:
- Timestamp
- The <wsu:Timestamp> element provides a mechanism
for expressing the creation and expiration times of the security semantics
in a message. CICS tolerates
the use of timestamps within the Web services security header on inbound
SOAP messages.
- Error handling
- CICS generates SOAP fault
messages using the standard list of response codes listed in the specification.
Compliance with Web Services Security: UsernameToken
Profile 1.0
The following aspects of this specification are
supported:
- Password types
- Text
- Token references
- Direct reference
Compliance with Web Services Security: X.509 Certificate
Token Profile 1.0
The following aspects of this specification
are supported:
- Token types
-
- Token references
- Key identifier - subject key identifier
- Direct reference
- Custom reference - issuer name and serial number
Aspects that are not supported
The following
items are not supported in CICS:
- Validation of Timestamps for freshness
- Nonces
- Web services security for SOAP attachments
- Security Assertion Markup Language (SAML) token profile, WS-SecurityKerberos
token profile, and XrML token profile
- Web Services Interoperability (WS-I) Basic Security Profile
- XML enveloping digital signature
- XML enveloping digital encryption
- The following transport algorithms for digital signatures are
not supported:
- The Diffie-Hellman key agreement algorithm for encryption is not
supported. For more information, see http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sec-DHKeyValue.
- The following canonicalization algorithms for encryption, which
are optional in the XML encryption specification, are not supported:
- Canonical XML with or without comments
- Exclusive XML canonicalization with or comments
- In the Username Token Version 1.0 Profile specification, the digest
password type is not supported.