What security concerns are addressed by the WS-Security standard? Very briefly describe how each of these concerns are handled.
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.
Hannah Smalltree, Editorial Director
The overarching solution that WS-Security provides is security for multi-hop XML messaging. In particularly, it is designed to provide the security for SOAP messages. At a high level it supplies a means to transmit authentication evidence pertaining to the initiator and, if different, the sender of the message by means of security tokens. This evidence may be used by the receiver to verify the initiator and sender of the SOAP message. The other two major constituents of WS-Security are digital signatures, which support integrity, i.e. proof that the message has not changed, and XML encryption, which supports confidentiality, i.e. encrypts the message so that only the intended receiver can read it.
Some of the specific threats that WS-Security can protect against are listed below. The syntax is the threat followed by the defense.
Un-authenticated sender – Use tokens and digital signature
Unauthorized receiver – Use XML encryption
Replay – Digital signatures alone are not enough to defeat replay. Other parts of the specification must be used with d-sig, such as timestamp, sequence number and nonce.
Token Substitution – Sign both the security header and the body.
Message modification – Sign the message
Message substitution - Sign both the security header and message body
Man-in-the-middle – Sign both the request and response
Multiple tokens using the same key – Require that the token be included in WS-Security header.
While WS-Security provides the means to protect against these attacks, it is up to the users of WS-Security to apply the appropriate protections depending on the level of risk management required. For example, if a sender is requesting a casual stock quote they might not deem it necessary to use the above protection mechanisms. However, if they were buying a stock then they would want to protect against the above threats. The receiver of the request may have different risk requirements and thus require some of above mechanisms, which are not important to the sender. For example, for the request for a quote, they may require authentication and additionally may require different level of authentication for different value transactions.
Some of the specific threats that WS-Security can protect against are listed below. The syntax is the threat followed by the defense.
Un-authenticated sender – Use tokens and digital signature
Unauthorized receiver – Use XML encryption
Replay – Digital signatures alone are not enough to defeat replay. Other parts of the specification must be used with d-sig, such as timestamp, sequence number and nonce.
Token Substitution – Sign both the security header and the body.
Message modification – Sign the message
Message substitution - Sign both the security header and message body
Man-in-the-middle – Sign both the request and response
Multiple tokens using the same key – Require that the token be included in WS-Security header.
While WS-Security provides the means to protect against these attacks, it is up to the users of WS-Security to apply the appropriate protections depending on the level of risk management required. For example, if a sender is requesting a casual stock quote they might not deem it necessary to use the above protection mechanisms. However, if they were buying a stock then they would want to protect against the above threats. The receiver of the request may have different risk requirements and thus require some of above mechanisms, which are not important to the sender. For example, for the request for a quote, they may require authentication and additionally may require different level of authentication for different value transactions.
This was first published in December 2003