Skip Headers
Oracle® Fusion Middleware Security and Administrator's Guide for Web Services
11g Release 1 (11.1.1.5)

Part Number B32511-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

9 Creating and Managing Policy Sets

Policy sets provide a means to attach policies globally to a range of endpoints of the same type. This chapter describes how to manage and create policy sets using Oracle Enterprise Manager Fusion Middleware Control and the command line interface WebLogic Scripting Tool (WLST). For more information about policy sets, see "Attaching Policies Globally Using Policy Sets". For information about attaching policies to policy subjects directly, see Chapter 8, "Attaching Policies to Web Services".

This chapter includes the following sections:

Notes:

The procedures in this chapter apply to Oracle Infrastructure Web Services only.

To view the help for the WLST commands described in this chapter, connect to a running instance of the server and enter help('wsmManage').

Navigating to the Policy Set Summary Page

You can manage your policy sets at the domain level from the Policy Set Summary page. From this page, you can view, create, copy, edit, and delete policy sets.

To navigate to the Policy Set Summary page:

  1. In the Navigator pane, expand WebLogic Domain.

  2. Select the domain for which you want to manage policy sets.

  3. From the WebLogic Domain menu, select Web Services then Policy Sets.

    The Policy Set Summary page is displayed, as shown in Figure 9-1.

    Figure 9-1 Policy Set Summary Page

    Description of Figure 9-1 follows
    Description of "Figure 9-1 Policy Set Summary Page"

Displaying a List of Policy Sets Using WLST

To display a list of the policy sets in the repository:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands".

  2. Use the listPolicySets command to display a list of the policy sets in the repository.

    listPolicySets ([type=None])
    

    You can limit the display to include only those policy sets that apply to a specific type of policy subject resource types. To specify the type of subject, you must use the abbreviations specified in Table 9-1, "Policy Subject Resource Types".

    For example, to display a list of policy sets that apply to Web service endpoints:

    wls:/jrfserver_domain/serverConfig>listPolicySets('ws-service')
     Global Policy Sets in Repository:
      app-only-web-service-policies
      all-domains-default-web-service-policies
    

For more information about this WLST command, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Viewing the Configuration of a Policy Set

The following sections describe how to view a policy set using either Fusion Middleware Control or the command-line interface WebLogic Scripting Tool (WLST).

Using Fusion Middleware Control

To view a policy set:

  1. Navigate to the Policy Set Summary page as described in "Navigating to the Policy Set Summary Page".

  2. In the Policy Set Summary page, select a policy set from the table and click View.

  3. When you are done viewing the policy set, click Return to Policy Sets.

    Figure 9-2 Viewing a Policy Set

    Description of Figure 9-2 follows
    Description of "Figure 9-2 Viewing a Policy Set"

Using WLST

To view the configuration of a specific policy set in the repository:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands".

  2. Use the displayPolicySet command to display the configuration of a specified policy set.

    displayPolicySet (name=None)
    

    When you execute this command outside of a repository session, you can display the configuration of any policy set using the name argument. If the policy set does not exist, an error message is displayed.

    If you are creating or modifying a policy set in a repository session, you do not need to specify the name argument. The current policy set is used by default. If the policy set is being modified, then the modified version is displayed. Otherwise, the latest version in the repository is displayed.

    For example:

    wls:/jrfserver_domain/serverConfig>displayPolicySet('all-domains-default-web-service-policies')
     
    Policy Set Details:
    -------------------
    Name:                all-domains-default-web-service-policies
    Type of Resources:   Web Service Endpoint
    Scope of Resources:  Domain("jrfServer_domain")
    Description:         Global policy attachments for Web Service Endpoint resources.
    Enabled:             true
    Policy Reference:    security : oracle/wss11_saml_or_username_token_with_message_protection_service_policy, enabled=true
    

For more information about this WLST command, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Managing Repository Modification Sessions Using WLST

When using WLST to create, modify, and delete policy sets, you must execute the commands in the context of a repository session. Each repository session applies to a single policy set only.

To create a session in which the repository will be modified, use the beginRepositorySession command. After you have entered the desired commands to create, modify, or delete a policy set, you write the contents of the session to the repository using the commitRepositorySession command.

Use the describeRepositorySession command to describe the contents of the current session.

To exit a repository session without writing the contents to the repository, use the abortRepositorySession command.

Examples of these commands are provided in the subsequent sections. For additional information, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Creating a Policy Set

