WAS v8.5 > Script the application serving environment (wsadmin) > Welcome to scripting for web services > Configure web services applications using wsadmin.sh > Configure application and system policy sets for web services using wsadmin.sh

Configure application-specific and system bindings using wsadmin.sh

Use the Jython or Jacl scripting language to edit custom application bindings and system bindings for policies to match your installation environment or system requirements.

Before using the commands in this topic, verify that you are using the most recent version of wsadmin. The policy set management commands that accept a properties object as the value for the attributes or bindingLocation parameters are not supported on previous versions of wsadmin. For example, the commands do not run on a v6.1.0.x node.

When administrative security is enabled, verify that we use the correct administrative role, as the following table describes:

Administrative roles. The administrative role determines if we can configure, modify or assign bindings.

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.
Binding configurations are environment- and platform-specific information such as keystore information, keys used for signature and encryption, or authentication information. We can use the default binding for each policy set or define application-specific bindings within an application.

There are three types of bindings to use with your policy sets, including cell-level, application server level, and application-level. Default bindings are used at the cell-level or application server level. This topic refers to system binding information or bindings that are defined at the application level, which overrides the cell-level or application server level definition.

Use default bindings only to develop and test applications. You must change signing and encryption keys before using your bindings in a production environment.

For transitioning users: In WAS v7.0 and later, the security model was 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 the product. In the WAS v6.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 and later, 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 used as the default for an application server 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 and later Application-specific bindings remain at the version the application requires. When the user creates an application-specific binding, the application server determines the required binding version to use for application.

Use the following guidelines to manage bindings in the environment:

Use a v6.1 binding for an application in a v7.0 and later environment if:

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 application server. Setting the server default bindings is useful if you want the services 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 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 the application server uses to determine which default bindings to use is as follows:

  1. Server level default
  2. Security domain level default
  3. Global security (cell) default

The sample general bindings 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 your 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.

  1. Launch the wsadmin scripting tool using the Jython scripting language. To learn more, see the starting the wsadmin scripting client information.
  2. Retrieve the current binding data for the attachment of interest.

    Use the getPolicySetAttachments command to determine the attachment ID. You will need to specify the attachment ID in the getBinding and setBinding commands to specify that this is a application-specific binding configuration. To retrieve the attachment ID:

      AdminTask.getPolicySetAttachments('-applicationName application1')

    Use the getBinding command to display a properties object containing each configuration attribute for a specific policy binding configuration. For application and client policy set attachments, specify a properties object for the -bindingLocation parameter using the application and attachmentId property names. For a system policy set attachment for the trust service, specify only the attachmentId property name. The following example queries for an application policy set binding configuration: 

    AdminTask.getBinding('-policyType WSAddressing -bindingLocation "[[application application1][attachmentId 
123]]"')

    To return a specific configuration attribute for the policy, use the -attributes parameter.

  3. Edit the binding configuration.

    Use the setBinding command to update your binding configuration for a policy. To specify that you are editing a application-specific binding configuration, set the -bindingLocation parameter by specifying the application and attachmentId property names in a properties object. We can additionally specify the -attachmentType parameter as provider or client.

    For transitioning users: Even though we can specify the application value for the -attachmentType parameter, use the provider value in place of the application value because the attachments are used for more than just applications, such as system attachments for trust service. For system policy set attachments, specify the provider value for the attachmentType parameter and the "[systemType trustService]" value for the -attachmentProperties parameter. For WSNClient attachments, specify the client value for the attachmentType parameter and the bus and WSNService properties with the -attachmentProperties parameter.trns Customize your binding configuration with the following optional parameters:

    Optional parameters. Use the optional binding parameters to update the binding configuration.

    Parameter Description Data type
    -policyType Policy of interest. String, optional
    -remove Use this parameter to remove a specific policy from the binding configuration. The default value for the -remove parameter is false. If the -policyType parameter is not specified, the command removes the application-specific binding from the attachment. To delete the binding configuration, provide a value for the -bindingName parameter and an asterisk character (*) for the -attachmentId parameter. Boolean, optional
    -attributes Attribute values to update. This parameter can include each binding configuration attribute for the policy or a subset of attributes to update. If we do not specify the attributes parameter, the command only updates the binding configuration location the specified attachment uses. Properties, optional
    -bindingName Name for the binding configuration. Specify a name for the binding when we create a new application-specific binding. We can also use this parameter to switch an attachment to use a different, existing application-specific binding configuration. Lastly, specify a value for this parameter to delete a binding configuration. String, optional
    -replace Whether to replace all of the existing binding configuration attributes with the attributes specified in the command. Use this parameter to remove optional parts of the configuration for policies with complex data. Default is false. Boolean, optional
    -domainName Domain name for the binding. Scope a binding to a domain other than the global security domain. String, optional

    The following example disables workload management for the myApplication application's binding configuration for the WSAddressing policy: 

    AdminTask.setBinding('[-policyType WSAddressing -bindingLocation "[ [application myApplication] 
[attachmentId 123] ]"
 -attributes "[preventWLM false]" -attachmentType provider]')

  4. Save the configuration changes.

    Enter the following command to save your changes.


Related


Start the wsadmin scripting client using wsadmin.sh
Create application specific bindings for policy set attachment
Configure application and system policy sets for web services using wsadmin.sh
Create policy sets using wsadmin.sh
Add and remove policies using wsadmin.sh
Create policy set attachments using wsadmin
Manage policy set attachments using wsadmin
Remove policy set attachments using wsadmin
Manage policy sets


Reference:

PolicySetManagement command group for AdminTask


+

Search Tips   |   Advanced Search