+

Search Tips   |   Advanced Search

Set the client.policy using 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 that contains 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 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 that contains 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 Learn about WS-Policy.

We 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 to apply dynamically the provider policy that it obtains from a registry at the service level. Endpoints and operations inherit their policy configuration from the relevant service. We cannot administer the client to apply dynamically the provider policy that it obtains from a registry at the application level.

This page describes how to configure the client.policy to use a service provider policy that is stored in a registry by using the admin console. We can also configure the client.policy to use a service provider policy that is stored in a registry by using wsadmin commands.

 

  1. If there is a secure connection using the SSL protocol between the client and the registry, ensure that trust is established between the appserver and the registry server so that the Web service client application can access the registry. 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. Add the signer certificate to the trust store that the client uses, for example, the default trust store for the node. See Add a signer certificate to a keystore.

  2. From the navigation pane of the admin console, click Applications > Application Types > WebSphere enterprise apps.

  3. Click the Web service client application that you wish to configure.

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

  5. In the row for the service where you 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.

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

    • Provider policy only. Set 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. Set 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.

  7. Click HTTP GET request.

  8. 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.

    The following example shows a typical URL:

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

  9. Click OK.

  10. If the registry requires authentication using the HTTP protocol, that is, it needs a valid user name and password, configure a policy to authenticate outbound service requests to the registry.

    The HTTP and HTTPS credentials are used for both the Web service endpoint and the registry. Therefore, it is advisable to secure any authorization credentials and ensure that those credentials are not sent to an unauthorized endpoint.

    1. Create an application policy set that contains the HTTP Transport policy. See the relevant steps in Set the HTTP transport policy.

    2. Attach the new policy set to the client service endpoint. See Attach a policy set to a service artifact.

    3. Assign the binding named Client sample to the client. See Manage policy sets and bindings for service clients at the application level .

    4. Set the HTTP transport client bindings for the binding named Client sample and enter the user name and password to authenticate outbound service requests. See the relevant steps in Set the HTTP transport policy.

  11. Save the changes to the master configuration.

 

Results

The Web app 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 you 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 concepts


Web service clients and policy configuration using the service provider policy

 

Related tasks


Learn about WS-Policy
Deploy Web services applications onto appservers
Add a signer certificate to a keystore
Manage policy sets and bindings for service clients at the application level
Set the HTTP transport policy
Attach a policy set to a service artifact
Set the client.policy based on a service provider policy using wsadmin
Set a service provider to share its policy configuration
Use WS-Policy to exchange policies in a standard format

 

Related


Policies applied settings