The following sections describe how to create a policy set using either Fusion Middleware Control or the command line interface WebLogic Scripting Tool, WLST.

Using Fusion Middleware Control

To create a policy set:

  1. Navigate to the Policy Set Summary page as described in "Navigating to the Policy Set Summary Page".

  2. From the Policy Set Summary page, click Create.

    The first page of the policy set creation wizard is displayed.

  3. In the Enter General Information page, as shown in Figure 9-3, enter a name and description for the policy set.

    Figure 9-3 Enter General Information Page

    Description of Figure 9-3 follows
    Description of "Figure 9-3 Enter General Information Page"

  4. Select the Enabled check box if you want to enable the policy set.

  5. In the Type of Resources field, select the type of policy subject to which you want to attach policies. On the next page you define the scope of resources to which you want the policy set to apply. The type of policy subjects that you can select are as follows:

    • SOA Component

    • SOA Service

    • SOA Reference

    • Web Service Connection

    • Web Service Endpoint

    • Web Service Client

    • Asynchronous Callback Client

  6. Optionally, add a description of the policy set, and then click Next.

  7. In the Enter Resource Scope page, enter at least one pattern string that defines the scope for the resource type you selected in the previous step. The following resource scopes are supported:

    • Domain

    • Server Instance

    • Application

    • Application Module

    • SOA Composite

    Note:

    To specify a resource scope, you must enter a pattern string in at least one Pattern field on this page.

    The list of available resource scopes is determined by the Resource Type you selected on the previous page. For example, if you selected Web Service Endpoint, the resource scopes available are Domain, Server Instance, Application, and Application Module. For SOA resource types, the resource scopes available are Domain, Server Instance, and SOA Composite.

    For example, to attach the policies to all Web Service endpoints in the domain, enter a pattern string to represent the name of the domain only. You do not need to complete any of the other fields. To attach the policies at a finer scope, for example at the application or application module level, enter a pattern string to represent the name of the application or the module in the Pattern field. You can use an asterisk (*) as a wildcard character anywhere within the string to match any number of characters at its position; you can specify multiple wildcards within the string. Note that if you use only an asterisk wildcard for Domain, the scope level will affect all domains in the enterprise.

    If you provide a pattern string for multiple resource scopes, such as Domain Name and Server Instance Name, the filtering conditions are ANDed together; for example, Domain("myDomain*") AND Server ("*SOA*"). For more information about specifying the resource type and scope, and an example that specifies multiple resource scopes, see "Defining the Type and Scope of Resources".

    Figure 9-4 Enter Resource Scope Page

    Description of Figure 9-4 follows
    Description of "Figure 9-4 Enter Resource Scope Page"

  8. Click Next.

  9. In the Add Policy References page, select a policy from the Available Policies list, and click Attach.

    To view details about a policy, select the policy and click the View Detail icon. A pop-up window provides a full read-only description of the policy and lists the assertions that it contains. Click OK when you are finished reviewing the details of the policy.

  10. Continue selecting and attaching policies. When you are finished, click Validate to verify that the combination of policies selected are valid.

    Figure 9-5 Add Policy References Page

    Description of Figure 9-5 follows
    Description of "Figure 9-5 Add Policy References Page"

  11. Click Next to view the Policy Set Summary Page.

  12. Review the policy set summary information. If you are satisfied with the policy set, click Save.

    Note that if the validation fails, the policy set is still saved, but in disabled mode.

    Figure 9-6 Policy Set Summary Page in Create Policy Set Wizard

    Description of Figure 9-6 follows
    Description of "Figure 9-6 Policy Set Summary Page in Create Policy Set Wizard"

Using WLST

