Anybody who's been following application development trends for any time knows that Web Services is fast becoming the veritable "hot seat" of the development world. It's where the action (and the money) is, and has become a line of business if not an outright obsession for everybody from Apple to Zend, with little outfits like Microsoft, IBM, Sun and others happily carving out their own little domains.
But on the Internet, not only may nobody know you're a dog, everybody is also likely to cross your transom at one time or another. Thus, interoperability, information exchange and trust have become huge issues. Likewise, the Internet has shown the hard, cruel, unflinching light of reality harder on little design flaws in interfaces and applications more regularly (and often, more damagingly) than other forms of use have allowed. Buffer overflows, lack of input validation and naÏve assumptions about user intentions and capabilities have led to great, big, gaping holes in supposedly secure infrastructures and in operating systems, runtime environments and applications alike. On the Internet everybody shares the same security problems.
What's a body to do? The W3C and OASIS are two cooperating bodies that are hard at work at defining an increasingly able and sophisticated Web of interfaces and specifications aimed to up the security ante for Web services. These include (but are not limited to) the following:
- WS-Security: Describes how security tokens may be used to assure message integrity, establish and assess confidentiality, and authenticate message senders.
- WS-SecureConversation (WS-SC): A building block for creating secure contexts within which multiple message exchanges may occur between organizations without requiring constant re-authenticaion.
- WS-SecurityPolicy (WS-SP): Defines a general set of security policies that may be associated with a Web service; used to enable expression of supported security exchange patterns as expressions of policy associated with specific SOAP endpoints.
- WS-Trust (WS-T): Provides a description to establish and manage or assess trust relationships between parties that wish to exchange information; used to enable obtaining of security tokens and brokering of trust relationships.
- WS-SecureExchange (WS-SX): designed to enable the trusted exchanged of multiple SOAP messages with defined security policies to govern the formats of and tokens inside such messages.
This infrastructure will ultimately consist of a set of modular specifications (use the ones you need, ignore the ones you don't) to standardize concepts, WSDL documents and XML Schema renderings so that trusted brokering of SOAP messages may occur, shared security contexts be established and security policies stated and checked for compliance.
Other key related efforts at OASIS include the Web Services Reliable Exchange (WS-RX) project, the Web Services Transaction (WS-TX) project and the Web Services Security committee. Key goals include developing functions to state security policy expressions and to maintain ongoing conversations (exchanges of information) over time.
The clear thrust of these developments is to define standard service building blocks that developers can use to establish, maintain and assess security as it relates to policy, communications and information exchange. Though mastering the many bits and pieces involved can take considerable time, effort, and energy the benefits are substantial enough to persuade companies like IBM, Microsoft, Adobe, BEA Systems, Computer Associates, Novell, Oracle, SAP and VeriSign to build support for these specifications. Smart developers everywhere would be wise to do the same. Start digging in at the OASIS Security Committee headquarters online.
About the author
Ed Tittel is a fulltime writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. E-mail Ed with comments, questions, or suggested topics or tools for review.
This article originally appeared on SearchWebServices.com.
