View the detail of a service provider and managing policy sets using the administrative console

View the detail of a service provider and managing policy sets using the administrative console

Use this administrative console task to view the detail of the service provider and to manage the policy sets for the service, its endpoints and operations. We can also use this page to manage policy sets and bindings or to access additional information for a Service Component Architecture (SCA) composition unit for service providers.
Before completing this task, we need to install one or more JAX-WS or SCA artifacts.

You 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.
The policy set information is displayed in the Attached Policy Set column. If a policy set is directly attached, then the policy set name appears; for example, WS-I RSP is displayed. If there is no policy set attached, and a policy set is attached at a higher level, 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 or to a higher level service 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 resource uses the default bindings.

Binding_name (inherited) or Default (inherited). A service resource inherits the bindings from an attachment to a higher level resource.

In Version 7.0 and later, there are two types of bindings, application specific bindings and general bindings.
Application specific binding
We can 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 creating 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 providers, we can only create application specific bindings by selecting Assign Binding > New Application Specific Binding for service provider resources that have an attached policy set. See service providers 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 were introduced in Version 7.0. These 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

We can create general provider 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. General provider policy set bindings might also be used for trust service attachments.
Depending on the assigned security role when security is enabled, you 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.

Open the administrative console.

In the navigation pane, expand Services > Service providers >Service_provider_application_instance Service providers.

[Optional] Use the WSDL document link under the Additional Properties section to view the WSDL for the service. The Application and Module links provide access to the application and module settings page.
For SCA service providers, the Additional Properties section does not show the WSDL document link, instead, there is a composition unit link. Click Composition unit to see the composition unit detail page.

Select one or more service, endpoints and operations of interest and view the associated service, endpoints and operations.

Do one or more of the following actions:

Click Attach, to attach a policy to a selected service, endpoint or operation.

Click Detach, to detach a policy set from a list of attached policy sets for a service, endpoint or operation.

Click Assign Binding to select from a list of available bindings for the selected policy set attachment. All the bindings are listed along with the following options:

Bindings Description
Default Default binding for the selected service, 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 you 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 runtime checks to see if the attachment includes a binding. If so, it uses that binding. If not, the runtime 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.
Provider sample Select this option to use the Provider sample binding.
Provider sample V2 Select this option to use the Provider sample V2 binding when we are using either the Kerberos V5 WSSecurity default or the TrustServiceKerberosDefault policy sets.
Saml Bearer Provider sample Select this option to use the Saml Bearer Provider sample. The Saml Bearer Provider sample extends the Provider 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 Provider sample Select this option to use the Saml HoK Symmetric Provider sample. The Saml HoK Symmetric Provider sample extends the Provider sample binding to support SAML holder-of-key (HoK) symmetric key token usage scenarios. We can 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.

Results
When you finish this task, a policy set is attached, detached or a binding is assigned to the service artifact.

Example
You have configured a service provider, EchoService12 in the application instance, WSSampleServicesSei. Now to attach the WS-Security policy to the EchoService12Port endpoint of the EchoService12 service provider. First locate EchoService12 in the Services > Service providers collection. Click the EchoService12 service provider. Select the check box for the columoService12Port resource. Click Attach and select WSSecurity default policy from the list. Click Save, to save the changes to the master configuration.

What to do next
We can now proceed to manage policy sets and bindings for service providers at the application level using the administrative console.

Subtopics

Service provider settings
Use the Service provider settings page to manage the settings for the service providers. We can attach and detach policy sets to an application, its service, endpoints or operations. We can create new bindings, or use bindings that we have already created for an attached policy set. We can view or change whether the service provider can share its current policy configuration.

Related tasks

View detail of a service client and managing policy sets using the administrative console
Manage policy sets and bindings for service providers at the application level using the administrative console
View service providers at the cell level using the administrative console
View service providers at the application level using the administrative console
Implement web services applications with JAX-WS
Implement web services applications from existing WSDL files with JAX-WS

Service client settings
Service provider policy sets and bindings collection
Administrative roles

Bindings	Description
Default	Default binding for the selected service, 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 you 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 runtime checks to see if the attachment includes a binding. If so, it uses that binding. If not, the runtime 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.
Provider sample	Select this option to use the Provider sample binding.
Provider sample V2	Select this option to use the Provider sample V2 binding when we are using either the Kerberos V5 WSSecurity default or the TrustServiceKerberosDefault policy sets.
Saml Bearer Provider sample	Select this option to use the Saml Bearer Provider sample. The Saml Bearer Provider sample extends the Provider 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 Provider sample	Select this option to use the Saml HoK Symmetric Provider sample. The Saml HoK Symmetric Provider sample extends the Provider sample binding to support SAML holder-of-key (HoK) symmetric key token usage scenarios. We can 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.