Use the following procedure to create a policy set using WLST.

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands".

  2. Begin a repository session using the beginRepositorySession command.

    The beginRepositorySession command is used to create a session in which the repository will be modified. All creation, modification, or deletion commands must be performed in the context of a session. A session can only act on a single document.

    For example:

    wls:/jrfserver_domain/serverConfig> beginRepositorySession()
    
    Repository session begun.
    
  3. Use the createPolicySet command to create a new, empty policy set. The name, type, and attachTo arguments are required.

    createPolicySet(name, type, attachTo, [description=None], [enable='true'])
    

    Where:

    • name represents the name of the new, empty policy set.

    • type represents the type of policy subject to which the new policy set applies.

    • attachTo represents the scope of resources to which the policy set will be attached. This argument must use a supported expression that defines a valid resource scope in a supported format. For more information, see "Defining the Type and Scope of Resources".

      You do not need to enter the exact domain name for the resource scope. Wildcards are permitted, as shown in the example. For details, see "Defining the Type and Scope of Resources".

    • description represents an optional argument that provides a description of the policy set.

    • enable specifies if the policy set is enabled or disabled. This argument is optional.

    For example, to create a policy set for all services in a domain using only the required arguments:

    wls:/jrfserver_domain/serverConfig> createPolicySet('all-domains-default-web-service-policies', 'ws-service', 'Domain("*")')
    
    Description defaulted to "Global policy attachments for Web Service Endpoint resources."The policy set was created successfully in the session.
    

    Note that because no description was specified on the command line, a default description was provided.

    For additional details about the arguments for this command, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

  4. Specify a description using the setPolicySetDescription command.

    setPolicySetDescription(description)
    

    For example, to set the description as "Default policies for web services in any domain", use the following command:

    wls:/jrfserver_domain/serverConfig> setPolicySetDescription('Default policies for web services in any domain')
    
    Description updated.
    
  5. To attach a policy to the current policy set, use the attachPolicySetPolicy command. The policy, identified by the specified URI using the uri argument, is attached to the endpoints specified in the policy set. You can repeat this command as needed to attach all the desired policies to the policy set.

    attachPolicySetPolicy(uri)
    

    For example, to attach the policy 'oracle/wss11_saml_or_username_token_with_message_protection_service_policy' to the subjects specified in the policy set, enter the following command:

    wls:/jrfserver_domain/serverConfig>attachPolicySetPolicy('oracle/wss11_saml_or_username_token_with_message_protection_service_policy')
    
    Policy reference added.
    
  6. To display the configuration of the policy set during the current repository session, use the displayPolicySet command.

    displayPolicySet(name=None)
    

    Note that when you execute this command within a repository session, you do not need to specify the name argument. The current policy set is used by default. If the policy set is being modified, then the modified version is displayed. Otherwise, the latest version in the repository is displayed.

    For example:

    wls:/jrfserver_domain/serverConfig>displayPolicySet() 
    
    Policy Set Details:
    -------------------
    Name:                all-domains-default-web-service-policies
    Type of Resources:   Web Service Endpoint
    Scope of Resources:  Domain("*")
    Description:         Default policies for web services in any domain
    Enabled:             true
    Policy Reference:    security : oracle/wss11_saml_or_username_token_with_message_protection_service_policy, enabled=true
    
  7. To validate the policy set, use the validatePolicySet command.

    validatePolicySet(name=None)
    

    If a name is not provided, then the command validates the policy set being created or modified in the current session. Note that you can also execute this command outside of a repository session. If you do so, the name argument is required.

    For example:

    wls:/jrfserver_domain/serverConfig> validatePolicySet()
     
    The policy set all-domains-default-web-service-policies is valid.
    
  8. To write the contents of the current repository session to the repository, use the commitRepositorySession command.

    wls:/jrfserver_domain/serverConfig> commitRepositorySession()
    
    The policy set all-domains-default-web-service-policies is valid.
    Creating policy set all-domains-default-web-service-policies in repository.
     
    Repository session committed successfully.
    

    Alternately, you can choose to cancel any changes by using the abortRepositorySession command, which discards any changes that were made to the repository during the session.

For more information about these WLST commands and their arguments, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Creating a Policy Set from an Existing Policy Set

You can use an existing policy set as the base for a new policy set. The following sections describe how to create a new policy set from an existing policy set using either Fusion Middleware Control or the command line interface WebLogic Scripting Tool, WLST.

Note that when you create a policy set from an existing policy set, all values and attachments are copied into the new one. You can modify the resource scope and the policy attachments in the new policy set, but you cannot change the type of resource to which it applies.

Using Fusion Middleware Control

To create a policy set using an existing policy set:

  1. Navigate to the Policy Set Summary page as described in "Navigating to the Policy Set Summary Page".

  2. In the Policy Set Summary page, select the policy set that you want to copy and click Create Like.

  3. In the Enter General Information page, enter a new name and description for the policy set.

    Note the following:

    • The default new policy set name is created by appending "_Copy" to the base policy set name. For example, if the base policy set is named all-domains-default-web-service-policies, the name displayed for the copy is all-domains-default-web-service-policies_Copy.

    • The Resource Type field is read-only. When you clone a policy set, you can modify the scope but not the type of resources to which the policy set will be attached.

  4. Select or clear the Enabled check box to enable or disable the policy set.

  5. Click Next.

  6. In the Enter Resource Scope page, modify the scope as desired and click Next.

    Note:

    To specify a resource scope, a pattern string must be provided in at least one Pattern field on this page.
  7. In the Add Policy References page, modify the policy attachments as desired. When you are finished, click Validate to verify that the combination of polices selected is valid.

  8. Click Next to view the Policy Set Summary Page.

  9. Review the policy set summary information. If you are satisfied with the policy set, click Save.

