Event

On 27 March 2007, the Organization for the Advancement of Structured Information Standards (OASIS) approved two key Web services security components as OASIS standards. The OASIS Web Services Secure Exchange (WS-SX) Technical Committee formally ratified:

• WS-SecureConversation version 1.3, for establishing and maintaining extended secure sessions
• WS-Trust version 1.3, for obtaining and exchanging security credentials

Analysis

OASIS's ratification of these security standards — following extensive participation by major players in the Web services and service-oriented architecture (SOA) communities, including verified implementations by IBM, Microsoft and Sun Microsystems — moves Web services secure messaging from basic and limited implementation to a more extended and contextual model. However, the real value of these standards lies in the benefits they can provide for implementations of brokered authentication or security token services (STSs). Web services typically authenticate clients across heterogeneous environments — and removing the need for a direct relationship with the client application and Web service through a “trust negotiator” requires robust security. Enterprises interested in using brokered authentication simply did without Web services authentication or implemented it on various platforms as needed. Indeed, the bulk of Web services use today continues to be middleware within enterprises, in part due to these security limitations.

The availability of these new standards means that Web services security has finally reached an acceptable maturity level. The issuance and dissemination of credentials between different trust domains via an STS can now be achieved using a syntax that is familiar to most developers. The OASIS standards also provide for a scalability that had not been available before in transactional Web services that required an STS — at least not in a standardized form with which most vendors involved in SOA applications and infrastructure comply. This adds tools to a credible toolset for credible federation efforts, which has proved elusive to many enterprises, due to the issues of brokered authentication availability and scalability the standards address. WS-Trust alone is vital to enabling the credential use necessary for networked, consumable Web services.

Some early adopters of Web services continue to believe that existing security standards are bloated and overly complex, and have implemented leaner, proprietary approaches. For simple requirements, mixed Web security and "classic" authentication coupled with services will still have a place. Other early adopters believe that IBM's and Microsoft’s view of Web services and SOA security — and particularly their roles in the development of WS-SecureConversation and WS-Trust and the standards' place in their architectures — gives them an advantage in this area. However, the standards have enough diversity of support within the developer and infrastructure community that their ratification must be viewed as a positive development for vendor and enterprise customer alike.

Enterprises designing or developing SOA, software as a service (SAS) or Web services projects involving authentication that could use STSs:

• Evaluate your development framework’s implementation of WS-SecureConversation and WS-Trust to determine their applicability.

Enterprises using third-party Web services:

• Consult with your service providers to determine their plans regarding these standards and their use in their service offerings for STSs.
• Take a leadership role within your Web services partnership network (consistent with your established security policy) to guide partners in reviewing and evaluating the applicability of WS-SecureConversation and WS-Trust standards adoption.

• "Best Practices Checklist for Web Services Security, 2006” — The security practices on a Gartner-developed checklist can help protect Web services deployments against most current threats. By Ray Wagner
• "Findings From the 'Information Security and Privacy' Group: Convergence of Liberty and WS-Federation Must Become a Reality” — Enterprises cannot consider identity federation technology strategic until the Liberty and WS-Federation protocols converge. By Ray Wagner

(You may need to sign in or be a Gartner client to access the documents referenced in this First Take.)