+

Search Tips   |   Advanced Search

Configure the client policy to use a service provider policy from a registry

An application that is a web service client can obtain the policy configuration of a web service provider from a registry, such as WebSphere Service Registry and Repository (WSRR), and use this information to establish a policy configuration that is acceptable to both the client and the service provider.

We have developed a web service client containing all the necessary artifacts, and deployed the web services application into the application server instance. If we require them, we have attached the policy sets and managed the associated bindings.

The Web Services Description Language (WSDL) for the policy of the service provider, and its corresponding policies and policy attachments, are stored in a registry such as WSRR. That policy must contain its policy configuration in WS-PolicyAttachments format. The client must be able to support those provider policies.

The registry must support the use of HTTP GET requests to publish WSDL containing WS-Policy attachments, for example WSRR v6.2 or later.

For a list of WS-Policy assertion specifications and WS-Policy domains that are supported, see the WS-Policy topic.

You can administer the client to configure itself dynamically at run time, based on the policy of a service provider that is held in a registry. We can administer the client at the service or service reference level to dynamically apply the provider policy that it obtains from a registry. By default, endpoints and operations inherit their policy configuration from the relevant service. However, it is possible to configure a service reference to override the service, in which case the endpoints and operations inherit their policy configuration from the service reference. We cannot administer the client to apply dynamically the provider policy that it obtains from a registry at the application level.

We can configure the client policy to use a service provider policy stored in a registry using the administrative console. We can also configure the client policy to use a service provider policy stored in a registry using wsadmin commands.


Tasks

  1. From the navigation pane of the administrative console, click Applications > Application Types > WebSphere enterprise applications.

  2. Click the web service client application to configure.

  3. Click [Web services properties] Service client policy sets and bindings.

  4. In the row for the service where we want to apply the policy, click the link in the Policies Applied column. We cannot apply the policy at application level. The Policies Applied pane is displayed.

  5. Select one of the following options from the drop-down list:

    • Provider policy only. Configure the client based solely on the policy of the service provider. This option is available when a client policy set is not attached.
    • Client and provider policy. Configure the client based on both the client policy set and the policy of the service provider. This option is available when a client policy set is attached.

    The other options in the list do not apply to this task.

  6. Click HTTP GET request.

  7. Click Specify request target, then enter the URL for the location of the provider policy in the field, that is, the address in the repository for the WSDL and policy. For information about using WSRR to retrieve a WSDL document with embedded policies, and therefore obtain the required URL, see the WSRR documentation.

    Typical URL:

      https://www.wsrr.host/WSRR/6.2/PolicyService/WSDL?bsrURI=3b9b493b-278f-4f64.ba3f.dabd30da3f7e

  8. Click OK.

  9. Optional: If there is a secure connection that uses the SSL protocol between the client and the registry, ensure that trust is established between the application server and the registry server. To access the registry, the client uses the SSL transport policy that is part of its service-level application policy. For example, for WSRR, we can enter the URL for the WSRR server in a browser window. If the WSRR server is not already trusted, a message is displayed stating that the security certificate is not trusted. To establish trust, use the following steps:

    1. Retrieve and store the X509 certificate from the WSRR server. Use the options on the message to view details of the certificate and save those details to a file, using distinguished encoding rules (DER) encoded binary format.

    2. Find out the key store that the client uses, that is, the key store that is shown by the SSL security transport bindings of the client application policy set. See Configure the SSL transport policy. For example, the key store might be the default trust store for the node.

    3. Add the signer certificate that you saved in step a. to the key store that the client uses. See Add a signer certificate to a keystore.

  10. Optional: To access the registry, the client uses the transport policy that is part of its service-level application policy. If the registry requires authentication using the HTTP protocol, configure a valid user name and password as part of the application-level transport policy binding configuration. It is advisable to secure any authorization credentials, because they are used for interactions with both the web service endpoint and the registry.

    1. Ensure that the client has a policy set containing the HTTP transport policy attached to the application or service level. See the relevant steps in Manage policy sets and bindings for service clients at the application level .

    2. Configure the HTTP transport client bindings for the binding named Client sample and enter the user name and password that the registry requires to authenticate outbound service requests. See the relevant steps in Configure the HTTP transport policy.

  11. Save changes to the master configuration.

The web application client-side policy is calculated when it is required at run time, based either on the policy of the service provider, or on the client policy set and the policy of the service provider, depending on which option we selected. This calculated policy is known as the "effective policy" and is cached as a runtime configuration. The effective policy is used for subsequent outbound web service requests to the endpoint or operation for which the dynamic policy calculation was performed. The policy set configuration of the client does not change.

The provider policy that the client holds for a service is refreshed the first time that the web service is invoked after the application is loaded. After that, the provider policy is refreshed when the application restarts, or if the application explicitly invokes a refresh. When the provider policy is refreshed, the effective policy is recalculated.


Related:

  • WS-Policy
  • Web service clients and policy configuration to use the service provider policy
  • Deploy web services applications onto application servers
  • Configure the SSL transport policy
  • Add a signer certificate to a keystore
  • Manage policy sets and bindings for service clients at the application level
  • Configure the HTTP transport policy
  • Configure the client policy to use a service provider policy by
  • Configure a service provider to share its policy configuration
  • Policies applied settings