Using WLST

To create a policy set from an existing policy set:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands".

  2. Begin a repository session using the beginRepositorySession command.

    For example:

    wls:/jrfserver_domain/serverConfig> beginRepositorySession()
    
    Repository session begun.
    
  3. Use the clonePolicySet command to create a policy set using an existing policy set.

    clonePolicySet(name, source, [attachTo=None,] [description=None], [enable='true'])
    

    Where:

    • name represents the name of the new, cloned policy set.

    • source specifies the name of the policy set to be cloned.

    • attachTo represents the scope of resources to which the policy set will be attached. This argument, if provided, must use a supported expression that defines a valid resource scope in a supported format. You do not need to enter the exact name for the resource scope. Wildcards are permitted, as shown in the example. For more information, see "Defining the Type and Scope of Resources".

      If this argument is not specified, then the expression used in the source policy set to identify the scope of resources is retained. You can also modify the resource scope using the attachPolicySet command, as described in step 0

    • description represents an optional argument that provides a description of the cloned policy set.

    • enable specifies if the policy set is enabled or disabled. This argument is optional.

    For example, to clone a policy set:

    wls:/jrfServer_domain/serverConfig> clonePolicySet('app-only-web-service-policies','all-domains-default-web-service-policies', None, 'Default policies for application jaxws-sut')
    
    The policy set was cloned successfully in the session.
    

    Note that the attachTo argument was not specified in this example.

    For details about the arguments for this command, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

  4. Optionally, you can view the configuration of the policy set using the displayPolicySet command.

    For example:

    wls:/jrfServer_domain/serverConfig> displayPolicySet()
     
    Policy Set Details:
    -------------------
    Name:                app-only-web-service-policies
    Type of Resources:   Web Service Endpoint
    Scope of Resources:  Domain("jrfServer_domain")
    Description:         Default policies for application jaxws-sut
    Enabled:             true
    Policy Reference:    security : oracle/wss11_saml_or_username_token_with_message_protection_service_policy, enabled=true
    
  5. To change the resource scope of the attachments, use the attachPolicySet command.

    attachPolicySet(expression)
    

    Where:

    • expression is a supported expression that defines the resource scope, in a supported format, that is valid for the resource type defined in the policy set. For example, for SOA resource types, you cannot define the resource scope to be an application. The supported resource scopes for SOA resource types are Domain, Server, and Composite. For more information, see "Defining the Type and Scope of Resources"

    For example, to attach the policies in the policy set only to the application named jaxws-sut, enter the following command:

    wls:/jrfServer_domain/serverConfig> attachPolicySet('Application("jaxws-sut")')
     
    Scope of resources updated.
    
  6. Optionally, you can view the configuration of the cloned policy set using the displayPolicySet command.

    For example:

    wls:/jrfserver_domain/serverConfig>displayPolicySet() 
    
    Policy Set Details:
    -------------------
    Name:                app-only-web-service-policies
    Type of Resources:   Web Service Endpoint
    Scope of Resources:  Application("jaxws-sut")
    Description:         Default policies for application jaxws-sut
    Enabled:             true
    Policy Reference:    security : oracle/wss11_saml_or_username_token_with_message_protection_service_policy, enabled=true
    
  7. To write the contents of the current repository session to the repository, use the commitRepositorySession command.

    For example:

    wls:/jrfserver_domain/serverConfig>commitRepositorySession()
    The policy set app-only-web-service-policies is valid.
    Creating policy set app-only-web-service-policies in repository.
     
    Repository session committed successfully.
    

    Alternately, you can choose to cancel any changes by using the abortRepositorySession command, which discards any changes that were made to the repository during the session.

For more information about these WLST commands and their arguments, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Editing a Policy Set

The following sections describe how to edit an existing policy set using either Fusion Middleware Control or the command line interface WebLogic Scripting Tool, WLST.

Using Fusion Middleware Control

