Customizing WS-Security decorations when adding a SAML token to an existing request or response
Article ID: 42939
Updated On:
Products
Issue/Introduction
Solution
Background
The CA API Gateway has an assertion that allows a policy author to control what WS-Security decorations are added or removed from a message. This includes the parameters used to sign and encrypt elements of a SOAP message. The Gateway is also capable of generating SAML tokens that can be used to authenticate or authorize external users to other entities based upon an existing trust relationship with an API Gateway cluster. The security decorations of these two capabilities can override one another depending on the order of implementation in the published service policy. The?Create SAML Token?assertion will leverage a preconfigured set of WS-Security decorations based upon standards and conventions. The Configure WS-Security Decoration?assertion allows an author to customize what decorations are present. If the Create SAML Token assertion is executed after the Configure WS-Security Decoration assertion then the token creation will overwrite the configured decoration. This article will prescribes the steps and provide a sample policy that avoids that behavior
Implementation
A sample policy is illustrated below?that simultaneously?creates a SAML token and adds it to a message then attempts to configure and apply a customized set of WS-Security decorations:
<Please see attached file for image>
This policy is technically valid and will generate an SOAP message containing a SAML token. The WS-Security decorations specified in the?Configure WS-Security Decoration?assertions and added via the?Apply WS-Security?assertion will not be present once the SAML token is added to the message. This has the broadest impact when attempting to modify certain signature parameters or when excluding certain decorations such as timestamps. Any decorations configured in the Configure assertion will be overridden by the Create assertion.
This can be avoided by not immediately adding the SAML token to the target message and relying upon another assertion to add the token to the message. A sample policy is illustrated below that adds the SAML token to the message after creation and then customizes the decoration
<Please see attached file for image>
The SAML token is created but not added to the target message. It is then added separately to the message. This allows the decoration customization to occur after the token is created and avoids any overriding?behavior that occurs as a result of the Create SAML Token assertion. A sample policy is attached to this article.
Attachments:
Environment
Component: APIGTW
Attachments
Feedback
