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. 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, Rational Application Developer, Rational Web Developer, and the Application Server Toolkit. 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 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 V5.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 (Network Deployment only) or server level configuration.
There is only one set of default bindings and they can be shared by multiple applications. This feature is available for WebSphere Application Server V6 and later applications only.
The following figure shows the relationship between the application enterprise archive (EAR) file and the ws-security.xml file.
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 (Network Deployment only) levels.