To edit an existing policy set:

  1. Navigate to the Policy Set Summary page as described in "Navigating to the Policy Set Summary Page".

  2. In the Policy Set Summary page, select the policy set that you want to edit and click Edit.

  3. In the Enter General Information page, select or clear the Enabled check box to enable or disable the policy set. You can also edit the policy set description.

    Note that the Name and Type of Resources fields are read-only.

  4. Click Next.

  5. In the Enter Resource Scope page, modify the scope as desired and click Next.

  6. In the Add Policy References page, modify the policy attachments as desired. When you are finished, click Validate to verify that the combination of polices selected is valid.

  7. Click Next to view the Policy Set Summary Page.

  8. Review the policy set summary information. If you are satisfied with the policy set, click Save.

Using WLST

To edit a policy set:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands".

  2. Begin a repository session using the beginRepositorySession command.

    For example:

    wls:/jrfserver_domain/serverConfig> beginRepositorySession()
    
    Repository session begun.
    
  3. Use the modifyPolicySet command to select an existing policy set to edit.

    modifyPolicySet(name)
    

    The latest version of the named policy set will be loaded into the current session. For example, to edit a policy set to add policies, use the following command:

    wls:/jrfServer_domain/serverConfig> modifyPolicySet('app-only-web-service-policies')
     
    The policy set is ready for modification in the session.
    
  4. Edit the policy set as desired. For example:

    • To add policies to the policy set, use the attachPolicySetPolicy command, identifying the policy by a specified URI using the uri argument.

      attachPolicySetPolicy(uri)
      

      To add the oracle/wsaddr_policy to the policy set, enter the following:

      wls:/jrfServer_domain/serverConfig> attachPolicySetPolicy('oracle/wsaddr_policy')
      
      Policy reference added.
      
    • To remove policies from the policy set, use the detachPolicySetPolicy command, identifying the policy by a specified URI using the uri argument.

      detachPolicySetPolicy(uri)
      

      To remove the oracle/wsaddr_policy from the policy set, enter the following:

      wls:/jrfServer_domain/serverConfig> detachPolicySetPolicy('oracle/wsaddr_policy')
      
      Policy reference removed.
      
    • To enable or disable a policy attachment in the policy set, use the enablePolicySetPolicy command, identifying the policy by a specified URI using the uri argument.

      enablePolicySetPolicy(uri,[enable=true])
      

      The default is true.

      To disable the oracle/wss11_saml_or_username_token_with_message_protection_service_policy, enter the following:

      wls:/jrfServer_domain/serverConfig> enablePolicySetPolicy('oracle/wss11_saml_or_username_token_with_message_protection_service_policy',false)
      
      Policy reference disabled.
      
  5. Validate the policy set using the ValidatePolicySet command.

    For example:

    wls:/jrfServer_domain/serverConfig> validatePolicySet()
     
    The policy set app-only-web-service-policies is valid.
    
  6. To write the contents of the current repository session to the repository, use the commitRepositorySession command.

    wls:/jrfServer_domain/serverConfig> commitRepositorySession()
     
    The policy set app-only-web-service-policies is valid.
    Updating policy set app-only-web-service-policies in repository.
     
    Repository session committed successfully.
    

    Alternately, you can choose to cancel any changes by using the abortRepositorySession command, which discards any changes that were made to the repository during the session.

For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Disabling a Globally Attached Policy

To explicitly disable a globally attached policy for specific endpoints, predefined policies that do not enforce any behavior are included with your Fusion Middleware installation. You can disable a globally, or externally, attached policy by attaching one of these predefined policies that contains the same category of assertions as the policy to be disabled. You can attach the no behavior policy either directly to an endpoint, or globally at a lower scope, such as at the application or module level. A policy that is directly attached takes precedence over a policy that is globally attached and a policy that is globally attached at a lower scope takes precedence over a policy that is globally attached at a higher scope. For more information, see "Calculating the Effective Set of Policies".

For example, if an authentication policy is globally attached to all service endpoints in a domain, you can disable it for a specific Web service endpoint by directly attaching the oracle/no_authentication_service_policy to the endpoint. Alternatively, to disable the authentication policy for only an application in the domain, you can create a policy set that attaches the oracle/no_authentication_service_policy only to the service endpoints in the application.

Note:

If the globally attached policy that you are disabling contains any other assertions, those assertions are disabled also. For example, if the global policy to be disabled is oracle/wss10_saml_token_with_message_protection_client_policy and you attach the no behavior oracle/no_authentication_service_policy to an endpoint at lower scope (or directly), both the authentication and the message protection assertions of the globally attached policy are disabled.

