WS-Security Authentication Introduced

The WS-Security standard defines a set of SOAP header extensions that provide mechanisms for securely passing authentication data and protecting message content between web services, particular those at federated enterprises.
sm1252sp1
The WS-Security standard defines a set of SOAP header extensions that provide mechanisms for securely passing authentication data and protecting message content between web services, particular those at federated enterprises.
Contents
2
 WS-Security allows web service implementation to do the following:
  • Send authentication data as part of a message using one of several supported security token types.
  • Ensure message integrity using digital signatures.
  • Ensure message confidentiality using XML encryption.
These mechanisms can be used independently (for example, to pass authentication data in a security token) or in combination (for example, signing and encrypting a message and providing authentication data in a security token).
For more information about the WS-Security standard, see the OASIS Standard, 
Web Services Security: SOAP Message Security 1.0
.
XML Encryption
CA Single Sign-On
Web Services Security supports encryption and decryption of any combination of WS-Security message header elements and body elements using XML encryption compliant with OASIS Standard 200401,
Web Services Security: SOAP Message
Security
1.0
.
XML encryption of WS-Security messages provides end-to-end security for web service applications that require secure exchange of structured data. XML encryption provides security functionality that cannot be provided by point-to-point security protocols such as SSL. Specifically, it allows you to:
  • Encrypt only part of the data that is being exchanged
  • Secure sessions between more than two parties
How
CA Single Sign-On
Web Services Security Obtains Credentials from Encrypted WS-Security Documents
The WS-Security authentication scheme automatically attempts to decrypt any XML-encrypted elements in incoming WS-Security messages for
CA Single Sign-On
Web Services Security to use for authentication/authorization. No additional configuration is required.
Where an incoming SOAP message contains multiple WS-Security header elements, each is identified by a unique SOAP actor/role attribute. In such cases,
CA Single Sign-On
Web Services Security attempts to decrypt only XML-encrypted elements that are specified in the header from which the WS-Security authentication scheme is configured to obtain security tokens.
Configure
CA Single Sign-On
Web Services Security to Perform Encryption and Decryption of WS-Security Documents
CA Single Sign-On
Web Services Security can encrypt any WS-Security message that contains the recipient’s X.509 certificate in a WS-Security header.
CA Single Sign-On
Web Services Security extracts the recipient’s public key from their X.509 certificate and uses this to encrypt a symmetric key. The symmetric key is then used to encrypt the desired header and message elements. Multiple encryption algorithms are available; different encryption algorithms can be used for encryption of the symmetric key and header/message elements.
Configure
CA Single Sign-On
Web Services Security to perform XML encryption on elements of outgoing messages by adding appropriate response attribute variables to a response configured to generate WS-Security headers.
Although the WS-Security authentication scheme automatically decrypts encrypted elements in incoming messages, the default behavior of
CA Single Sign-On
Web Services Security is to deliver messages to the recipient web service in encrypted form. However, you can configure
CA Single Sign-On
Web Services Security to deliver decrypted versions of incoming encrypted WS-Security messages by configuring a response with the TXM_WSSEC[_SAML]_ENCRYPT_DECRYPT response attribute variable and associating it with the authorizing policy.
XML Encryption and Decryption Service Use Case
In multistep and chain authentication service models, encryption or decryption may be considered part of message preparation before sending to the ultimate destination. Thus, the
CA Single Sign-On
Web Services Security XML encryption and decryption functionality might typically be used to implement a WS-Security encryption or decryption web service.
For example, consider a business relationship between two companies—Company A and Company B. Company A wants to end detailed bids on contracts to Company B without unauthorized personnel at Company B seeing the message (as would be the case if it was simply sent over an SSL link).
To implement this business logic using
CA Single Sign-On
Web Services Security-protected web services, Company A develops the following mechanism:
  • A web service consumer application that takes the bid, places it in XML format and wraps it with SOAP headers, placing Company B’s X.509 certificate in a WS-Security header. The application then sends it to Company A’s encryption web service.
  • An encryption web service that is protected by the WS-Security authentication scheme and an authorization policy that is configured to do the following:
    • Obtain the intended recipient's public key certificate (in this case Company B's certificate) from the message headers
    • Encrypt the required header and message elements.
    The encryption web service then forwards the encrypted message to a decryption web service at Company B.
Company B develops a Decryption web service that is protected by the WS-Security authentication scheme and an authorization policy that is configured to deliver the decrypted version of message header/body elements.
Encryption Algorithms
CA Single Sign-On
Web Services Security supports the following XML encryption algorithms:
  • Key transport algorithms
    (used to encrypt the symmetric key):
    • rsa-1_5
    • rsa-oaep-mgf1p
  • Block Encryption algorithms
    (used to encrypt message data):
    • tripledes-cbc
    • aes128-cbc
    • aes256-cbc
    • aes192-cbc
Message Timestamps
Regardless of the particular security token that is used by any WS-Security document, a utility timestamp element, which specifies the expiry time of a message, can be specified. If this element is covered by an XML signature, then the timestamp provides a protection against replay attacks for the entire XML document (different from the replay attack defense that is provided by the Username and Password Digest token) by giving an indication of the document's “freshness.”
The expiry feature does not completely address the problems that are introduced by unsynchronized clocks. The receiving party in a WS-Security message exchange may receive a document before the timestamp's created time; the issue of acceptable skew is a receiving policy issue, while the expiry offset is a creation policy issue.
XML Signature Scope
CA Single Sign-On
Web Services Security provides three options for defining what elements of an incoming SOAP message are digitally signed when configuring WS-Security authentication using either Username and Password Digest or X509v3 tokens:
  • Signature must cover the entire document
  • Signature must cover the body of the message
  • Signature need apply only to headers
Notes:
For the Username and Password Digest token, XML digital signatures are optional.
If the authentication scheme is configured to require the timestamp element, the digital signature must cover that timestamp.
SAML token authentication has its own requirements for what elements of a SOAP message must be digitally signed; these requirements are defined implicitly based on the subject confirmation methods that you require.
SOAP Actor Role Attributes in Messages with Multiple WS-Security Headers
If a SOAP document has multiple WS-Security headers (intended for different recipients), the WS-Security specification requires that each header is identified uniquely using the SOAP actor/role attribute (at most, one header can omit the SOAP actor attribute).
The WS-Security authentication scheme lets you specify the value of the SOAP actor/role attribute that identifies the header element from which
CA Single Sign-On
Web Services Security should obtain security tokens.
If a message has only one WS-Security header, it does not need to include a SOAP actor attribute. However, if you specify an actor/role attribute when configuring the authentication scheme, a matching actor attribute must be present in the document to allow successful authentication.
Username and Password Digest Token Age Restrictions
The WS-Security authentication scheme provides protection against replay attacks using Username and Password Digest tokens by imposing a "freshness" restriction (60 minutes by default) on the age of the token. That is, if a token was created more than 60 minutes ago according to the <wsu:Created> timestamp, authentication fails.
The token age restriction for Username and Password Digest Tokens can be configured at the agent level. For more information, see the
CA Single Sign-On
WSS Agent configuration documentation.
Username and Password Digest Limitation
If you configure the WS- Security authentication to use Username and Password Digest, the userPassword attribute value is retrieved and compared with the digest value of the incoming SOAP message. For security reasons, the password attributes (UserPasswrd or unicodePwd) of the Active Directory cannot be retrieved.
For Active Directory, the WS-Security authentication scheme does not support the digest form that is generated by the client. Only the cleartext form of the user password is supported.