Building the Foundation for Agile Computing

 <  Day Day Up  >  

This book comes at a very opportune time. As I write, the OASIS Web Services Security (WSS) Technical Committee has completed development of three WS-Security specifications and submitted them to the OASIS community for ratification. The specifications include the core security framework (SOAP Message Security) and two authentication token profiles (Username Token Profile and X.509 Certificate Token Profile).

The non-normative descriptions in the WS-Security specifications are pretty decent, but it's still dense reading. This book makes it quite a bit easier to comprehend all the facets of Web Services Security; plus, it aggregates information on all the underlying and associated security technologies that WS-Security relies on, such as SSL, PKI, XKMS, SAML, and a host of other acronyms. It's a reference book that I intend to keep handy.

In all my conversations with enterprise companies, security reigns as the number one concern in their plans to deploy Web services. And I can't blame them. Without a proper security infrastructure in place, Web services can expose sensitive corporate processes and information and leave a company open to risk and malfeasance ”from both internal and external perpetrators.

Traditional network-layer and perimeter security tactics, such as SSL, proxy servers, and firewalls, aren't sufficient to protect IT systems anymore. In the past, businesses maintained a clean separation between the applications that support internal business processes and those that manage interactions with external customers, partners , and suppliers. The former systems, referred to as intranet applications, typically require less stringent security. The latter systems, or extranet applications, require more. With clear boundaries set in place, perimeter security works reasonably well.

More recently, though, the boundary between internal and external business processes has become blurred, and the artificial separation of the two has stymied innovation. Business processes don't stop at corporate boundaries. The concept that "enterprise application integration" is somehow different from "business-to-business integration" imposes constraints and restrictions on a business. Business applications should be able to seamlessly execute the appropriate tasks required to complete a business process, regardless of which business entity hosts the application code.

The challenge, though, is enabling this cross-domain integration to happen in a secure and reliable fashion. Perimeter security tactics won't cut it. Instead, businesses need to deploy application-level security frameworks. WS-Security provides the foundation for implementing a comprehensive application-level security framework that supports both internal and external integration requirements, and with it agile computing.

To effectively compete in today's economy, enterprises need an IT environment that supports real-time responsiveness and enables business processes to seamlessly cross logical and physical boundaries. Unfortunately, many enterprises find that their IT systems aren't quite as agile as they'd like. Changes to a business process can take months to implement, and the opportunity costs are staggering. Seamless, dynamic integration with customers, partners, and suppliers remains elusive .

The inertia of most IT systems stems from their application architecture. Most applications are designed as monolithic and autonomous systems. Each application implements a complete business process, and the specifics of the process are hard-coded in the application. Any modification to the business process requires a corresponding modification to the application code.

So the industry is turning to service-oriented architecture (SOA) as a way to increase agility. SOA defines a set of principles and practices for designing application functionality as shared, reusable services. Developers can compose and recompose these services into orchestrated applications that implement a variety of business processes. With the proper infrastructure in place, an SOA-based environment can allow IT systems to respond rapidly to changing business conditions.

The Web services framework (WSF) supports this infrastructure. The WSF provides an open, vendor-independent, language-neutral middleware framework that supports application integration based on ubiquitous Web protocols. Unlike any previous middleware framework, the WSF has gained universal endorsement from virtually every software vendor in the industry. Vendors are adding WSF support to their platforms, tools, applications, and infrastructure products. The WSF is rapidly becoming as ubiquitous as the Web.

The WSF takes the Web to the next level, supplying the technology necessary to support real-time responsiveness and cross-domain integration. And perhaps more important, the WSF supplies a foundation for implementing SOA, which is the real key to business agility. The industry has been aware of the value of SOA for more than 20 years , but until now, technology has not really supplied the tools and standards necessary to make it practical.

But the WSF is still young. I characterize it as an adolescent ”strong, capable, and energetic ”but it requires supervision. In particular, it requires a robust security framework. This security framework must support end-to-end security, and it must work in conjunction with identity management systems. WS-Security provides the foundation for this security framework.

