WAS v8.5 > Secure applications > Secure web services > Secure web services > Web Services Security concepts > Web Services Security conceptsWeb Services Security provides message integrity, confidentiality, and authentication
OASIS WS-Security is a flexible standard used to secure web services at the message level within multiple security models. We can secure SOAP messages through XML digital signature, confidentiality through XML encryption, and credential propagation through security tokens.
The WS-Security 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. Message-level security, or securing web services at the message level, addresses the same security requirements as for traditional web security. These security requirements include: identity, authentication, authorization, integrity, confidentiality, nonrepudiation, basic message exchange, and so forth. Both traditional web and message-level security share many of the same mechanisms for handling security, including digital certificates, encryption, and digital signatures. While HTTPS and SSL transport-level technology may be used for securing web services, some security scenarios are addressed more effectively by message-level security.
Traditional web security mechanisms, such as HTTPS, might be insufficient to manage the security requirements of all web service scenarios. For example, when an application sends a document with JAX-RPC using HTTPS, the message is secured only for the HTTPS connection, meaning during the transport of the document between the service requester (the client) and the service. However, the application might require the document data be secured beyond the HTTPS connection, or even beyond the transport layer. By securing web services at the message level, message-level security is capable of meeting these expanded requirements.
Message-level security applies to XML documents sent as SOAP messages. Message-level security makes security part of the message itself by embedding all required security information in the SOAP header of a message. In addition, message-level security can apply security mechanisms, such as encryption and digital signature, to the data in the message itself.
With message-level security, the SOAP message itself either contains the information needed to secure the message or it contains information about where to get that information to handle security needs. The SOAP message also contains information relevant to the protocols and procedures for processing the specified message-level security. However, message-level security is not tied to any particular transport mechanism. Because the security information is part of the message, it is independent of a transport protocol, such as HTTPS.
The client adds to the SOAP message header security information that applies to that particular message. When the message is received, the web service endpoint, using the security information in the header, verifies the secured message and validates it against the policy. For example, the service endpoint might verify the message signature and check the message has not been tampered with. It is possible to add signature and encryption information to the SOAP message headers, as well as other information such as security tokens for identity (for example, an X.509 certificate) that are bound to the SOAP message content.
For WebSphere Application Server Versions 6 and later, Web Services Security can be applied as transport-level security and as message-level security. We can architect highly secure client and server designs using these security mechanisms. Transport-level security refers to securing the connection between a client application and a web service with SSL.
We can apply various scenarios of Web Services Security according to the characteristics of each web service application. You have choices of how to protect your information when using Web Services Security. The authentication mechanism, integrity, and confidentiality can be applied at the message level and at the transport level. When message-level security is applied, we can protect the SOAP message with a security token, digital signature, and encryption.
Without Web Services Security, the SOAP message is sent in clear text, and personal information such as a user ID or an account number is not protected. Without applying Web Services Security, there is only a SOAP body under the SOAP envelope in the SOAP message. By applying features from the WS-Security specification, the SOAP security header is inserted under the SOAP envelope in the SOAP message when the SOAP body is signed and encrypted.
To maintain the integrity or confidentiality of the message, digital signatures and encryption are typically applied.
- Confidentiality specifies the confidentiality constraints that are applied to generated messages. This includes specifying which message parts within the generated message must be encrypted, and the message parts to attach encrypted Nonce and time stamp elements to.
- Integrity is provided by applying a digital signature to a SOAP message. Confidentiality is applied by SOAP message encryption. Multiple signatures and encryptions are supported. In addition, both signing and encryption can be applied to the same parts, such as the SOAP body.
We can add an authentication mechanism by inserting various types of security tokens, such as the Username token (<UsernameToken> element). When the Username token is received by the web service server, the user name and password are extracted and verified. Only when the user name and password combination is valid, will the message be accepted and processed at the server. Using the Username token is just one of the ways of implementing authentication. This mechanism is also known as basic authentication.
In addition to digital signatures, encryption, and basic authentication, other forms of authentication include identity assertion, LTPA tokens, Kerberos tokens, and custom tokens. These other forms of authentication are also extensions of WAS. We can configure these authentication mechanisms using the assembly tools to implement authentication.
With updates to Web Services Security in the v1.1 specification, it is possible to layer additional functionality in addition to these basic mechanisms. Some v1.1 mechanisms are extensions of WAS, such as signature confirmation and the encrypted header. The security token profiles that are supported by WAS include the Username token profile, the X.509 token profile, and the Kerberos profile. In this case, when the message is received, the web service endpoint, using the security information in the header, applies the appropriate security mechanisms to the message. For example, the service endpoint might add signature and encryption information to the SOAP message headers, as well as other information, such as security tokens, that are bound to the SOAP message content. We can implement these new mechanisms using a policy set.
WS-SecureConversation was introduced in WAS v6.1 with the Feature Pack for Web Services. Secure Conversation uses a session key to protect SOAP messages more efficiently, particularly when multiple SOAP messages are transmitted in a session.
Other enhancements include:
- The Kerberos token, which is used for both authentication and for subsequent message protection.
- Dynamic policy, which allows the client to retrieve the provider policy through a WSDL request, or using Web Services MetadataExhange (WS-MEX), to simplify web services client deployment.
Subtopics
- High-level architecture for Web Services Security
The Web Services Security policy is specified in the IBM extension of the web services deployment descriptors when using the JAX-RPC programming model, and in policy sets when using the JAX-WS programming model. A stand-alone JAX-WS client application may specify Web Services Security policy programmatically. Binding data that supports the Web Services Security policy are stored in the IBM extension of the web services deployment descriptors for both the JAX-RPC and JAX-WS programming models. The Web Services Security run time enforces the security assertions specified in the policy document, or in the application program, in that order.- XML digital signature
XML-Signature Syntax and Processing (XML digital signature) is a specification that defines XML syntax and processing rules to sign and verify digital signatures for digital content. The specification was developed jointly by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF).- Collection certificate store
A collection certificate store is a collection of non-root, certificate authority (CA) certificates and certificate revocation lists (CRLs). This collection of CA certificates and CRLs is used to check the signature of a digitally signed SOAP message.- Certificate revocation list
A certificate revocation list is a time-stamped list of certificates that have been revoked by a certificate authority (CA).- XML encryption
XML encryption is a specification that was developed by World Wide Web (WWW) Consortium (W3C) in 2002 and containing the steps to encrypt data, the steps to decrypt encrypted data, the XML syntax to represent encrypted data, the information to be used to decrypt the data, and a list of encryption algorithms, such as triple DES, AES, and RSA.- Security token
Web Services Security provides a general-purpose mechanism to associate security tokens with messages for single message authentication. A security token represents a set of claims made by a client that might include a name, password, identity, key, certificate, group, privilege, and so on.- LTPA and LTPA v2 tokens
Web services security supports both LTPA (v1) and LTPA v2 (LTPA2) tokens. The LTPA2 token, which is more secure than v1, is supported by the JAX-WS runtime only.- Username token
We can use the <UsernameToken> element to propagate a user name and, optionally, password information. Also, we can use this token type to carry basic authentication information. Both a user name and a password are used to authenticate the SOAP message.- XML token
XML tokens are offered in two well-known formats called SAML and eXtensible rights Markup Language (XrML).- Binary security token
The ValueType attribute identifies the type of the security token, for example, a LTPA token. The EncodingType type indicates how the security token is encoded, for example, Base64Binary. The BinarySecurityToken element defines a security token that is binary encoded. The encoding is specified using the EncodingType attribute. The value type and space are specified using the ValueType attribute. The Web Services Security implementation for WAS, v6 and later supports LTPA,, LTPA version 2, and X.509 certificate binary security tokens.- X.509 Binary Security Token
An X.509 binary security token is the base64 encoded representation of an X.509 public certificate.- Kerberos token
IBM WAS provides Kerberos token support for web services message-level security. The support is based on the Organization for the OASIS Web Services Security Kerberos Token Profile v1.1. Use this topic to understand the Kerberos support that is available for web services.- SAML token
SAML is an XML-based standard for exchanging user identity and security attributes.- Time stamp
A time stamp is the value of an object that indicates the system time at some critical point in the history of the object.- Security considerations for web services
When you configure Web Services Security, you should make every effort to verify the result is not vulnerable to a wide range of attack mechanisms. There are possible security concerns that arise when we are securing web services.- Web Services Security token propagation
Web Services Security has the ability to send security tokens in the security header of a SOAP message. These security tokens can be used to sign, verify, encrypt or decrypt message parts. Security tokens can also be sent as stand-alone security tokens and set as the caller on the request consumer. Web Services Security token propagation is used to send these stand-alone security tokens in a wsse:BinarySecurityToken element within the security header of the SOAP message.
Related concepts:
Programming models for web services message-level security