Overview of platform configuration and bindings

The Web Services Security policy is specified in the IBM® extension of the web services deployment descriptors when using the JAX-RPC programming model, and in policy sets when using the JAX-WS programming model. Binding information to support the Web Services Security policy is stored in the IBM extension of the web services deployment descriptors for both the JAX-RPC and JAX-WS programming models.

最佳作法 最佳作法: IBM WebSphere® Application Server 支援 Java™ API for XML 型 Web 服務 (JAX-WS) 程式設計模型和 Java API for XML 型 RPC (JAX-RPC) 程式設計模型。JAX-WS 是延伸 JAX-RPC 程式設計模型所提供之基礎的下一代 Web 服務程式設計模型。 當使用策略性 JAX-WS 程式設計模型時,透過支援標準型註釋模型,簡化了 Web 服務和用戶端的開發工作。 雖然仍支援 JAX-RPC 程式設計模型和應用程式,但請利用易於實作的 JAX-WS 程式設計模型來開發新的 Web 服務應用程式和用戶端。best-practices

Due to the complexity of these files, it is not recommended that you edit the deployment descriptor and binding files manually with a text editor because they might cause errors. It is recommended, however, that you use the tools provided by IBM to configure the Web Services Security constraints for an application. These tools are the WebSphere Application Server administrative console, or an assembly tool. For more information about IBM assembly tools, see the assembly tools information.

You can use the policy set function of the WebSphere Application Server to simplify your web services configuration because policy sets group security and other web services settings into reusable units. Policy sets are assertions about how quality of services is defined. A policy set incorporates policy types, and their settings.

In addition to the application deployment descriptor and binding files, WebSphere Application Server Versions 6 and later have a cell level and a server level configuration. These configurations are global for all applications. Because WebSphere Application Server Version 6 and later support 5.x applications, some of the configurations are valid for Version 5.x applications only and some are valid for Version 6 and later applications only.

The following figure represents the relationship of the application deployment descriptor and binding files to the cell (WebSphere Application Server, Network Deployment only) or server level configuration.

Relationship of the application deployment descriptor and binding files to the application server

Platform configuration

The following options are available in the administrative console:
Nonce cache timeout
This option, which is found on the cell level (WebSphere Application Server, Network Deployment only) and server level, specifies the cache timeout value for a nonce in seconds.
Nonce maximum age
This option, which is found on the cell level (WebSphere Application Server, Network Deployment only) and server level, specifies the default life span for the nonce in seconds.
Nonce clock skew
This option, which is found on the cell level (WebSphere Application Server, Network Deployment only) and server level, specifies the default clock skew to account for network delay, processing delay, and so on. It is used to calculate when the nonce expires. Its unit of measurement is seconds.
Distribute nonce caching
This feature enables you to distribute the cache for the nonce to different servers in a cluster. It is available for WebSphere Application Server Version 6.0.x and later.
The following features can be referenced in the application binding:
Key locator
This feature specifies how the keys are retrieved for signing, encryption, and decryption. The implementation classes for the key locator are different in WebSphere Application Server Versions 6 and later and Version 5.x.
Collection certificate store
This feature specifies the certificate store for certificate path validation. It is typically used for validating X.509 tokens during signature verification or constructing the X.509 token with a certificate revocation list that is encoded in the PKCS#7 format. The certificate revocation list is supported for WebSphere Application Server Version 6.x and later applications only.
Trust anchors
This feature specifies the trust level for the signer certificate and is typically used in the X.509 token validation during signature verification.
Trusted ID evaluators
This feature specifies how to verify the trust level for the identity. The feature is used with identity assertion.
Login mappings
This feature specifies the login configuration binding to the authentication methods. This feature is used by WebSphere Application Server Version 5.x applications only and it is deprecated.

Default bindings

The configuration of the default cell level and default server level bindings has changed in WebSphere Application Server. Previously, you could configure only one set of default bindings for the cell, and optionally configure one set of default bindings for each server. In version 7.0 and later, you can configure one or more general provider bindings and one or more general client bindings. However, only one general provider binding and one general client binding can be designated as the default.

The following figure shows the relationship between the application enterprise archive (EAR) file and the ws-security.xml file.

Relationship of an enterprise archive (EAR) file and the ws-security.xml file

Applications EAR 1 and EAR 2 have specific bindings in the application binding file. However, applications EAR 3 and EAR 4 do not have a binding in the application binding file; it must be referenced to use the default bindings defined in the ws-security.xml file. The configuration is resolved by nearest configuration in the hierarchy. For example, there might be three key locators named mykeylocator that is defined in the application binding file, the server level, and the cell level.

If mykeylocator is referenced in the application binding, then the key locator that is defined in the application binding is used. The visibility scope of the data depends upon where the data is defined. If the data is defined in the application binding, then its visibility is scoped to that particular application. If the data is defined on the server level, then the visibility scope is all of the applications deployed on that server. If the data is defined on the cell level, then the visibility scope is all of the applications deployed on servers in the cell. In general, if data is not meant to be shared by other applications, define the configuration in the application binding level.

The following figure shows the relationship of the bindings on the application, server, and cell (WebSphere Application Server, Network Deployment only) levels.

Relationship of the bindings on the application, server, and cell levels

General bindings

General bindings are used as the default bindings at the cell level or server level. The general bindings that are shipped with WebSphere Application Server are initially set as the default bindings, but you can choose a different binding as the default, or change the level of binding that should be used as the default, for example, from cell level binding to server level binding.

In version 7.0 and later, there are two types of bindings: application specific bindings, and general bindings. Both types of bindings are supported for WS-Security policy sets. General bindings can be shared across multiple applications and for trust service attachments. There are two types of general bindings: one for service providers and one for service clients. Multiple general bindings can be defined for the provider and also for the client.


指出主題類型的圖示 概念主題



時間戳記圖示 前次更新: July 9, 2016 11:11
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_configv6overview
檔名:cwbs_configv6overview.html