By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
WSS builds on top of XML Encryption and XML Signature from W3C and specifies how to apply them to SOAP-based Web services. It defines the way to establish message confidentiality (using XML Encryption), establish message integrity (using XML Signature), and add a variety of predefined and custom security tokens for purposes such as authentication and authorization -- using a username token, SAML and other WSS profiles -- specifically for SOAP messages with attachments (SwA).
WSS does not, however, cover issues such as messaging patterns, how to describe the security mechanisms it enforces in WSDLs or how to establish trust relationships between different endpoints.
WS-Trust is an extension to WS-Security. In WS-Security, the validity of exchanged credentials, such as a username and password, is assumed. WS-Trust provides methods for issuing, renewing and validating security tokens and means for establishing and assessing broker trust relationships.
For example, a Web service provider may require certain claims to consume messages from a Web service client and describe them using WS-SecurityPolicy/WS-PolicyAttachment. The service client may need to acquire the appropriate tokens from a security token service -- an authority directly or indirectly trusted by the service provider. In this case, WS-Trust can be used as an XML language to acquire these tokens from the authority. WS-Trust also describes the way to exchange multiple messages as part of the token acquisition process from the authority by defining a challenge-response protocol. WS-Trust, however, is agnostic to the type of tokens that are exchanged or negotiated. It merely provides the wire-frames to wrap and exchange tokens within SOAP messages.
WS-Policy is a general XML syntax model for describing the policies of an entity in a Web service system. It is orthogonal to SOAP, WSDL and all the other W3C specs; it is a general policy language that does not define any relationships with these other specs. WS-Policy does not specify policy domains or application contexts, as it is just an abstract framework for wrapping your own policy semantics. WS-Policy defines methods for specifying assertions and explains how to nest policies within other policies. It covers concepts such as equivalence, whether something is required all the time or optional, whether one or all of the policy assertions need to be satisfied, and other abstract ideas.
WS-PolicyAttachment is a relatively small specification that describes how to associate WS-Policy protocols with WSDLs and UDDI registries. In essence, WS-PolicyAttachment explains how to include these policies inside WSDLs and UDDI entities.
WS-SecurityPolicy is a specialization of the generic WS-Policy. It builds on top of WS-Policy to specify WS-Security and WS-Trust policy semantics. It defines the way to describe assertions for username tokens, X509 tokens, SAML tokens, SSL requirements, algorithms accepted for signatures and encryptions, etc.
WS-Reliability addresses reliable SOAP message exchange based on a Quality of Service contract between the service providers and consumers. The features it addresses are guaranteed message delivery and guaranteed ordering within a message group. For instance, it defines how message reception acknowledgments or sequencing data are communicated within SOAP messages.
WS-Reliability does not relate directly to WS-Security, WS-Trust or WS-Policy. However, it can be composed with these specifications. One could use WS-Reliability to deliver an "exactly once" SOAP messages that is signed according to the WS-Security specs, for example.
In conclusion, WS-Trust builds on top of WS-Security. WS-PolicyAttachment and WS-SecurityPolicy both build on top of WS-Policy, and WS-SecurityPolicy assertions can certainly be used with WS-PolicyAttachment. WS-Reliability does not relate directly with any of the previous specs, but it can be combined with them in Web services system. Composability is a property that is inherent in WS- specs. It allows for different fusions of these orthogonal WS- standards to address combinations of Web services requirements.
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.