Policy Fragments

Policy fragments provide a convenient way to create a group of assertions that can be used in any published service. These "fragments" behave as boilerplate text to help maintain consistency when constructing a policy: once a fragment is created, it can be added to any service policy only as a "read only" entity. This allows you to enforce global rules across any number of services. Maintenance is also simplified: when the active version of a fragment is updated, the changes are instantly applied in every policy where the fragment is used. When a policy is exported or imported, any fragments present are also included.
gateway90
Policy fragments provide a convenient way to create a group of assertions that can be used in any published service. These "fragments" behave as boilerplate text to help maintain consistency when constructing a policy: once a fragment is created, it can be added to any service policy only as a "read only" entity. This allows you to enforce global rules across any number of services. Maintenance is also simplified: when the active version of a fragment is updated, the changes are instantly applied in every policy where the fragment is used. When a policy is exported or imported, any fragments present are also included.
Policy fragment can also be used in encapsulated assertions, to create a self-contained package that looks and behaves like a standard assertion.
As with conventional policies, the ability to use a policy fragment depends on the role and permissions of the user currently logged in. At the very least, the user must have Read access to the fragment and Update access to the policy to which the fragment is being added.
Example:
The following example illustrates how a service policy can be constructed by users in different roles throughout an organization, using policy fragments that were predefined earlier:
  1. The first phase of a policy (e.g., IP address and authentication assertions) is edited by DMZ network operations staff.
  2. A subsequent phase containing WS-Security and schema validation assertions could be under the control of a security architect.
  3. The routing assertion and other assertions related to Protected Service behaviour assertions are added by the application deployer.
For a description of the various policy fragments, see Create a Policy or Policy Fragment.
Choose a task from the following table:
For information on how to...
See
Create a new policy fragment
(see also "Policy Fragment Shortcut" below)
Create a new version of a policy fragment
Add a policy fragment to a policy
Delete a policy fragment
Edit a policy fragment
Policy Fragment Shortcut
To quickly create a policy fragment based on existing assertions:
  1. Open the policy revision containing the assertions to be added to a fragment.
  2. Select one or more assertions in the policy window.
  3. Right-click and select
    Create Include Fragment
    .
  4. Enter a name for the fragment and then click [
    OK
    ].
The Policy Manager replaces the selected assertions with a new Include Policy Fragment that contains those assertions. The new fragment is added to the Services and Policies list, where it will be available to be added to any other policy.
Policy Fragment Tips
The following tips apply to included policy fragments. For tips and suggestions related to global policy fragments, see "Working with Global Policy Fragments".
  • Policy fragments are listed in the Services and Policies list.
  • Fragments can be as short as a single assertion or as long as a complete policy.
  • The assertions in an included policy fragment cannot be edited when the fragment is inserted into a policy. However you can edit an included policy fragment and the changes instantly apply everywhere the fragment is used.
  • You can import items from a policy template into a fragment, but you cannot import from a UDDI registry.
  • You can drag and drop one policy fragment into another (i.e., a fragment can be made up of other fragments).
  • Policy fragments have their own revision history.
  • If the fragment contains assertions that create their own context variables and these variables need to be available to the parent policy (that is, outside of the policy fragment), ensure that a Export Variables from Fragment assertion appears in the fragment. An example of assertions that create context variables are the XPath-based assertions (Evaluate Request XPath or Evaluate Response XPath).
  • If the fragment is to be used in an encapsulated assertion, it is not necessary to include the a Export Variables from Fragment assertion unless XPath-based assertions are involved.