SAML 1.0 Signals Next Step in Evolution of Web Services Security

Industry analysts provide insight on SAML’s role among other prominent security standards

• By Matt Migliore
• 11/20/2002

SAML is an XML-based framework for Web services that allows the exchange of authentication and authorization information among independent networks. Through it, enterprises can enable a number of Web-based security functions—such as single sign-on and role-based access control (RBAC)—across sites hosted by multiple companies. Furthermore, SAML provides security functionality for more complex Web services integration, whereby Web services have the intelligence to reach out to a number of other components to perform a given task.

Prior to its official 1.0 release, SAML had been receiving significant support among the vendor community. However, on the user side, SSL (Secure Sockets Layers) was being implemented to secure Web services, and another emerging standard, WS-Security, was also gaining momentum.

Now that SAML 1.0 has been approved, it’s unclear how these standards and others, such as Public Key Infrastructure (PKI), will fit into the Web services equation.

To help answer some of these questions, Security Strategies held a brief Q&A session with James Kobielus, a senior analyst with Burton Group, and Ray Wagner, a research director with Gartner Inc.

Security Strategies: Will the approval of SAML 1.0 help stimulate the use of Web services for external integration efforts?

James Kobielus: As an open Web services security standard with broad vendor support, SAML 1.0 will stimulate use of Web services for external integration among organizations' line-of-business applications (such as ERP and procurement). SAML 1.0 is one of the most fundamental interoperability standards for Web services security. Even in advance of the standard's formal ratification by OASIS, SAML 1.0 had already gained broad acceptance, adoption, and implementation by many vendors of Web services security products, especially vendors of Web access management platforms, including vendors such as IBM, Sun, Netegrity, Oblix, Entrust, Entegrity, and Novell.

Many of these vendors have already demonstrated some basic SAML 1.0 interoperability scenarios among their products, supporting standards-based single sign-on (SSO) and RBAC across Web services environments. Enterprises who use these vendors' Web access management tools are demanding the ability to do standards-based Web SSO and RBAC with their external trading partners, such as in extranet environments. By leveraging XML, SOAP, HTTP, and SSL, SAML 1.0 allows organizations to implement these Web security services over their existing firewalls and intranet/extranet infrastructures.

Formal ratification of SAML 1.0 by OASIS should provide enterprises with further confirmation of the standard's importance in the expanding universe of Web services security products and services.

Ray Wagner: Enough security is provided by current Web mechanisms (SSL with two-way authentication) to manage development of simple point-to-point Web service integration efforts. SAML's core functionality is around the use of identity information by communities of interest. As such, SAML is not generally necessary for simple integration efforts. However, because SAML provides another important building block toward complex Web services, it adds to the foundation of standard functionality, which will be leverageable by enterprises for their needs around Web services.

Security Strategies: OASIS is positioning SAML as something that's going to reinvigorate interest in PKI by giving it relevance in the Web services world. Do you agree with that sentiment?

Jim Kobielus: SAML 1.0 will not necessarily reinvigorate interest in or implementation of PKI beyond PKI's limited role in today's Web services environment. PKI is primarily used today to enable server-side SSL, and SAML will primarily leverage server-side SSL for secure sessions among SAML-enabled Web security platforms.

Consequently, PKI will play a role—albeit limited to server-side SSL—in SAML implementations. But SAML does not require new or enhanced PKI capabilities, such as client-side SSL or digitally signed SAML assertions. And it's very unlikely that SAML implementors will layer these additional PKI capabilities on SAML-based Web services security environments when server-side SSL is sufficiently secure for most real-world applications, internal or external to organizations.

Ray Wagner: Most security mechanisms associated with Web services, including SAML and WS-Security, will require the use of public key techniques. SAML and WS-Security provide a platform on which complex workflow-based Web service business models can be deployed. However, just because the functionality is there does not mean it will be used in complex ways.

At Gartner, we think most Web services deployed across the firewall through 2005 will be simple, point-to-point implementations that have security based on SSL server certificates only. Because this infrastructure is already mostly in place, organizations likely do not need to invest in enterprise public key infrastructures at this point.

However, if complex Web service deployments become the norm, enterprise public key capabilities will be required. PKI may also get a boost from newer mechanisms for key management that are designed to make PKI more manageable, like the XKMS standard.

Security Strategies: I've heard a lot of people talk about using SSL to deploy "secure" Web services. What does SAML offer above and beyond SSL when it comes to Web services security?

Jim Kobielus: SAML uses server-side SSL to support encryption of content flowing over HTTP/S sessions between SAML-enabled servers that are doing Web SSO and RBAC. What SAML offers over and above SSL is a SOAP-based messaging protocol for Web SSO, plus XML-based data structures—known as SAML assertions—that are exchanged between SAML-enabled servers over this messaging protocol, plus implementation profiles describing how users can transparently access SAML-based Web security services through standard Web browsers.

Ray Wagner: SSL will work for simple deployments at the enterprise-to-enterprise level, and provides channel encryption and a mechanism to authenticate the communicating servers. SAML provides the ability for the enterprise to vouch for the identity, authentication mechanism, and authorization rights of users—both human and programmatic—of another enterprise's services. Simple server-to-server Web services can get by with SSL; complex user-based interactions will likely require SAML.

Security Strategies: How do you see WS-Security and SAML working together in a Web services environment?

Jim Kobielus: The SAML 1.0 standard places SAML assertions in the body of SOAP messages to support Web SSO and RBAC services. In future versions of the SAML standard, OASIS is also likely to include the option of putting SAML assertions in SOAP message headers, thereby allowing SOAP messages to contain any XML-based business document—such as an electronic purchase order—in the SOAP message body and also to contain the full security context for that business document—as described in SOAP authentication, attribute, and authorization decision assertions—in the SOAP message header. This proposed SAML "SOAP profile" will be useful for EDI and e-business over Web services environments.

The proposed SAML SOAP profile is similar to what's defined in WS-Security. WS-Security supports carriage of various types of security credentials—such as SAML assertions and Kerberos tickets—in the SOAP message header. It's very likely that WS-Security will be used as the primary basis for the future SAML SOAP profile. Both the SAML and WS-Security standards are managed by OASIS, and various OASIS participants have indicated an intention to explore integration scenarios involving these standards.

Ray Wagner: WS-Security may offer SAML-like functionality in the future, but at this point the functionalities of WS-Security and SAML dovetail nicely together. WS-Security offers a secure transport mechanism with fine-grained control of message elements through configurable encryption and digital signatures. SAML provides a mechanism for enterprises to make assertions about identities, which need to use external services that can be accepted by the external service provider. The combination of these functionalities provides most of the building blocks for allowing the creation of secure Web services.