For details about directly attaching a policy to an endpoint, see "Attaching a Policy to a Single Subject". For more information about the no behavior policies, see "No Behavior Policies".

Note:

Do not delete these no behavior policies. All of the policies use the same no_behavior assertion. An assertion template is not provided, therefore if you delete the policies, there is no way to recreate them manually. If they are deleted by mistake, the only way to restore them is to rebuild the repository. For more information, see "Rebuilding the Oracle WSM Repository".

Enabling and Disabling a Policy Set

The following sections describe how to enable or disable a policy set using either Fusion Middleware Control or the command line interface WebLogic Scripting Tool, WLST.

Using Fusion Middleware Control

To enable or disable a policy set using Fusion Middleware Control, edit the policy set as described in "Editing a Policy Set". To enable the policy set if it is disabled, select the Enabled check box. To disable the policy set, clear the Enabled check box.

Note that you must click Next through steps 2 and 3, then click Save in Step 4 to save the updated policy set.

Figure 9-7 Enabling and Disabling a Policy Set

Description of Figure 9-7 follows
Description of "Figure 9-7 Enabling and Disabling a Policy Set"

Using WLST

To enable or disable a policy set:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands".

  2. Begin a repository session using the beginRepositorySession command.

    For example:

    wls:/jrfserver_domain/serverConfig> beginRepositorySession()
    
    Repository session begun.
    
  3. Specify the policy set to be modified using the modifyPolicySet command.

    For example:

    wls:/jrfServer_domain/serverConfig> modifyPolicySet('all-domains-default-web-service-policies')
     
    The policy set is ready for modification in the session.
    
  4. Use the enablePolicySet command to enable or disable a policy set.

    enablePolicySet([enable=true])
    

    Set the enable argument to true to enable a policy set if it is disabled. The default is true. Set the enable argument to false to disable a policy set.

    For example, to disable a policy set:

    wls:/jrfServer_domain/serverConfig> enablePolicySet(false)
     
    Policy set disabled.
    
  5. Validate the policy set using the ValidatePolicySet command.

    For example:

    wls:/jrfServer_domain/serverConfig> validatePolicySet()
     
    The policy set app-only-web-service-policies is valid.
    
  6. To write the contents of the current repository session to the repository, use the commitRepositorySession command.

    wls:/jrfServer_domain/serverConfig> commitRepositorySession()
     
    The policy set all-domains-default-web-service-policies is valid.
    Updating policy set all-domains-default-web-service-policies in repository.
     
    Repository session committed successfully.
    

    Alternately, you can choose to cancel any changes by using the abortRepositorySession command, which discards any changes that were made to the repository during the session.

For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Deleting a Policy Set

The following sections describe how to delete a policy set using either Fusion Middleware Control or the command line interface WebLogic Scripting Tool, WLST.

Using Fusion Middleware Control

To delete a policy set:

  1. Navigate to the Policy Set Summary page as described in "Navigating to the Policy Set Summary Page".

  2. In the Policy Set Summary page, select a policy set from the table and click Delete.

  3. A dialog box displays asking you to confirm the deletion. Click OK.

Using WLST

To delete a policy set:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands".

  2. Begin a repository session using the beginRepositorySession command.

    For example:

    wls:/jrfserver_domain/serverConfig> beginRepositorySession()
    
    Repository session begun.
    
  3. Optionally, list the policy sets in the repository using the listPolicySets command.

    wls:/jrfServer_domain/serverConfig> listPolicySets()
     
    Global Policy Sets in Repository:
      app-only-web-service-policies
      all-domains-default-web-service-policies
    
  4. Delete the policy set using the deletePolicySet command.

    deletePolicySet (name)
    

    For example:

    wls:/jrfServer_domain/serverConfig> deletePolicySet('app-only-web-service-policies')
     
    The policy set was deleted successfully in the session.
    
  5. To write the contents of the current repository session to the repository, use the commitRepositorySession command.

    wls:/jrfServer_domain/serverConfig> commitRepositorySession()
     
    Deleting policy set app-only-web-service-policies from repository.
     
    Repository session committed successfully.
    

    Alternately, you can choose to cancel any changes by using the abortRepositorySession command, which discards any changes that were made to the repository during the session.

For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Migrating Direct Policy Attachments to Global Policy Attachments

