Set V6.1 server-specific default bindings for policies using wsadmin

Set V6.1 server-specific default bindings for policies using wsadmin

Use the Jython or Jacl scripting language to customize WAS V6.1 server-specific default bindings for policies to match the installation environment or requirements.
Server-specific default bindings use the WAS V6.1 namespace. When admin security is enabled, verify that you use the correct admin role, as the following table describes:

Table 1. Administrative roles

Administrative role Authorization
Administrator The Administrator role must have cell-wide access to configure bindings. If we have access to a specific resource only, we can configure bindings for the resource for which we have access. Only the Administrator role can edit binding attributes.
Configurator The Configurator role with cell-wide or resource specific access can assign or unassign bindings, but cannot edit attributes.
Deployer The Deployer role with cell-wide or resource specific access can assign or unassign bindings, but cannot edit attributes.
Operator The Operator role can view, but cannot configure bindings.
Monitor The Monitor role can view, but cannot configure bindings.

For transitioning users: In WAS Version 7.0, the security model is enhanced to a domain-centric security model instead of a server-based security model. The configuration of the default global security (cell) level and default server level bindings has also changed in this version of WAS ND. In the WAS V 6.1 Feature Pack for Web Services, we can configure one set of default bindings for the cell and optionally configure one set of default bindings for each server. In V7.0, we can configure one or more general service provider bindings and one or more general service client bindings. After we have configured general bindings, we can specify which of these bindings is the global default binding. We can also optionally specify general binding that are used as the default for an appserver or a security domain. trns
To support a mixed-cell environment, WAS supports V7.0 and V6.1 bindings. General cell-level bindings are specific to V7.0 Application-specific bindings remain at the version that the application requires. When the user creates an application-specific binding, the appserver determines the required binding version to use for application. Use the following guidelines to manage bindings in the environment:

To display or modify default V6.1 bindings, V7.0 trust service bindings, or to reference bindings by attachment for an application, specify the attachmentId and bindingLocation parameters with the getBinding or setBinding commands.
To use or modify general V7.0 bindings, specify the bindingName parameter with the getBinding or setBinding commands.
To display the version of a specific binding, specify the version attribute for the getBinding command.

Use a V6.1 binding for an application in a V7.0 environment if:

The module in the application is installed on at least one Web Services Feature Pack server.
The application contains at least one V6.1 application-specific binding. The appserver does not assign general bindings to resource attachments for applications that are installed on a Web Services Feature Pack server. All application-specific bindings for an application must be at the same level.

General service provider and client bindings are not linked to a particular policy set and they provide configuration information that we can reuse across multiple applications. We can create and manage general provider and client.policy set bindings and then select one of each binding type to use as the default for an appserver. Setting the server default bindings is useful if we want the services that are deployed to a server to share binding configuration. We can also accomplish this sharing of binding configuration by assigning the binding to each application deployed to the server or by setting default bindings for a security domain and assigning the security domain to one or more servers. We can specify default bindings for the service provider or client that are used at the global security (cell) level, for a security domain, for a particular server. The default bindings are used in the absence of an overriding binding specified at a lower scope. The order of precedence from lowest to highest that the appserver uses to determine which default bindings to use is as follows:

Server level default
Security domain level default
Global security (cell) default

The sample general bindings that are provided with the product are initially set as the global security (cell) default bindings. The default service provider binding and the default service client bindings are used when no application specific bindings or trust service bindings are assigned to a policy set attachment. For trust service attachments, the default bindings are used when no trust specific bindings are assigned. If we do not want to use the provided Provider sample as the default service provider binding, we can select an existing general provider binding or create a new general provider binding to meet the business needs. Likewise, if we do not want to use the provided Client sample as the default service client binding, we can select an existing general client binding or create a new general client binding.

Launch the wsadmin scripting tool using Jython.
Determine the policy to update. To view a list of all available policies for a specific policy set, use the listPolicyTypes command...
AdminTask.listPolicyTypes('[-policySet WSAddressing]')

Retrieve the current binding configuration for the policy to determine the attributes to update. Use the getBinding command to display a Properties object containing all configuration attributes for a specific policy binding. Specify a Properties object for the -bindingLocation parameter using the property names node and server. For example:
AdminTask.getBinding('-policyType WSAddressing -bindingLocation "[[node node1] [server server1]]"')

To return a specific configuration attribute for the policy, use the -attributes parameter. For example, enter this command to determine if the policy is enabled:
AdminTask.getBinding('-policyType WSAddressing -bindingLocation "[[node node1] [server server1]]" -attributes "[[preventWLM]]"')

The command returns a properties object which contains the value of the requested attribute, preventWLM.
Edit the binding configuration. Use the setBinding command to update the binding configuration for a policy. To specify that we are editing a server-specific default binding, set the -bindingLocation parameter using the node and server property names in a Properties object. We can further customize the binding with the following optional parameters:

Table 2. Optional parameters

Parameter Description Data type
-policyType Policy of interest. String, optional
-remove Use this parameter to remove a server-level binding configuration. The default value for the -remove parameter is false. Boolean, optional
-attributes Attribute values to update. This parameter can include all binding attributes for the policy or a subset to update. The -attributes parameter is not required if we are removing your server-level binding. Properties, optional
-replace Specifies whether to replace all of the existing binding attributes with the attributes specified in the command. Use this parameter to remove optional parts of the configuration for policies with complex data. The default value is false. Boolean, optional
-domainName Domain name for the binding. Use this parameter to scope a binding to a domain other than the global security domain. String, optional

You should always specify the -attributes parameter when editing the configuration.
The following example disables workload management within the server-specific default binding for the WSAddressing policy:
AdminTask.setBinding('-policyType WSAddressing -bindingLocation "[ [server server1] [node node01] ]" -attributes "[preventWLM false]"')

Save the configuration changes.
AdminConfig.save()

Related tasks

Create application specific bindings for policy set attachment
Set application and system policy sets for Web services using scripting
Create policy sets using wsadmin
Add and remove policies using wsadmin
Create policy set attachments using wsadmin
Manage policy set attachments using wsadmin
Remove policy set attachments using wsadmin
Manage policy sets

Related

PolicySetManagement

Administrative role	Authorization
Administrator	The Administrator role must have cell-wide access to configure bindings. If we have access to a specific resource only, we can configure bindings for the resource for which we have access. Only the Administrator role can edit binding attributes.
Configurator	The Configurator role with cell-wide or resource specific access can assign or unassign bindings, but cannot edit attributes.
Deployer	The Deployer role with cell-wide or resource specific access can assign or unassign bindings, but cannot edit attributes.
Operator	The Operator role can view, but cannot configure bindings.
Monitor	The Monitor role can view, but cannot configure bindings.

Parameter	Description	Data type
-policyType	Policy of interest.	String, optional
-remove	Use this parameter to remove a server-level binding configuration. The default value for the -remove parameter is false.	Boolean, optional
-attributes	Attribute values to update. This parameter can include all binding attributes for the policy or a subset to update. The -attributes parameter is not required if we are removing your server-level binding.	Properties, optional
-replace	Specifies whether to replace all of the existing binding attributes with the attributes specified in the command. Use this parameter to remove optional parts of the configuration for policies with complex data. The default value is false.	Boolean, optional
-domainName	Domain name for the binding. Use this parameter to scope a binding to a domain other than the global security domain.	String, optional