Securing Web services for version 6.0.x applications based on WS-Security
Securing Web services for version 6.0.x applications based on WS-Security
Web services security for WebSphere Application Server is based on standards included in the Organization for the Advancement of Structured Information Standards (OASIS) Web services security (WSS) Version 1.0 specification,
the Username token Version 1.0 profile, and the X.509 token Version 1.0 profile.
These standards and profiles address how to provide protection for messages exchanged in a Web service environment. The specification defines the core facilities for protecting the integrity and confidentiality of a message and provides mechanisms for associating security-related claims with the message.
Web services security is a message-level standard based on securing Simple Object Access Protocol (SOAP) messages through XML digital signature, confidentiality through XML encryption, and credential propagation through security tokens.
To secure Web services, consider a broad set of security
requirements, including authentication, authorization, privacy, trust, integrity,
confidentiality, secure communications channels, federation, delegation, and auditing across a spectrum of application and business topologies. One of the key requirements for the security model in today's business environment
is the ability to interoperate between formerly incompatible security technologies (such as public key infrastructure, Kerberos and so on) in heterogeneous environments (such as Microsoft .NET and Java 2 Platform, Enterprise Edition (J2EE)). The complete Web services security protocol stack and technology roadmap is described in Security in a Web Services World: A Proposed Architecture and Roadmap.
The Web Services Security: SOAP Message Security 1.0 specification outlines a standard set of SOAP extensions that you can use to build secure Web services.
These standards confirm integrity and confidentiality, which are generally provided with digital signature and encryption technologies. In addition,
Web services security provides a general purpose mechanism for associating
security tokens with messages. A typical example of the security token is a username token, in which a user name and password are included as text.
Web services security defines how to encode binary security tokens using methods such as X.509 certificates and Kerberos tickets. However, the required security
tokens are not defined in the Web service security Version 1.0 specification.
Instead, the tokens are defined in separate profiles such as the Username token profile, the X.509 token profile, the SAML profile, the Kerberos profile,
the XrML profile and so on.
Web service security is supported in the managed Web service container. To establish a managed environment and to enforce constraints for Web services security, perform a Java Naming and Directory Interface (JNDI) lookup on the client to resolve the service reference.
For more information on the recommended client programming model, see "Service lookup" in the Java Specification Request (JSR) 109 specification available at: ftp://www-126.ibm.com/pub/jsr109/spec/1.0/websvcs-1_0-fr.pdf.
WebSphere Application Server Version 6.0.x and Version 5.x compatibility
In WebSphere Application Server Version 6.0.x, you can run a version 5.x Web services-secured application on a version 6.0.x application server. However, when you use a Web services-secured application, the client and the server must use the same version of the application server. For example, a Web services-secured application does not work properly when the client uses WebSphere Application Server Version 6 and the server uses version 5.x. Conversely, a Web services-secured application does not work properly when the client uses WebSphere Application Server Version 5.x and the server uses version 6.0.x. This issue occurs because the SOAP message format is different between a version 5.x application and a version 6.0.x application.
Configurations
To secure Web services with WebSphere Application Server, specify several different configurations. Although there is not a specific sequence in which specify these different configurations, some configurations reference other configurations. You can configure Web services security on the application level, server level, and the cell level. The following table shows an example of the relationships between each of the configurations that apply to just the application, to an entire server, or to the entire cell. However, the requirements for the bindings depend upon the deployment descriptor. Some binding information depends upon other information in the binding or server and cell-level configuration. Within the table, the configurations in the Referenced configurations column are referenced by the configuration listed in the Configuration name column. For example, the token generator on the application-level for the request generator references the collection certificate store, the nonce, time stamp, and callback handler configurations.
Table 1.
The relationship between the configurations.
If multiple applications will use the same binding information, consider configuring the binding information on the server or cell level. For example,
you might have a global key locator configuration that is used by multiple applications. Configuration information for the application-level precedes similar configuration information on the server-level and the cell level.
Because of the relationship between the different Web services security configurations, it is recommended that you specify the configurations on each level of the configuration in following order. You can choose to configure Web services security for the application level or the server level as it depends upon your environment and security needs.
Because of the relationship between the different Web services security configurations, it is recommended that you specify the configurations on each level of the configuration in following order: You can choose to configure Web services security for the application level, the server level or the cell level as it depends upon your environment and security needs.
(dependent on configuration)
Assemble your Web services security-enabled application using an assembly tool. Prior to modifying a Web services security-enabled application in the WebSphere Application Server administrative console, assemble your application using an assembly tool. Although you can modify some of the application settings using the administrative console, configure the generator and the consumer security constraints using an assembly tool such as the Application Server Toolkit or the Rational Application Developer.
For information on the assembly tools, see Assembly tools. For information on how to add Web services security to an application using an assembly tool, see Configuring an application for Web services security with an assembly tool.
Return to this article after you have assembled your application and imported it into the administrative console.
![[Version 6 only]](../../v6app.gif)