Configuration overview

The Web services security constraints are defined in an IBM extension of the Web services deployment descriptor for Java 2 Platform, Enterprise Edition (J2EE). The IBM extension deployment descriptor and binding for Web services
security are IBM proprietary. 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. IBM recommends, however, that you use the tools provided by IBM to configure the Web services
security constraints for an application. These tools are the Rational Application Developer, Rational Web Developer, the Application Server Toolkit, and the WebSphere Application Server administrative console. The following table provides the names of the deployment descriptor and binding files for the client and the server.

File type	Client side	Server side
Deployment descriptor	ibm-webservicesclient-ext.xmi	ibm-webservices-ext.xmi
Binding file	ibm-webservicesclient-bnd.xmi	ibm-webservices-bnd.xmi

The "what" is specified in the deployment descriptor such as what message part to sign and which token to encrypt. The "how" is specified in the binding file such as how the message is signed, how to generate and consume the security token.

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

The following figure represents the relationship of the application deployment descriptor and binding files to the cell or server level configuration.

Platform configuration overview

The following options are available in the administrative console:

Nonce cache timeout

This option, which is found on the cell level (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 (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 (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 a new feature for WebSphere Application Server Version 6.

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 Version 6 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 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 default bindings specify the default binding so that applications do not have to define the binding in the application binding files for Web services security. There is only one set of default bindings and they can be shared by multiple applications. This feature is available for WebSphere Application Server Version 6 applications only.

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

Application EAR 1 and EAR 2 have specific bindings in the application binding file. However, application EAR 3 and EAR 4 do not have a binding in the application binding file, but rather use the default binding 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" 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 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 levels.

Related concepts
Nonce, a randomly generated token
Distributed nonce caching
Key locator
Collection certificate store
Trust anchor
Trusted ID evaluator