You can use the migrateAttachments WLST command to migrate direct (local) policy attachments to external global policy attachments if they are identical. Migrating identical policy attachments improves manageability by reducing the number of physical attachments that need to be maintained. A direct policy attachment is identical if its URI is the same as one provided by a global policy attachment, and if it does not have any configuration overrides. You cannot migrate the following:

Notes:

A direct attachment with an unscoped override will be migrated but an attachment with a scoped override will not. This is because after running the migrateAttachments command, the enforcement of the policies on all subjects remains the same, even though some policies are globally attached.

To migrate policy attachments:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands".

  2. Migrate the attachments using the migrateAttachments command. You can specify whether to force the migration (force), prompt for confirmation before each migration (prompt), or simply list the migrations that would occur (preview). If no mode is specified, the default is prompt.

    migrateAttachments(mode=None)
    

    For example, to prompt, by default, for confirmation of each potential attachment migration, enter the following command. Note in the output that there are identical global and direct policy attachments for the jaxws-sut application that can be migrated.

    wls:/jrfServer_domain/serverConfig> migrateAttachments()
     
    --------------------------------------------------------------------------------
    Application Path:    /jrfServer_domain/jrfServer/jaxws-sut-no-policy
    Web Service Name:    TestService
    Module Type:         web
    Module Name:         jaxws-service
    Port:                TestPort
     
    --------------------------------------------------------------------------------
    Application Path:    /jrfServer_domain/jrfServer/jaxws-sut
    Web Service Name:    TestService
    Module Type:         web
    Module Name:         jaxws-sut-service
    Port:                TestPort
    Policy Reference:    management : oracle/log_policy, enabled=true
                         security : oracle/wss_username_token_service_policy, enabled=true
                         (global) /policysets/global/migrate_example : oracle/wss_username_token_service_policy
     
    Migrate "oracle/wss_username_token_service_policy" (yes/no/cancel)? yes
    "oracle/wss_username_token_service_policy" was migrated successfully.
    

    For more information about the arguments for this command, see "Web Services Custom WLST Commands" in WebLogic Scripting Tool Command Reference.

Defining the Type and Scope of Resources

