Validate a Policy

The Policy Manager provides two types of policy validation:
The Policy Manager provides two types of policy validation:
  • Instant feedback messages in the Policy Validation Messages window when you configure or edit a policy
  • Final policy validation when [
    ] or [
    ] is clicked on the Policy Tool Bar. A final policy validation is more thorough than an instant feedback message, as it queries the server.
Ensure that the Policy Validation Message window is visible and that policy validation feedback has not been disabled in the Preferences. Disabled assertions in a policy are ignored during validation.
A service with an invalid policy is still active, enabled, and accessible. Only a disabled service is inactive and inaccessible. See Published Service Properties for information on disabling a service.
You can disable policy validation by using the "Policy Validation Feedback" setting in the Preferences. For example, you may wish to disable validation during construction of a complex policy, to maximize responsiveness of the Policy Manager.
Instant Feedback Messages
The Policy Validation Messages window displays valuable feedback messages during policy configuration or editing. The window displays the following types of messages:
Message Type
Confirmation messages confirm that an assertion has been properly added and configured.
Warning messages warn that an assertion:
  • Has been duplicated
  • Requires another assertion to be valid
  • Has been configured improperly
Error messages warn that an assertion:
  • Has not been configured
  • Is located improperly within the policy
  • Is in conflict with another assertion
The instant feedback messages are not designed to detect all possible errors. For example, it will not report on non-existent identities in an imported policy. Always perform a final policy validation and carefully review any messages.
Final Policy Validation Messages
The Policy Manager performs additional validation checks when you click [
] or [
] on the Policy Tool Bar, or select [
] >
from the Main Menu.
  • If the policy contains no errors, the message "Policy validated ok" is displayed. You may now enable or export the policy.
  • If error messages appear, refer to the following table to troubleshoot.
Message Type
Suggested Solution
Assertion organization errors
Assertions must be placed in a logical order, and must be valid at the time of validation. Common policy errors include:
  • Assertions out of order
  • Assertion dependencies not established
  • User/group IP referenced in the policy are no longer valid
Reorganize the assertions so that they conform to the organization and rules described in Policy Organization.
Assertion configuration errors
Double check the settings of each assertion in the policy. Refer to the documentation for each assertion for more details.
Assertion permission errors
The validation message "Permission is denied for this assertion. The policy cannot be saved." indicates that the policy contains assertions that are not permitted for the policy. This could be caused by the assertions belonging to a different security zone from the policy or the user does not have sufficient permissions to save the assertions.  
Identity errors
See "Invalid Users or Groups" below for more details.
An example of such an error: "The corresponding identity cannot be found. Please remove the assertion from the policy."
JMS warning messages
See "Invalid JMS Queue" below for more details.
An example of such an error: "The assertion might not work as configured. There is no protected service JMS queue defined."
Save errors
The message "Error saving service and policy" appears. This error can occur if multiple Policy Managers modify the same policy simultaneously, resulting in conflicts. If this happens, dismiss the error message, refresh the service policy, modify the policy further if necessary, then try saving again.  
Namespace errors
A message similar to the following appears: "Assertion: <name> Warning: This assertion contains an XPath that uses the SOAP 1.1 envelope namespace URI, but the service is configured as using only SOAP 1.2. The XPath will always fail."
To correct this, click the Fix It link next to the message. This will allow you to update the namespaces for all your XPath assertions. For more information, see Migrating Namespaces.
Continue validating the policy until no errors remain. At this point, you may enable or export the policy. 
Invalid Users or Groups
You will receive an identity error during policy validation if either of the following occurs:
  • An Internal Identity Provider user in the policy has an expired account
  • The user or group in the policy has been deleted from the LDAP Identity Provider, Federated Identity Provider, or Internal Identity Provider.
To resolve these errors, refer to the following table:
Identity no longer required
  • Delete the assertion.
Need to keep the user or group
  1. Delete the assertion.
  2. Set a new account expiration date for the user (see Internal Identity Provider Users and Group)
    Re-add the user or group to the appropriate Internal Identity Provider Users and Groups, Federated Identity Provider Users and Groups, or LDAP Identity Provider.
    Since LDAP Identity Provider users and groups are defined outside of the Policy Manager, use the appropriate external management program to re-add the missing LDAP Identity Provider user or group.
  3. Use the Authenticate User or Group assertion to re-add the user or group into the policy.
  4. Click [
    ] or [
    ] on the Policy Tool Bar to perform the final validation check.
When constructing a new policy, you will not be able to add a user or group that is not in the target identity provider.
Invalid JMS Queue
When JMS routing is used in a new or existing policy, the validation process checks the outbound queue attached to the Route via JMS assertion. An error message will appear in the Policy Validation Messages window if the queue is unspecified or invalid. Try the following steps if errors occur:
  1. Enter or re-enter the outbound JMS queue.
  2. Test the outbound JMS queue.
  3. Edit the JMS Routing assertion, if necessary, for the new or revised queue.