WS-Security spec - a chronology
The development of the WS-Security specification includes information on the OASIS WS-Security specification. The OASIS WS-Security spec serves as a basis for securing Web services in WAS.
Best practice: IBM WAS supports...
- JAX-WS
- JAX-RPC
JAX-WS extends JAX-RPC, and offers...
- Simplified configuration of qualities of service (QoS) using policy sets, which combine settings, including those for transport and message-level configuration.
Policy sets and general bindings can be reused across multiple applications, making Web services QoS more consumable.
- WS-Security for JAX-WS is supported in both a managed environment, such as a Java EE container, and unmanaged environments, such as Java SE 6.
In addition, there is an API for enabling WS-Security in the JAX-WS client.
Non-OASIS activities
IBM and Microsoft jointly published a security white paper on Web services entitled Security in a Web Services World: A Proposed Architecture and Roadmap. The white paper discusses the following initial and subsequent specifications in the proposed WS-Security roadmap:
- Web service security
- Defines how to attach a digital signature, use encryption, and use security tokens in SOAP messages.
- WS-Policy
- Defines the language used to describe security constraints and the policy of intermediaries or endpoints.
- WS-Trust
- Defines a framework for trust models to establish trust between Web services.
- WS-Privacy
- Defines a model of how to express a privacy policy for a Web service and a requester.
- WS-SecureConversation
- Defines how to exchange and establish a secured context, which derives session keys between Web services.
- WS-Authorization
- Defines the authorization policy for a Web service. However, the WS-Authorization spec has not been published. The existing implementation of WS-Security is based upon the Web Services for Java EE or Java Specification Requirements (JSR) 109 specification.
The implementation of WS-Security leverages the Java EE role-based authorization checks.
If we develop a Web service that requires method-level authorization checks, then use stateless session beans to implement the Web service.
If we develop a Web service that is implemented as a servlet, we can use coarse-grained or URL-based authorization in the Web container. However, in this situation, we cannot use the identity from WS-Security for authorization checks. Instead, we can use the identity from the transport. If we use SOAP over HTTP, then the identity is in the HTTP transport.
This following figure shows the relationship between these specifications:
In April 2002, IBM, Microsoft, and VeriSign proposed the WS-Security spec, which included the basic ideas of a security token, XML digital signature, and XML encryption. The spec also defined the format for user name tokens and encoded binary security tokens. After some discussion and an interoperability test based on the specification, the following issues were noted:
- The spec requires that the WS-Security processors understand the schema correctly so that the processor distinguishes between the ID attribute for XML digital signature and XML encryption.
- The freshness of the message, which indicates whether the message complies with predefined time constraints, cannot be determined.
- Digested password strings do not strengthen security.
In August 2002, IBM, Microsoft, and VeriSign published the WS-Security Addendum, which attempted to address the previously listed issues.
The following solutions were addressed in the addendum:
- Require a global ID attribute for XML signature and XML encryption.
- Use time stamp header elements that indicate the time of the creation, receipt, or expiration of the message.
- Use password strings that are digested with a time stamp and nonce, which is a randomly generated token.
The specifications for the blue boxes in the previous figure have been proposed by various industry vendors and various interoperability events have been organized by the vendors to verify and refine the proposed specifications.
OASIS activities
In June 2002, OASIS received a proposed WS-Security spec from IBM, Microsoft, and VeriSign. The WS-Security Technical Committee (WSS TC) was organized at OASIS soon after the submission. The technical committee included many companies including IBM, Microsoft, VeriSign, Sun Microsystems, and BEA Systems.
In September 2002, WSS TC published its first specification, WS-Security Core Specification, Working Draft 01. This spec included the contents of both the original WS-Security spec and its addendum.
Because the WS-Security Core Specification allows arbitrary types of security tokens, proposals were published as profiles. The profiles described the method for embedding tokens, including Security Assertion Markup Language (SAML) tokens and Kerberos tokens embedded into the WS-Security messages. Subsequently, the definitions of the usage for user name tokens and X.509 binary security tokens, which were defined in the original WS-Security Specification, were divided into the profiles. WAS Vs 5.0.2, 5.1, and 5.1.1 support the following specifications:
- WS-Security: SOAP Message Security Draft 13 (formerly WS-Security Core Specification)
- WS-Security: Username Token Profile Draft 2
In April 2004, the Web service security specification (officially called WS-Security: SOAP Message Security V 1.0) became the V1.0 OASIS standard. Also, the Username token and X.509 token profiles are V1.0 specifications. WAS 6 and later support the following WS-Security specifications from OASIS:
- WS-Security: SOAP Message Security 1.0 specification
- WS-Security: Username Token 1.0 Profile
- WS-Security: X.509 Token 1.0 Profile
In February 2006, the core Web service security spec was updated and became the V 1.1 OASIS standard. Also, the Username token, X.509 token profile, and Kerberos token profile were updated to the V1.1 specifications. Portions of the following WS-Security specifications from OASIS are supported in WAS, specifically signature confirmation, encrypted header, and thumbprint references:
- OASIS: WS-Security: SOAP Message Security 1.1 (WS-Security 2004) OASIS Standard Specification, 1 February 2006
- OASIS: WS-Security UsernameToken Profile 1.1 OASIS Standard Specification, 1 February 2006
- OASIS: WS-Security X.509 Certificate Token Profile 1.1 OASIS Standard Specification, 1 February 2006
The following spec describes the use of Kerberos tokens with respect to the WS-Security message security specifications. The spec defines how to use a Kerberos token to support authentication and message protection: OASIS: WS-Security Kerberos Token Profile 1.1 OASIS Standard Specification, 1 February 2006.
In 2007, the OASIS Web Services Secure Exchange Technical Committee (WS-SX) produced and approved the following specifications. Portions of these specifications are supported by WAS V7.
The following figure shows the various WS-Security-related specifications.
WAS also provides plug-in capability to enable security providers to extend the runtime capability and implement some of the higher level specifications in the Web service security stack. The plug-in points are exposed as Service Provider Programming Interfaces (SPI).
WS-Security spec 1.0 development
The OASIS WS-Security spec is based upon the following World Wide Web Consortium (W3C) specifications. Most of the W3C specifications are in the standard body recommended status.
- XML-Signature Syntax and Processing
W3C recommendation, February 2002 (Also, IETF RFC 3275, March 2002)
- Canonical XML V1.0
W3C recommendation, March 2001
- Exclusive XML Canonicalization V1.0
W3C recommendation, July 2002
- XML-Signature XPath Filter V2.0
W3C Recommendation, November 2002
- XML Encryption Syntax and Processing
W3C Recommendation, December 2002
- Decryption Transform for XML Signature
W3C Recommendation, December 2002
These specifications are supported in WAS in the context of WS-Security. For example, we can sign a SOAP message by specifying the integrity option in the deployment descriptors. There is a client side API that an application can use to enable WS-Security for securing a SOAP message.
The OASIS WS-Security Version 1.0 spec defines the enhancements that are used to provide message integrity and confidentiality. It also provides a general framework for associating the security tokens with a SOAP message. The spec is designed to be extensible to support multiple security token formats. The particular security token usage is addressed with the security token profile.
Specification and profile support in
OASIS is working on various profiles.
The following list includes of the published draft profiles and OASIS WS-Security technical committee work in progress.
WAS does not support these profiles:
- WS-Security: SAML token profile 1.0
- WS-Security: Rights Expression Language (REL) token profile 1.0
- WS-Security: SOAP Messages with Attachments (SwA) profile 1.0
Support for WS-Security draft 13 and Username token profile draft 2 is deprecated in WebSphere Application 5.0.2, 5.1.0 and 5.1.1. For migration information, see Migrate JAX-RPC WS-Security applications to V7.0 applications.
The wire format of the SOAP message with WS-Security in WS-Security V1.0 has changed and is not compatible with previous drafts of the OASIS WS-Security specification. Interoperability between OASIS WS-Security V1.0 and previous WS-Security drafts is not supported. However, it is possible to run an application that is based on WS-Security draft 13 on WAS V6 and later. The application can interoperate with an application that is based on WS-Security draft 13 on WAS V5.0.2, 5.1 or 5.1.1.
WAS supports both the OASIS WS-Security draft 13 and the OASIS WS-Security 1.0 specification. But in WAS V6 and later, the support of OASIS WS-Security draft 13 is deprecated. However, applications that were developed using OASIS WS-Security draft 13 on WAS 5.0.2, 5.1.0 and 5.1.1 can run on WAS V6 and later. OASIS WS-Security V1.0 support is available only for Java EE Version 1.4 and later applications. The configuration format for the deployment descriptor and the binding is different from previous versions of WAS. You must migrate the existing applications to Java EE 1.4 and migrate the WS-Security configuration to the WAS V6 format.
Other WS-Security specifications development
The most recently updated versions of the following OASIS WS-Security specifications are supported in WAS V7.0 in the context of WS-Security:
- WS-Trust V1.3
The Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of Web services security to define additional primitives and extensions for the issuance, exchange and validation of security tokens. WS-Trust enables the issuance and dissemination of credentials within different trust domains.
This spec defines ways to establish, assess the presence of, and broker trust relationships.
- WS-SecureConversation V1.3
The Web Services Secure Conversation Language (WS-SecureConversation) is built on top of the WS-Security and WS-Policy models to provide secure communication between services. WS-Security focuses on the message authentication model but not a security context, and thus is subject several forms of security attacks. This spec defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts, to enable a secure conversation. By using the SOAP extensibility model, modular SOAP-based specifications are designed to be composed with each other to provide a rich messaging environment.
- WS-SecurityPolicy V1.2
WS-Security Policy (WS-Policy) provides a general purpose model and syntax to describe and communicate the policies of a Web service. WS-Policy assertions express the capabilities and constraints of a particular Web service. WS-PolicyAttachments defines several methods for associating the WS-Policy expressions with Web services (such as WSDL).
The WS-Security specifications have been updated following the re-publication of WS-Security Policy in July 2005, to reflect the constraints and capabilities of Web services that are using WS-Security, WSTrust and WS-SecureConversation. WS-ReliableMessaging Policy has also been re-published in 2005 to express the capabilities and constraints of Web services implementing WS-ReliableMessaging.
Web Services Interoperability Organization (WS-I) activities
Web Services Interoperability Organization< (WS-I) is an open industry effort to promote Web services interoperability across vendors, platforms, programming languages and applications.
The organization is a consortium of companies across many industries including IBM, Microsoft, Oracle, Sun, Novell, VeriSign, and Daimler Chrysler. WS-I began working on the basic security profile (BSP) in the spring of 2003. BSP consists of a set of non-proprietary Web services specifications that clarifies and amplifies those specifications to promote WS-Security interoperability across different vendor implementations. As of June 2004, BSP is a public draft.
Specifically, see Basic Security Profile V1.0 for details about the BSP. WAS supports compliance with the BSP draft, but WS-Security does not support the BSP V1.1 draft. See Basic Security Profile compliance tips for the details to configure the application in compliance with the BSP draft.
Related concepts
Default implementations of the WS-Security service provider programming interfaces
Role-based authorization
Basic Security Profile compliance tips
What is new for securing Web services
Related tasks
Migrate JAX-RPC WS-Security applications to V7.0 applications
Implementing Web services applications with JAX-WS
Implementing Web services applications with JAX-RPC
Secure enterprise bean applications