When defining a security model, you have to show how data can flow through an application and over a network to meet the requirements defined by the business without exposing the data to any risk. The ISO security standard defines seven security services:
- Identification: Can you can tell me who you are?
- Authentication: Can you prove that you are who you say you are?
- Authorization: Now that I have determined your identity, what is the set of things that you're allowed to do?
- Integrity: Was the information that you sent to me changed or corrupted as it was transmitted?
- Confidentiality: Can anyone read the information that is passed back and forth between us?
- Auditing: Are all transactions recorded so that we can review them later?
- Non-repudiation: Can I prove that it was you who sent the message?
When enabling security for any application, one or more of the above services, based on the requirements of your application, is implemented. The real security challenge is to understand and assess the risk involved in securing any application and apply the appropriate measures. For Web services, it is important to understand what security technology exists today and at the same time track emerging standards and understand how they will be used to offset the risk in new Web services.
In Web services, the SOAP envelope is defined in XML. Web services can therefore use many existing XML security technologies and standards, such as XML encryption and XML digital signatures. In addition to such existing security techniques, many new specifications have begun to emerge. The WS-Security specification (see Resources ) is the cornerstone in the effort to pull all of these requirements together. The abstract of the WS-Security specification document says that "WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies..."
The first version of the WS-Security specification was proposed by IBM, Microsoft, and VeriSign in April 2002. After the formalization of the April 2002 specifications, the specification was transferred to the OASIS consortium (http://www.oasis-open.org). The latest specification and profiles of WS-Security were proposed in March 2004 as an OASIS standard. The latest core specification, Web Services Security: SOAP Message Security 1.0 (WS-Security 2004) was standardized in March 2004. The two profiles, Web Services Security UsernameToken Profile 1.0 and Web Services Security X.509 Certificate Token Profile 1.0, were standardized at the same time.
It is important to note that WS-Security makes use of many existing technologies rather than creating new ones. XML encryption and XML digital signatures are two good examples of existing technologies that are used within this new specification.
This tutorial covers the security implementation in individual exercises. The use of security tokens, XML encryption, and XML digital signatures as currently supported by Rational Application Developer are demonstrated. Other supported features are usually variations of the examples shown here. There are a number of security extensions and unsupported features also available. A complete description of these features can be found in the redbook, Web Services Handbook for WebSphere Application Server 6.1.
The support of the April 2002 draft specification of WS-Security is provided in WebSphere Application Server Versions 5.0.2 and 5.1. WebSphere Application Server Version 6.0 supports the WS-Security 2004 specification and two token profiles (UsernameToken 1.0, X.509 Certificate Token 1.0), providing the runtime for them. WebSphere Application Server V6.1 adds support Basic Security Profile (WS-I BSP), plus additional specifications such as WS-Addressing, WS-Resource, WS-BusinessActivity, and WS-Notification. XDoclet annotations can be used to create a Web service. Rational Application Developer V7.0 provides functions to secure Web services based on these specifications.
WebSphere Application Server V6.0 and 6.1have two types of the WS-Security runtime: one is for Version 5.x, the other is for Version 6.0 (Figure 21-61 of the WebSphere Version 6 Web Services Handbook Development and Deployment). Because there are two runtimes, the server can receive a request from both a J2EE 1.3 client with Version 5.x and a J2EE 1.4 client with Version 6.0 WS-Security. However, a J2EE 1.3 client cannot connect to the Version 6.0 runtime and cannot use the new features of Version 6.0 WS-Security. If you want to use Version 6.0 functions in your secure Version 5.x application, you have to migrate from Version 5.x to Version 6.0. For more information on interoperability and migration see Web Services Handbook for WebSphere Application Server 6.1.
The WS-Security configuration can be done either via the Wizards in Rational Application Developer or defined directly in the IBM extension of the Web services deployment descriptors and bindings. These descriptors and bindings are based on a aWeb service port, that is, each port can have it's own security definitions. These definitions are defined outside of the application business logic and therefore allows for the seperation of roles. After the application is developed the security expert can apply the appropriate policies. This means that the original service never changes: all security processing occurs outside of the code, allowing you greater deployment flexibility.
There are two sets of security handler configurations on the client side and two on the server side. Both sides have a request generator and response consumer. As their name indicates they define the constraints on the responses and requests that are applied.
Rational Application Developer provides the ability to add security tokens, XML digital signatures, and XML encryption to Web service messages either via the Web services wizard (now when using the wizard, you can do either one or the other, or both) or the via directly configuring the deployment descriptors and bindings.
You can add a token only via the Web services deployment descriptor. Using the latter method, you can choose to add any of the options in any combination. In this tutorial, however, you will see how to add signatures and encryption via the Web services wizard, and security tokens via the deployment descriptor. The IBM Web services Redbook Web Services Handbook for WebSphere Application Server 6.1, which replaces WebSphere Version 6 Web Services Handbook Development and Deployment, describes the steps required to do all of this using the deployment descriptor.
In this tutorial, security implementation is covered in the following sequence:
- Generate a Web service without any security and look at the SOAP envelopes that the service generates.
- Implement XML encryption and view the encrypted parts of the envelope.
- Implement XML digital signatures and view the associated elements within the SOAP envelope.
- Add a security token, using a user ID and password, and view how these elements are represented within the SOAP envelope.