Now, that's not to say that Web services can't be secured without WS-Security. A number of companies have deployed secure Web services using SSL. But the capabilities and extensibility of these Web services are very limited when relying on the transport level to enforce security. SSL provides point-to-point security rather than end-to-end security. As Web services deployments get more sophisticated, IT organizations will start to deploy intermediary nodes between consumer and service to perform functions, such as monitoring, auditing, content-based routing, version mismatch resolution, reliability, and orchestration. SSL-based protection can't provide a seamless security infrastructure for these multi-hop requirements. Beside, SSL imposes a heavy burden on IT developers to implement a security management framework that maps transport-level authentication mechanisms to the back-end applications' authentication and authorization systems.

As companies begin to deploy more and more Web services, per-application security management will rapidly become untenable. When companies use WS-Security, all this low-level security functionality can be implemented, managed, and enforced using a combination of the Web services infrastructure and identity management. Companies will soon discover that Web services and identity management are inextricably joined at the hip.

Without identity management, developers must still manage security on an application-by-application basis. WS-Security currently supports two types of authentication tokens: simple username tokens and X.509 certificates. And while WS-Security with these tokens offers much more flexibility and granularity than SSL does, it also places an onerous burden on the developer to implement application-specific authentication and authorization mechanisms for username token, or ”even worse ”complex PKI processing facilities in every application for X.509 certificate processing. (See Chapter 3, "The Foundations of Distributed Message-Level Security," for information on PKI.) Any way you look at it, it's a much better idea to use centrally managed identity management solutions that abstract away complexity.

For this reason I'm somewhat disappointed that the OASIS WSS technical committee has not yet completed the specification that describes how to pass SAML tokens with WS-Security. (See Chapter 6, "Portable Identity, Authentication, and Authorization," for information on SAML.) SAML ”the Security Assertion Markup Language ”provides a standard, vendor-neutral, interoperable, and portable way to represent identity, and it has been adopted as the standard identity format by most identity management vendors. SAML also supplies a critical piece of the foundation that will eventually support identity federation.

Federation is a more challenging task than simple integration. Federation hinges on the notion of bridging domains ”areas of control that manage infrastructure issues such as identity, transactions, provisioning, and the like. To achieve federation, separate domains must establish trust relationships, common protocols, and governance structures that permit them to coordinate their activities. Therefore, federation requires some type of cross-domain interoperability framework within which autonomous entities honor each other's decisions and trust each other's assertions. The most basic part of federation, therefore, is a standard syntax and data format to represent identity and assertions ”that is, SAML.

Fortunately, integration between WS-Security and SAML is just a matter of time. The next work items on the agenda for the OASIS WSS technical committee are to complete the token profile specifications for SAML assertions, XrML licenses, and Kerberos tickets. The committee plans to publish these three token profiles simultaneously .

Another encouraging development is that the Web Services Interoperability Organization (WS-I) has initiated a working group to create an interoperability profile for Web services security. The forthcoming WS-I Basic Security Profile (WS-I BSP) will provide guidelines for developers to aid in the creation of secure, interoperable Web services. The working group has published a draft requirements document called "WS-I Security Scenarios" that outlines the set of issues and use cases that the profile should address. The WS-I BSP will define an interoperability profile that supports transport-level (SSL) and application-level (WS-Security) security. It will include support for any tokens that have been standardized by the OASIS WSS technical committee, and periodic updates will maintain parity with new token profiles as they emerge.

So, the future looks bright for IT agility. The combination of Web services framework and identity management will enable real-time responsiveness and borderless application systems. WS-Security is the critical component that ties these two technologies together. Web services infrastructure vendors, such as Actional, BEA, DataPower, IBM, IONA, Microsoft, Oracle, SAP, Systinet, Westbridge, and others, already provide support for WS-Security within their products. And many also support SAML.

Developers need to be prepared to start using WS-Security and SAML. This book is a great place to start.


Anne  Thomas  Manes
VP  &  Research  Director
Burton  Group
March  7,  2004

 <  Day Day Up  >  


Securing Web Services with WS-Security. Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption
Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption
ISBN: 0672326515
EAN: 2147483647
Year: 2004
Pages: 119

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net