What is new for securing web services
In WebSphere Application Server, there are many security enhancements for web services. The enhancements include supporting sections of the Web Services Security (WS-Security) specifications and providing architectural support for plugging in and extending the capabilities of security tokens.
Enhancements from the supported Web Services Security specifications
Since September 2002, the Organization for the Advancement of Structured Information Standards (OASIS) has been developing the Web Services Security (WS-Security) for SOAP message standard.
In April 2004, OASIS released the Web Services Security Version 1.0 specification, which is a major milestone for securing web services. In Feburary 2006, the specification was updated to Version 1.1. This specification is the foundation for other Web Services Security specifications and is also the basis for the Basic Security Profile (WS-I BSP) Version 1.0 specification, which was approved in March 2007.See the Basic Security Profile web page for more information.
Web Services Security Version 1.1 is a strategic move towards Web Services Security interoperability, and an important part of the Web Services Security roadmap. For more information on the Web Services Security roadmap, see Security in a Web Services World: A Proposed Architecture and Roadmap.
WebSphere Application Server supports the following OASIS specifications and WS-I profiles:
- OASIS: Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)
- OASIS: Web Services Security: UsernameToken Profile 1.1
- OASIS: Web Services Security: Kerberos Token Profile 1.1
- OASIS: WS-SecurityPolicy 1.2
- OASIS: WS-SecureConversation 1.3
- OASIS: WS-Trust 1.3
- Basic Security Profile (WS-I BSP) 1.0
- OASIS: Web Services Security: SAML Token Profile 1.1
The Security Assertion Markup Language (SAML) is an XML-based OASIS standard for exchanging user identity and security attributes information. Using SAML, a client can communicate assertions regarding the identity, attributes, and entitlements of a SOAP message. Using the SAML function in WebSphere Application Server, we can apply policy sets to JAX-WS applications to use SAML assertions in web services messages and in web services usage scenarios. Use SAML assertions to represent user identity and user security attributes, and optionally, to sign and to encrypt SOAP message elements.
For details on what parts of the previous specifications are supported in WebSphere Application Server, see Supported functionality from OASIS specifications.
High level features overview in WebSphere Application Server
In WebSphere Application Server, the Web Services Security for SOAP Message Version 1.1 specification is designed to be flexible and accommodate the requirements of Web services. For example, the specification does not have a mandatory security token definition. Instead, the specification defines a generic mechanism to associate the security token with a SOAP message. The use of security tokens is defined in the various Version 1.0 and 1.1 security token profiles, such as:
For more information on security token profile development at OASIS, see Organization for the Advancement of Structured Information Standards.
The Web Services Security for SOAP Message Version 1.1 updates the Web Services Security for SOAP Message core specification and the various security token profiles. For this release, WebSphere Application Server implements the Username Token Profile 1.1 and the X.509 Token Profile 1.1, which includes support for the Thumbprint type of security token reference. In addition, it supports the signature confirmation and encrypted header portions of the Web Services Security Version 1.1 standard.
Important: The wire format (such as namespaces) in the WS-SecureConversation and WS-Trust 1.3 specification has changed. WebSphere Application Server tolerates requests formatted according to both the Submission Drafts and version 1.3 specifications, but you must ensure that the correct version is used when clients are communicating with a Web Services Feature Pack service provider. We can disable tolerance of the older format for WS-SecureConversation and WS-Trust 1.3 endpoints. Submission Drafts requests are not interoperable with version 1.3 standards.
WebSphere Application Server supports pluggable security tokens. The pluggable architecture is enhanced to support the Web Services Security specifications, other profiles, and other Web Services Security specifications. We can learn more about the pluggable security token framework for JAX-RPC web services, and associating custom security tokens with SOAP messages, by reading these articles on the IBM developerWorks website:
- Security for JAX-RPC Web services, Part 1: Generating custom tokens
- Security for JAX-RPC Web services, Part 2: Consuming custom tokens
WebSphere Application Server includes the following key enhancements:
- Support for the LTPA version 2 token
- Support for configuration of multiple callers, and an order attribute on the caller to determine which caller is used for the WebSphere credential
- Support for the published WS-SecurityPolicy version 1.2 specification embedded in WSDL
- Support for the WS-SecureConversation version 1.3 specification and the WS-Trust version 1.3 specification (used by WS-SecureConversation)
- Support for Kerberos token as defined in the WS-Kerberos Token Profile version 1.1 specification
For more information on some of these enhancements, see Web Services Security enhancements.
Configuration of Web Services Security
WAS uses the policy set model for implementing the Web Services Security Version 1.1 specification, including the Username token Version 1.1 profile, support for the Kerberos and LTPA v2 tokens, and the X.509 token version 1.1 profile. Policy sets combine configuration settings, including those for transport and message level configuration, such as WS-Addressing, WS-ReliableMessaging, WS-SecureConversation, and WS-Security. For more information on policy sets, refer to the topic Managing policy sets using the administrative console.
We can use the administrative console to configure the Web Services Security binding of a deployed application with Web Services Security constraints defined in the policy set.
For the X.509 Certificate Token Profile, one new type of security token reference is the Thumbprint reference, which is specified in the binding. WebSphere Application Server now supports creating and authenticating a security token by using a security token reference (STR) with a key identifier and a Thumbprint in the <KeyInfo> element. The Thumbprint key information type requires that there be a keystore with the public and private key pair instead of a shared key. To use the Thumbprint of the specified certificate, specify the keyInfo type THUMBPRINT in the bindings.
For example, a decryption key is referenced by means of the thumbprint of an associated certificate. The certificate is not included in the message. Instead, the <ds:KeyInfo> element contains a <wsse:SecurityTokenReference> element that specified the thumbprint of the specified certificate by means of the http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1 attribute of the <wsse:KeyIdentifier> element.
To take advantage of implementations associated with the Web Services Security Version 1.1 specification, you must:
- Ensure that the applications use the JAX-WS programming model.
- Re-configure the Web Services Security constraints in the new policy set and binding format.
WebSphere Application Server provides the following tools for editing the policy set file and the binding file:
- IBM assembly tools
- We can use IBM assembly tools to develop web services and configure the policy set and the binding file for Web Services Security. The tools enable you to assemble both web and EJB modules. The assembly tools do not support direct editing of policy sets, but can import policy sets from the application server, and then attach the modified policy sets to the service. For more information, read about assembly tools.
We can use policy sets only with JAX-WS applications. We cannot use policy sets with JAX-RPC applications.
- WebSphere Application Server administrative console
- We can use the administrative console to configure the Web Services Security binding of a deployed application with Web Services Security constraints defined in the policy set.
What is not supported
Web service security is still fairly new and some of the standards are still being defined or standardized. The following functionality is not supported in WebSphere Application Server:
- JSR-183 (Java API for Web Services Security: SOAP Message Security 1.0 specification).
- APIs do not exist for Web Services Security in WAS v6.0.x and later.
- SAML token profile is not supported out of the box.
- REL token profile is not supported.
- SwA profile is not supported
What is supported by the IBM Software Development Kit (SDK)
The following standards exist for the Java API for XML security and Web Services Security:
- JSR-105 (Java API for XML-Signature XPath Filter Version 2.0
W3C Recommendation, November 2002
- JSR-106 (Java API for XML Encryption Syntax and Processing)
W3C Recommendation, December 2002
For more information on the IBM SDK for Java Version 6, see the security information documentation.
For information on what is supported for Web Services Security in WebSphere Application Server, see Supported functionality from OASIS specifications.
Subtopics
- Web Services Security enhancements
- Supported functionality from OASIS specifications
- Web Services Security specification - a chronology
Related concepts
Overview of standards and programming models for web services message-level securityBasic Security Profile compliance tips XML token Development and assembly tools Secure web services using Security Markup Assertion Language (SAML) Manage policy sets using the administrative console
Security information