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 inter-operability, 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:
New feature: 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, you 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.
newfeat
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. You 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. You 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:
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
WebSphere Application Server 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.
You can use the administrative console to configure
the Web Services Security binding of a deployed application with Web
Services Security constraints that are 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 your applications
use the Java API
for XML Web Services (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 that you can use to edit the policy set file and
the binding file:
- IBM assembly tools
- You 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 Enterprise JavaBeans (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.
Note: You
can use policy sets only with Java API
for XML-Based Web Services (JAX-WS) applications. You cannot use policy
sets with Java API for XML-based RPC (JAX-RPC)
applications.
- WebSphere Application Server administrative
console
- You can use the administrative console to configure
the Web Services
Security binding of a deployed application with Web Services Security
constraints that are 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).
See the standard documentation for more information: JSR-183 (Java API
for Web Services Security: SOAP Message Security 1.0 specification).
- Application programming interfaces
(API) do not exist for Web Services Security in WebSphere Application Server Versions 6.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 application programming interface for XML
security and Web Services Security:
For more information on the IBM
SDK for Java Version 6,
see the security information documentation.