Network Deployment (Distributed operating systems), v8.0 > Scripting 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


Create application-specific and trust service-specific bindings using wsadmin

Use the Jython or Jacl scripting language to create application-specific and trust service-specific bindings to match your installation environment or requirements.

When administrative security is enabled, verify that you use the correct administrative role:

Administrative roles. The administrative role determines if you can configure 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, you can configure bindings for the resource for which we have access. Only the Administrator role can configure 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.

Policy set bindings specify the details about how your quality of service (QoS) is configured. For example, a policy set attachment determines that sign, encrypt, or reliable messaging should be enabled. The policy set binding specifies how the protection is configured, for example, the path of the keystore file, the class name of the token generator, or the Java™ Authentication and Authorization Service (JAAS) configuration name.

For application policy sets, you can specify the policy set bindings at the cell-level using default binding configurations, at the application level using application-specific binding configurations, or at the cell-level with general bindings. Server-level default bindings are deprecated. If no binding information is specified during policy set attachment, the policy set inherits the default binding. We can specify a general binding as the default for a server instead of server-default bindings.

For system policy sets, you can specify the bindings at the cell-level and the server-level. The available bindings for system policy sets are the TrustServiceSymmetricDefault and TrustServiceSecurityDefault bindings. If no custom binding information is specified by the attachment, the resources inherit the TrustServiceSymmetricDefault or TrustServiceSecurityDefault binding. Only use default binding for development and testing. We must customize the signing and encryption keys in your binding configurations for 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, you 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, you can configure one or more general service provider bindings and one or more general service client bindings. After we have configured general bindings, you 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 application server or a security domain. trns

To support a mixed-cell environment, WebSphere Application Server 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 that 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 you 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 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 your 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 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 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 you do not want to use the provided Provider sample as the default service provider binding, you can select an existing general provider binding or create a new general provider binding to meet your business needs. Likewise, if you do not want to use the provided Client sample as the default service client binding, you can select an existing general client binding or create a new general client binding.


Procedure

  1. Launch a scripting command.

    To learn more, see the starting the wsadmin scripting client information.

  2. Determine the type of binding to create.

    You can create application policy set bindings at the cell-level, server-level, or application-level, and trust service policy set bindings at the cell-level or server-level.

  3. Retrieve the current binding configuration for the policy of interest.

    Use the getBinding command to display a Properties object containing all configuration attributes for a specific binding. Specify the location of the binding by passing a properties object using the -bindingLocation parameter and the following reference table:

    Command parameters. Use the command to display attributes for a binding.

    Type of binding -bindingLocation parameter value
    Server-level (deprecated) -bindingLocation "[[node node1][server server1]]"
    Application -bindingLocation "[[application application1][attachmentId 123]]"
    Trust service -bindingLocation "[[systemType trustService] [attachmentId 123]]"
    Trust client -bindingLocation "[[systemType trustClient] [attachmentId 123]]"
    WS-Notification client -bindingLocation "[[bus myBus][WSNService myService][attachmentId 123]"

    For this example, the command displays the current binding configuration for the WSAddressing policy, with the 123 attachment ID, for the application1 application: 

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

    To return a specific configuration attribute for the policy, use the -attributes parameter. For example, enter this command to determine if workload management is enabled: 

    AdminTask.getBinding('-policyType WSaddressing -bindingLocation "[[application application1][attachmentId 123]]" -attributes "[preventWLM]"')
    The command returns a properties object which contains the value of the requested attribute, preventWLM. You might receive an error message if the binding does not exist in the configuration.

  4. Create a new application-specific binding for the policy of interest.

    Use the setBinding command to create a binding configuration for a policy.

    To specify that you are creating an application-specific binding, set the -bindingLocation parameter by passing the application and attachmentId property names in a properties object. If you are creating a system policy set binding for the trust service, you only need to specify the attachmentId property name. We can further customize your binding with the following parameters:

    Command parameters. Use the command to create a binding configuration.

    Parameter Description Data type
    -policyType Policy of interest. String, optional
    -attachmentType Type of policy set attachment. If the attachment is for an application, you do not need to specify this parameter.

    For transitioning users: Even though you 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

    		String, optional
    -attributes Attribute values to update. This parameter can include all binding attributes for the policy or a subset of attributes. Properties, optional
    -bindingName Name for your new application-specific binding. A name is generated if it is not specified. String, 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

    The following example creates the WSAddressing1234binding attachment-specific binding for the WSAddressing policy, assigned to the application1 application attachment 123, and enables workload management: 

    AdminTask.setBinding('-policyType WSAddressing -bindingName
 WSAddressing123binding -bindingLocation "[ [application application1] [attachmentId 123] ]" -attributes
 "[preventWLM false]"')

  5. Optional: Add application-specific binding properties.

    Use the setBinding command to add any additional custom properties for the application-specific binding. The application server provides custom properties that are specific to each quality of service. Use the following format to specify custom properties for the binding: 

    AdminTask.setBinding('[-bindingLocation "[ [application application1] [attachmentId 123]
 ]" -policyType WSAddressing -attributes "[[properties_x:name key_value] [properties_x:value
 value]"]')

  6. Save the configuration changes. 
    AdminConfig.save()


Start the wsadmin scripting client using wsadmin.sh
Create application specific bindings for policy set attachment
Create policy set attachments using wsadmin
Manage policy set attachments using wsadmin
Remove policy set attachments using wsadmin
Manage policy sets


Related


PolicySetManagement command group

+

Search Tips   |   Advanced Search