Manage policy sets and bindings for services references using the administrative console
Use this administrative console task to manage policy sets and bindings for the service reference, its endpoints, and operations.
Before completing this task, install one or more Java API for API for XML-based Web Services (JAX-WS) web services, that contain at least one client service reference.
We have developed a web service containing all the necessary artifacts and deployed the web services application into the application server instance. Now, we can attach or detach policy sets and manage the associated bindings.
When we configure the policy set attachments for a service reference, we can override the policy set attachments inherited from the service client using the administrative console. Attach a policy set and binding for a service reference that is different from the policy set attachment for the service client. We can also specify to not attach a policy set to a service reference, even if a policy set is attached to the service client.
The default behavior is that a service reference, and its endpoints and operations, inherits the policy set attachment of the corresponding resources of the service. Service references are only valid for service clients.
Use the administrative console, we can configure the service reference to either inherit policy set and bindings configuration from the service client or to specify individual settings for the service reference by attaching policy sets and bindings that are different from the policy sets and bindings attached to the service client.
The policy set information is displayed in the Attached Policy Set column. If a policy set is directly attached, then the policy set name is displayed; for example, WS-I RSP. If there is no policy set attached, and a policy set is attached at a higher level or to the service client, then the word inherited in parentheses is appended to the policy set name: WS-I RSP (inherited). If there is no policy set attached directly or at a higher level, then None is displayed.
Every attachment of a policy set to a service artifact has an assigned binding. The binding information is displayed in the Binding column. The Binding column can contain the following values:
- Not applicable. There is no policy set attached, either directly, to a service client resource, or to a higher level service reference resource.
- Binding_name or Default. The binding name is displayed if a policy set is attached directly and an application-specific binding or a general binding is assigned, for example, MyBindings1. Default is displayed if a policy set is attached directly but the service reference resource uses the default bindings.
- Binding_name (inherited) or Default (inherited). A service resource inherits the bindings from an attachment to a service client resource or a higher level service reference resource.
There are two types of bindings, application specific bindings and general bindings.
Application specific binding
Create application specific bindings only at a policy set attachment point. These bindings are specific to and constrained to the characteristics of the defined policy. Application specific bindings are capable of providing configuration for advanced policy requirements, such as multiple signatures; however, these bindings are only reusable within an application. Furthermore, application specific bindings have very limited reuse across policy sets.
When we create an application specific binding for a policy set attachment, the binding begins in a completely unconfigured state. We must add each policy, such as WS-Security or HTTP transport, to override the default binding and fully configure the bindings for each policy that we have added. For WS-Security policy, some high-level configuration attributes such as TokenConsumer, TokenGenerator, SigningInfo, or EncryptionInfo might be obtained from the default bindings if they are not configured in the application specific bindings.
For service clients, we can only create application specific bindings by selecting...
-
Assign Binding > New Application Specific Binding for service client resources that have an attached policy set
See service clients policy sets and bindings collection. Similarly, for service clients, we can only create application specific bindings by selecting...
-
Assign Binding > New Application Specific Binding for service client resources that have an attached policy set
See service client policy set and bindings collection.
General bindings
General bindings can be configured to be used across a range of policy sets and can be reused across applications and for trust service attachments. Though general bindings are highly reusable, they are however not able to provide configuration for advanced policy requirements, such as multiple signatures. There are two types of general bindings:
- General provider policy set bindings
- General client policy set bindings
Create general client policy set bindings by accessing...
-
Services > Policy sets > General provider policy set bindings > New
...in the general provider policy sets panel or by accessing...
-
Services > Policy sets > General client policy set bindings > New
...in the general client policy set and bindings panel. See defining and managing service client or provider bindings.
Depending on the assigned security role when security is enabled, we might not have access to text entry fields or buttons to create or edit configuration data. Review the administrative roles documentation to learn more about the valid roles for the application server.
Mixed-version environment: In a mixed cell environment, the following limitations
apply to service reference attachments or resource attachments specified in name-value pair format:
- We must not create these types of attachments for applications deployed on an application server that is prior to WAS v8.0. Service reference attachments are only supported on WAS v8.0 and later.
- An application containing these types of attachments must not be deployed on an application server that is prior to WAS v8.0.
- If an application that is deployed in a cluster environment contains these types of attachments, we must not add a member application server that is prior to WAS v8.0 to the cluster.
mixv
Tasks
- Open the administrative console.
- In the navigation pane, click...
Applications > Application Types > WebSphere enterprise applications >Service_client_application_instance > Service clients.
- Select a service references and view the associated service reference, endpoints, and operations.
- We can perform any of the following actions:
- Click Inherit, to clear existing policy set and binding settings for the service reference and to use policy set attachments defined by the service client. By default, a service reference, and its endpoints and operations, inherits the policy set attachment of the corresponding resources of the service.
- Click Override, to override existing policy set and binding settings for the service client and to either define separate policy sets and bindings for the service reference or to specify that a policy set is not attached to the service reference.
- Click Attach Client Policy Set, to attach a policy set to a selected service reference, endpoint, or operation. This button is active only after we have clicked the Override button.
- Click, Detach Client Policy Set, to detach a policy set from a list of attached policy sets for a service reference, endpoint, or operation. The service name is the service client reference in the application. This button is active only after we have clicked the Override button.
- Click Assign Binding to select from
a list of available bindings for the selected policy set attachment.
This button is active only after we have clicked the Override button.
All the bindings are listed along with the following options:
Bindings Description Default Default binding for the selected service reference, endpoint, or operation. We can specify client and provider default bindings to be used at the cell level or global security domain level, for a particular server, or for a security domain. The default bindings are used when an application-specific binding has not been assigned to the attachment. When we attach a policy set to a service resource, the binding is initially set to the default. If we do not specifically assign a binding to the attachment point using this Assign Binding action, the default specified at the nearest scope is used. For any policy set attachment, the run time checks to see if the attachment includes a binding. If so, it uses that binding. If not, the run time checks in the following order and uses the first available default binding:
- Default general bindings for the server
- Default general bindings for the domain in which the server resides
- Default general bindings for the global security domain
New Application Specific Binding Select this option to create a new application-specific binding for the policy set attachments. The new binding we create is used for the selected resources. If we select more than one resource, ensure that all selected resources have the same policy set attached. Client sample Select this option to use the Client sample binding. Client sample V2 Select this option to use the Client sample V2 binding when we are using either the Kerberos V5 WSSecurity default or the TrustServiceKerberosDefault policy sets. Saml Bearer Client sample Select this option to use the Saml Bearer Client sample. The Saml Bearer Client sample extends the Client sample binding to support SAML Bearer token usage scenarios. We can use this sample with any of the SAML bearer token default policy sets. Saml HoK Symmetric Client sample Select this option to use the Saml HoK Symmetric Client sample. The Saml HoK Symmetric Client sample extends the Client sample binding to support SAML holder-of-key (HoK) symmetric key token usage scenarios. Use this sample with one of the SAML HoK Symmetric key default policy sets: either SAML11 HoK Symmetric WSSecurity default or SAML20 HoK Symmetric WSSecurity default. - To close the drop-down list for the assign binding action, click Assign Binding.
- (optional) Display inherit policy set attachments confirmation. Selecting this check box enables the inherit policy set attachments confirmation panel. We must expand the Preferences section to select this check box.
When we finish this task, we have specified policy sets and bindings for a service reference.
Example
Suppose that we have configured a service client reference, EchoService12 in the application instance, WSSampleClientSei. You want to attach the WSSecurity default policy to the EchoService12Port endpoint of the EchoService12 service client reference. We must override the current service client policy set and bindings. Complete the following steps:
- Locate EchoService12 in the Applications > Application Types > WebSphere enterprise applications >WSSampleClientSei > Service clients collection. Alternatively, we can locate EchoService12 in the Services > Service clients collection.
- Click Override, to override the service client attachments.
- Select the check box for the EchoService12Port resource, and click Attach Client Policy Set.
- Select the WSSecurity default policy from the list.
- Click Save to save the changes to the master configuration.
Suppose later, we want your service reference, EchoService12 to not use the WSSecurity default policy. Instead, we want to use the policy sets and attachments from the service client, WSSampleClientSei. Complete the following steps:
- Locate EchoService12 in the Applications > Application Types > WebSphere enterprise applications >WSSampleClientSei > Service clients collection. Alternatively, we can locate EchoService12 in the Services > Service clients collection.
- Click Inherit, to clear the existing policy set and binding settings for the service reference and to use policy set attachments defined by the service client.
- Click OK on the Inherit policy sets page to confirm to inherit the policy set attachments defined by the service client. We can optionally select the check box to not show the inherit confirmation page in the future.
- Click Save to save the changes to the master configuration.
What to do next
We can now proceed to manage other service references for the service client or to manage policy sets and bindings for service clients at the application level using the administrative console.
Subtopics
- Service reference settings
Use this administrative console page to manage the settings for our service references. Service references can inherit the policy sets and bindings of the service client or we can specify policy sets and bindings that are different from those of the service client.