How CICS complies with Web Services Security specifications

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)
  • SAML token
  • Kerberos token
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 algorithm requirements as those specified 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:
  • The SOAP body
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
  • References to X509 certificates from a <wsse:SecurityTokenReference> using a <wsse:KeyIdentifier>
  • 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 algorithm for encryption, which is optional in the XML encryption specification, is not supported:
    • Canonical XML with or without comments
    • Exclusive XML canonicalization with or without comments
  • In the Username Token Version 1.0 Profile specification, the digest password type is not supported.