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. WS-Security allows web service implementers to do the following:
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.
CA SiteMinder WSS 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:
The WS-Security authentication scheme automatically attempts to decrypt any XML-encrypted elements in incoming WS-Security messages for CA SiteMinder WSS to use for authentication/authorization. No additional configuration is required.
Note: 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 SiteMinder WSS attempts to decrypt only XML-encrypted elements specified in the header from which the WS-Security authentication scheme is configured to obtain security tokens.
CA SiteMinder WSS can encrypt any WS-Security message that contains the recipient’s X.509 certificate in a WS-Security header. CA SiteMinder WSS extracts the recipient’s public key from their X.509 certificate and uses this to encrypt a symmetric key, which it then uses 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 SiteMinder WSS 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 SiteMinder WSS is to deliver messages to the recipient web service in encrypted form. However, you can configure CA SiteMinder WSS 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.
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 SiteMinder WSS 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 SiteMinder WSS-protected web services, Company A develops the following:
The encryption web service then forwards the encrypted message to a decryption web service at Company B.
Company B develops a Decryption web service protected by the WS-Security authentication scheme and an authorization policy configured to deliver the decrypted version of message header/body elements.
CA SiteMinder WSS supports the following XML encryption algorithms:
Regardless of the particular security token 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 provided by the Username and Password Digest token) by giving an indication of the document's “freshness.”
Note: The expiry feature does not completely address the problems 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.
CA SiteMinder WSS 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:
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 are defined implicitly based on the subject confirmation methods that you require.
If a SOAP document has multiple WS-Security headers (intended for different recipients), the WS-Security specification requires that each be 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 SiteMinder WSS should obtain security tokens.
Note: 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.
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 its <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 SiteMinder WSS Agent configuration documentation.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|