You can use the Jython or Jacl scripting language to customize
your cell-wide default binding configuration. Create multiple cell-wide
general bindings that you can attach to applications.
Before you begin
Before you use the commands in this topic, verify
that you are using the most recent version of the wsadmin tool. 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 the wsadmin tool. For example,
the commands do not run on a Version 6.1.0.x node.
When
administrative security is enabled, verify that you use the correct
administrative role, as the following table describes:
Table 1. 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 you have access to a specific resource only,
you can configure bindings for the resource for which you 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. |
.
About this task
Bindings are environment and platform-specific information
such as key store information, keys used for signature and encryption,
or authentication information.
For transitioning users: In WebSphere Application
Server 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 the product. In the WebSphere
Application Server Version 6.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 Version
7.0, you can configure one or more general service provider bindings
and one or more general service client bindings. After you have configured
general bindings, you can specify which of these bindings is the global
default binding. You 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 Version 7.0 and Version 6.1 bindings.
General cell-level bindings are specific to Version 7.0 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 your environment:
- To display or modify default Version 6.1 bindings, Version 7.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 Version 7.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 Version 6.1 binding for an application in a Version 7.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 Version 6.1 application-specific
binding. The application server 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 you can reuse across multiple applications. You 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. You 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. You 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:
- 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 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.