Web services security
Contents
- Overview
- High-level architecture
- Web Services security review tasks
- Web services security with WebSphere appserver V6
Overview
WS-Security...
- Secures SOAP messages through XML digital signature
- Enhances confidentiality through XML encryption
- Propagates credentials using security tokens
For WAS V6 and later, WS-Security can be applied as transport-level security and as message-level security.
HTTPS and SSL transport-level technology may be used for securing Web services. Web services security includes transport-level SSL.
Applications that require that the document data be secured beyond the HTTPS connection or beyond the transport layer should use message-level security.
Message-level security requirements include:
- identity
- authentication
- authorization
- integrity
- confidentiality
- nonrepudiation
- basic message exchange
- etc...
Traditional Web and message-level security share many of the same mechanisms for handling security, including...
- digital certificates
- encryption
- digital signatures
Message-level security applies to XML documents that are sent as SOAP messages, embedding required security information in the SOAP header of a message. Encryption and digital signature apply to the data in the message itself.
With message-level security, the SOAP message itself either...
- contains the information needed to secure the message
- contains information about where to get that information to handle security needs
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.
Web service clients add to the SOAP message header security information. When the message is received the Web service endpoint uses the security information in the header to...
- verify the secured message
- validate it against the policy
For example, the service endpoint might verify the message signature and check that 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.
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 WS-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 WS-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...
- message parts within the generated message must be encrypted
- message parts to attach encrypted Nonce and time stamp elements
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>). 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.
Other forms of authentication include...
- identity assertion
- LTPA tokens
- Kerberos tokens
- custom tokens
With updates to WS-Security v1.1, we can layer additional functionality on top of these basic mechanisms, including signature confirmation and encrypted headers.
The security token profiles supported by WAS include...
- Username token profile
- X.509 token profile
- Kerberos profile
When messages are received, the Web service endpoint uses the security information in the header to apply the appropriate security mechanism.
The service endpoint can add signature and encryption information to the SOAP message headers, as well as other information, such as security tokens bound to the SOAP message content.
We can implement these new mechanisms by 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, added in WAS V 7.0, 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.
The WS-Security policy is specified...
- In the IBM extension of the Web services deployment descriptors when using the JAX-RPC model
- In policy sets when using the JAX-WS model
High-level architecture
Here is the standard high-level Web services security architecture ...
