Global Policy Fragments

Global policies are policy fragments that are always applied before or after every service policy in the system. They can be used to configure global behaviors like auditing or logging, where it may not be feasible to manually add the policy logic to all service policies.
gateway94
Global policies are policy fragments that are always applied before or after every service policy in the system. They can be used to configure global behaviors like auditing or logging, where it may not be feasible to manually add the policy logic to all service policies.
Global policies ensure consistency and reduce possible errors, because an administrator no longer needs to remember to manually insert policy fragments to every service policy to achieve a specific outcome (in that scenario, the Policy Manager is not able to detect instances where the administrator forgets to add a policy fragment) .
Only users with the role of 'Administrator' can create or delete global policies. Administrators and those with the role 'Manage Web Service' can edit global policies. Administrators, Operators, and Manage Web Service roles can read global policies.
It is important to plan your global policies carefully. Careless use of these policies can cause service requests to fail in ways that may be difficult to diagnose.
Types of Global Policies
The following types of global policies are available (these are selected from the "Policy Tag" field in the policy properties):
  • message-received:
     A policy of this type will run when a message is received, but before the service is resolved.
  • pre-security:
     A policy of this type will run before any security is processed in the request. This policy runs even if there is no security in the message.
Other items of note about this policy type: A 'pre-security' global policy can run even before the target service is determined, since it may be necessary to decrypt a message in order to resolve the service. As a result, it is possible that the 'pre-security' policy may run without the corresponding 'post-security' policy being run. For example, consider this scenario: a 'pre-security' policy runs, but then service resolution fails. When this happens, the only policy that can run upon resolution failure is the 'message-completed' policy.
  • pre-service:
     A policy of this type will run before the service policy is executed. 
  • post-service:
     A policy of this type will run after the service policy is executed. 
  • post-security:
     A policy of this type will run after security is processed for the response. This policy runs even if there is no security processing is required. 
  • message-completed:
     A policy of this type will run when processing for a message completes. It will run even if the service policy fails, an exception occurs, the service could not be resolved, or any other condition that prevents the service policy from being completed.
Note that only one policy of each type is permitted.
How Global Policies are Evaluated
Global policies are evaluated in the order shown under "Types of Global Policies" above. However note that not all global policies will be evaluated in all cases. If a service cannot be resolved, then only the following global policies would be run:
  • message-received policy
  • pre-security policy (only if security processing is required during service resolution, i.e., for an encrypted message body)
  • message-completed policy
Global policies of these types should be configured to run without a resolved service and should not assume there is a response message. As a result, a WSDL operation assertion (for example) should not be used in these policies.
If policy processing failed due to an exception or policy falsified error, then the following global policies will be run:
  • message-received policy 
  • pre-security policy 
  • pre-service policy 
  • message-completed policy
The Gateway will stop evaluating global policies on any error or on policy failure, except for the message-completed policy, which always runs.
A global policy that contains no assertions or all disabled assertions will always succeed.
How a Global Policy Relates to the Service Policy
 A global policy shares the following with a service policy:
  • request/response messages
  • message context mappings
  • audit/fault settings
  • authentication details
  • built-in context variables (all other variables local to the policy being run)
Routing assertions in a global policy will not affect the routing latency or the URL for the service policy.
The policy status of a global policy affects the overall status for a service: a failure of a global policy causes a "policy falsified" error for message processing.
Details in SOAP faults will not include details for global policies.
If an audit sink policy is configured, it will run after the service policy and all global policies complete.
When constructing a global policy, you may use any policy fragments.
Compatible Assertions
The following assertions are tested and certified for use in global policies:
  • Add Audit Detail Assertion
  • Add Comment to Policy Assertion
  • All Assertions Must Evaluate to True Assertion
  • Apply Rate Limit Assertion
  • At Least One Assertion Must Evaluate to True Assertion
  • Audit Messages in Policy Assertion
  • Capture Identity of Requestor Assertion
  • Compare Expression Assertion
  • Continue Processing Assertion
  • Customize Error Response Assertion
  • Customize SOAP Fault Response Assertion
  • Export Variables from Fragment Assertion
    (
    Note:
     Be sure to reference the exported variables using the syntax:
     ${request.shared.<exported_variable_name>}.
    )
  • Include Policy Fragment Assertion
  • Limit Availability to Time/Days Assertion
  • Limit Message Size Assertion
  • Resolve Service Assertion
  • Restrict Access to IP Address Range Assertion
  • Send Email Assertion
  • Send SNMP Trap Assertion
  • Set Context Variable Assertion
  • Stop Processing Assertion
WARNING:
Other assertions not listed above may work but are not supported by CA Technologies. Avoid using assertions in a global policy that have significant side effects, as this can make debugging service policies extremely difficult.
Limitations to Global Policies
Note the following scenarios when global policies will not be processed:
  • Global policies will not be processed when the Gateway generates a policy for the CA API Gateway - XML VPN Client.
  • Global policies will be not processed when the Gateway generates the WS-SecurityPolicy document attached to a service WSDL. 
  • Global policies will not be included if policy debug tracing is enabled for a service. 
  • Global policies will not be included when the service policy is exported. 
  • Global policies will not be included in policy migrations.
Validating Global Policies
As with policy fragments, the policy validator built into the Policy Manager can provide only limited assistance when editing a global policy.
When global policies are in effect, the validator may display unexpected warnings when editing a service policy since the validator will not see the effects of the global policies. For example, if credentials are collected in a global policy, a service policy that uses those credentials may trigger a validator warning that no credentials have been collected. Use of such a global policy is not recommended.