The resource scope for a policy set describes a collection of related resources, from the domain-level down to the application module-level or SOA composite-level, that are running in the same enterprise topology nodes (based on the node's names).

To attach policies globally across a set of resources, you must specify the type of policy subjects to which the policy set applies and the scope of resources within the topology of the enterprise.

Resource Type

In Fusion Middleware Control, you select the resource type from a menu when you are creating a policy set. When you create a policy set using WLST, you must use specific abbreviations for these resource types. Table 9-1 lists the type of resources that you select in EM, the abbreviations that are required in WLST, and the resource scopes that are valid for each resource type.

Table 9-1 Policy Subject Resource Types

Fusion Middleware Control
WLST Valid Resource Scope

SOA Component

sca-component

  • Domain

  • Server Instance

  • SOA Composite

SOA Reference

sca-reference

  • Domain

  • Server Instance

  • SOA Composite

SOA Service

sca-service

  • Domain

  • Server Instance

  • SOA Composite

Web Service Endpoint

ws-service

  • Domain

  • Server Instance

  • Application

  • Application Module

Web Service Client

ws-client

  • Domain

  • Server Instance

  • Application

  • Application Module

Web Service Connection

ws-connection

  • Domain

  • Server Instance

  • Application

  • Application Module

Asynchronous Callback Client

ws-callback

  • Domain

  • Server Instance

  • Application

  • Application Module


Resource Scope

In Fusion Middleware Control, you specify the scope by entering a pattern string that represents the name associated with the resource scope. For example, to attach a policy set to all Web service endpoints in a domain, you enter a pattern that represents the name of the domain in the Domain Name field.When specifying the resource scope in WLST, you need to use a supported expression for each scope. The supported expressions are described in Table 9-2. These expressions are required for the following arguments:

  • attachTo argument of the createPolicySet and clonePolicySet commands

  • expression argument of the attachPolicySet command

For both Fusion Middleware Control and WLST, you can enter the complete name, or a partial value using wildcards. An asterisk (*) is permitted as a wildcard character anywhere within the string to match any number of characters at its position. You can specify multiple wildcards at any position within the string. For example, for the domain name jrf_domain, you can enter jrf*, or *rf*domain, or any number of combinations. You need to provide only a single pattern for a scope. If you do not specify a pattern string for a resource scope, asterisk (*) is assumed. You can use single or double quotes. If multiple functions are provided, then all of the expressions must match for the policy set to be considered attached to the policy subject.

The following is a list of the supported expressions for the resource scope.

Table 9-2 Supported Expressions for the Resource Scope

Supported Expression Description

Domain("expression")

This value will be matched against a policy subject based on the management domain in which it is deployed.

Server("expression")

This value will be matched against a policy subject based on the server instance in which it is deployed.

Application("expression")

This value will be matched against a policy subject based on the name of the application in which it is located.

Module("expression")

This value will be matched against a policy subject based on the name of the application module in which it is located.

Composite("expression")

This value will be matched against a policy subject based on the name of the SOA composite in which it is located.

Note: For a composite, the expression should use the composite name only, for example:

Composite("*Basic_SOA_Client*")

Do not include the SOA partition or composite revision number in the expression.


Examples

The following examples demonstrate how to create policy sets using different resource types and scopes.

Example 9-1 creates a policy set for an asynchronous callback client (ws-callback) resource type. In this example, the policy set is attached at a specific application scope, and applies to all services that satisfy the filter condition (Domain AND Server AND Application.

Example 9-1 Asynchronous Callback Client Resource Type Policy Set

beginRepositorySession()
createPolicySet('Async callback client', 'ws-callback', 'Domain('FinancialDomain') and Server ('*payable*') and Application('Expense*')', 'Global policy for asynchronous callback client', true)
attachPolicySetPolicy('oracle/wss10_saml_token_client_policy')
validatePolicySet()
commitRepositorySession()
displayPolicySet('Async callback client')

Example 9-2 creates a policy set named web_connection_cost_service for a Web service connection (ws-connection) resource type. In this example, the policy set is attached at a specific application module scope, and applies to all services that satisfy the filter condition (Domain AND Server AND Application AND Module).

Example 9-2 Web Service Connection Resource Type Policy Set

beginRepositorySession()
createPolicySet('web_connection_cost_service', 'ws-connection',  'Domain("SCMDomain") and Server("*CostManagementServer*") and Application("ScmCst*") and Module("*Costs")', enable=true)
attachPolicySetPolicy('oracle/wss10_saml_token_client_policy')
validatePolicySet()
commitRepositorySession()
displayPolicySet('web_connection_cost_service')

Validating a Policy Set

In addition to validating that the policy set adheres to the rules described in "Validating Policy Subjects", policy set validation also performs the following checks:

Note:

To ensure there are no conflicts between policy attachments, you can use WLST commands to determine if Web service endpoints contain a valid configuration. For details, see "Diagnosing Policy Attachment Issues Using WLST".

Calculating the Effective Set of Policies

To support the attachment of policies both directly and externally and avoid breaking existing deployments, the determination of the effective set of policies for a subject will take into account the category of assertions within each policy. If a subject has a directly attached policy with an assertion of a given category, then any policies with assertions of the same category referenced by an external policy set will be excluded from the effective set of policies for a subject. This process will be repeated at each subject scope. Narrower/lower scopes have a higher priority than broader/higher scopes. For additional information about resource scopes, see "Defining the Type and Scope of Resources"

For example, a policy attachment at the application scope will be excluded from the effective set of policies for a subject if it contains assertions of the same category as a policy that was attached at the module scope or attached directly. However, policies with overlapping assertion categories attached at the same scope (or directly) will still be included in the effective set of policies, even if they result in an invalid configuration. For details about the number and combination of policies that can be attached to a subject, see "Validating Policy Subjects".

The effective set of policies calculation will take into account the status of each policy attachment. If a policy, a policy reference in a policy set, or a policy set is disabled, it is removed from the effective set of policies for a subject.

Using this calculation mechanism, a globally attached policy can be overridden by attaching a policy containing assertions with the same categories either directly or at a lower scope. As a special case of this, a globally attached policy can be effectively disabled for a specific subject by attaching a policy with the same category of assertions that does not enforce any behavior. For more information about these policies that do not enforce any behavior, see "No Behavior Policies".

Note:

The amount of time it takes for a global policy attachment to take effect is determined by the Oracle WSM policy accessor and policy cache property settings. By default, this delay can be up to a maximum of 11 minutes. To reduce the amount of the delay, you can tune the following cache property settings:
  • Policy Accessor

    cache.refresh.initial, default 600000 milliseconds (10 minutes)

    cache.refresh.repeat, default 600000 milliseconds (10 minutes)

  • Policy Cache

    cache.tolerance, default is 60000 milliseconds (1 minute)

For details about tuning these properties, see "Configuring Platform Policy Properties".