- What Are WS Security Initiatives?
- WS Security SOAP Extensions
- WS Security and SAML
- Web Services Security Stack: the Big Picture
- Future of WS Security
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
WS Security SOAP Extensions
As indicated previously, WS Security's SOAP security extensions define specifications for building security information right into SOAP message headers. The present draft specifically covers how to add encryption and digital signature information to SOAP headers—as well as means for exchanging security tokens across different services.
In other words, the specification currently addresses three major areas of security:
Security token propagation
Message integrity
Message confidentiality
Note that "authentication and authorization" (another core concept of Web services security) is missing here! There are very specific reasons for this (see "WS Security and SAML" later in this article).
A security token represents a claim or collection of claims made by the client regarding his identity and privileges. For example, when you submit your username and password for authentication into an email system, you are making a claim that you are an identity who is registered with the system. In this case, the username/password represent your security token.
This is rather a very simple example. Actual security tokens take the form of signed security certificates issued by trusted third-party service providers such as VeriSign. For example, the X509 certificate substantiates a client's ownership of a given encryption key.
WS Security makes use of security tokens, in conjunction with XML encryption and XML digital signatures, to provide integrity and confidentiality to SOAP messages transmitted across the services.
Regarding specific implementation details, WS Security talks about one or more <Security> blocks that encapsulate security-related information within SOAP headers. My previous article discussed the fact that conventional security mechanisms fail because Web services interactions are essentially many-to-many, not point-to-point. WS Security intuitively addresses the issue of propagating multiple types of security information to multiple recipients—as detailed below.
Every <Security> block must have an S:actor attribute, which signifies the SOAP actor who is either an intermediary or the ultimate recipient of the SOAP message. Subsequently, there can be many <Security> blocks, each with an independent S:actor attribute, depending upon the number of different recipients for a given secure SOAP message. (However, there can be one—and only one—<Security> block without an S:actor attribute, and it can be read by one and all.)
Intermediaries can modify the existing <Security> blocks with additional information—provided they have the necessary privileges.
This can be illustrated further with the Web services interaction scenario discussed earlier: Service A transmits some XML information to Service B; it then adds some more data and passes it on to Service C, the end consumer. Figure 1 simplifies the WS Security-based solution.
)
Figure 1 Web service interactions using WS Security SOAP extensions.
As shown in the figure, Service A sends a SOAP message to Service B with <Security> blocks. Because Service B simply adds additional information to the existing message, it modifies the <Security> header appropriately, and passes the message on to Service C. Service C uses the information contained in the <Security> header information to ensure that it is coming from authentic sources A and B, and has not been tampered with while in transit.
Again, this is a very simple example; real-life interactions can be complex. For example, consider that the <Security> header(s) may have to be modified if Service B has to decrypt the information coming from Service A, process the elements, and then evolve the data to be sent to Service C.
Elements in the <Security> block contain sequential information on how the sender encrypted and signed the confidential message. Because this sequence is important for the receiver to decrypt the message, modifications made by intermediaries within the <Security> blocks should always be appended to the existing elements.
Based on our discussions so far, we can construct a SOAP message with WS Security extensions—like the one shown in Figure 2.
)
Figure 2 SOAP message with WS Security extensions.
Beyond this broad outline, WS Security does not enforce any subelements within the <Security> block. However, it does recognize certain elements that may be widely featured in all implementations, as follows:
<UsernameToken> element: Enables the addition of the username, password, and other essential authentication information required. The specification does allow the addition of customized elements for extensibility.
<BinarySecurityToken> element: Allows security tokens in non-XML formats (such as the X509 certificate) to be encoded and added within the <Security> block.
<SecurityTokenReference> element: Enables provisioning a URI for security token information. If the token information is not transmitted along with the message, then the client can use this element to reference a remote URI, which actually hosts the security token. Usually, this domain is that of a trusted third-party service provider.
XML digital signature elements: Elements defined by the XML digital signature specifications, such as <ds:KeyInfo> and <ds:Signature>, are used in the same context—the difference being the fact that they are featured inside the SOAP header. Moreover, WS Security recommends the use of the <BinarySecurityToken> element over the <ds:KeyInfo> element for transmitting key information across the services because the latter is considered to be more secure. Otherwise, WS Security fully embraces the recommendations of XML digital signature specifications by W3C. (For a detailed discussion of <ds:...> elements, see my previous article on XML digital signatures.)
Encryption subelements: With some subtle differences, elements from XML encryption specifications are reused here. These include <xenc:ReferenceList>, <xenc:EncryptedKey>, and <xenc:EncryptedData>.
The WS Security group recognizes SOAP security extensions as the foundation for all its future efforts.