In the pursuit of Web services security, there are two main approaches. The W3C takes an encryption and XML approach to ensuring that data from Web services cannot be intercepted. OASIS (And the WS-I before they handed their work over to OASIS) takes a security token-based approach to ensuring only authorized users have access to Web services. Last month we took a look at the
The OASIS standards in general are commonly referred to as WS-* standards. WS stands for Web services, and the star is understood to stand in for whatever aspect the particular standard is addressing. For instance, the security standards are all built on the principles set forward by the WS-Security standard,often abbreviated WSS.
WS-Security proposes a standard set of SOAP extensions designed to allow for secure SOAP message exchanges. The standard is compatible with multiple security token formats, trust domains, security signature formats and encryption technologies. The standard provides the three main building blocks that form the foundation of OASIS's token-based security – message integrity, message confidentiality, and of course the ability to incorporate security tokens into messages. The OASIS website provides links to the standards of several of the most important security token profiles, including Kerberos and SAML.
Other OASIS standards have been built on top of the WS-Security standard in what could be thought of as a Web services security stack. WSS forms the base. On top of this were built WS-Trust, WS-SecureConversation and WS-SecurityPolicy, with each new standard building off the standards that came before it. At the very top of the stack is SAML.
WS-Trust was the first to build off of WSS. Early on, it was realized that in addition to standardizing the exchange of security credentials, it would be necessary to ensure that security credentials could be trusted. WS-Trust sought to enable applications to construct trusted SOAP message exchanges by providing a flexible set of mechanisms designed to support a wide range of security protocols. WS-Trust supplies methods for issuing, renewing, and validating security tokens, as well as ways to establish and maintain trust relationships between applications.
With rules for creating and maintaining trust as well as rules for security token creation and exchange, Web services were much more secure. But there were still holes in the system. WS-SecureConversation introduced and utilized the concept of security context to help fill the gaps in WS-Security and WS-Trust. According to the WS-SecureConversation 1.3 OASIS Standard, "security context is an abstract concept that refers to an established authentication state and negotiated key(s) that may have additional security-related properties."
The WS-SecurityPolicy standards connect WSS and the related standards to the WS-Policy framework, which is how WS-* compliant Web services express restraints and requirements. WS-SecurityPolicy defines policy assertions for use with all the other WS-* security standards in order to provide the information necessary to determine Web service interoperability and to enable the modularity among the security protocols of various Web services. The standard is designed to work with all applicable versions of WS-Policy.
On top of all of the WS-* security standards, OASIS maintains SAML, the security assertion markup language. SAML is focused on enabling single sign-on (SSO) across multiple domains, providing attribute-based authorization, and of course providing better security for Web services. In order to enable SSO across multiple domains, the SAML approach dictates that service providers rely on identity providers. Principals and users enroll with identity providers to manage their secure identity. The third party identity provider system has a few advantages over browser cookies that require a one-to-one relationship with Web applications
By de-coupling the identity management tasks from the Web service provider, SAML enables end-users to sign-in once and gain access to multiple services because each service will refer back to the identity provider. This same decoupling also allows attribute-based authorization. The identity provider can and should maintain attribute information about users such as the user's position within the organization. These attributes can then be used by Web applications making authorization decisions. SAML also works with SOAP messages to provide security information to Web services. Therefore, SAML can and does act as a security token provider in the WS-Security framework.
Other Links on SAML: