Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Secure web services > Secure web services > Web Services Security concepts > Web Services Security concepts > Web Services Security provides message integrity, confidentiality, and authentication > High-level architecture for Web Services Security
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 JAX-RPC, and in policy sets when using JAX-WS. 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 WAS supports the JAX-WS programming model and JAX-RPC. JAX-WS is the next generation web services programming model extending the foundation provided by JAX-RPC. Using the strategic JAX-WS programming model, development of web services and clients is simplified through support of a standards-based annotations model. Although JAX-RPC and applications are still supported, take advantage of the easy-to-implement JAX-WS programming model to develop new web services applications and clients. bprac
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 console, or an assembly tool. For more information about IBM assembly tools, see the assembly tools information.
We can use the policy set function of the WAS 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, WAS Versions 6 and later have a cell level and a server level configuration. These configurations are global for all applications. Because WAS v6 and later support 5.x applications, some of the configurations are valid for v5.x applications only and some are valid for v6 and later applications only.
The following figure represents the relationship of the application deployment descriptor and binding files to the cell (WAS ND only) or server level configuration.
application deployment descriptor and binding files to the application server" />
Platform configuration
The following options are available in the admin console:
The following features can be referenced in the application binding:
Default bindings
The configuration of the default cell level and default server level bindings has changed in WAS. 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 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 (WAS ND only) 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 WAS 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.
Related
Keys
Key locator
Trust anchor
Trusted ID evaluator
Hardware cryptographic device support for Web Services Security
Web services policy sets
Nonce, a randomly generated token
Basic Security Profile compliance tips
Collection certificate store
Assembly tools
High-level architecture for Web Services Security
Manage policy sets
Distribute nonce caching to servers in a cluster
Related
Application policy sets collection