The idea of business partners sharing security policies for electronic transactions is relatively new. Until the advent of Web services and service-oriented architecture (SOA), most electronic business transactions were conducted through a third party, most often in the form of an electronic data interchange (EDI) value- added network provider (VAN). The EDI VAN would define suitable individual security policies and rules applied to all transactions between itself and customers; the EDI VAN would then broker these transactions between partners in a hub-and-spoke model. As organizations have begun to adopt Web services, the role of the EDI VAN in B2B transactions has diminished. Web services provide a standards-based document and communications model, allowing partners to communicate directly in a secure, reliable way. This does, of course, require partners to understand how each other’s services work, and how requests must be secured, monitored and managed.
Imagine two fictitious companies engaging in direct Web-services- enabled business transactions. The first company is an aircraft manufacturer, ACME aircraft. The second is an airline, FLIGHT, that uses ACME airplanes. It is easy to see how FLIGHT’s purchasing systems, driven by maintenance staff managing parts inventory would determine that it’s time to purchase more tires, for example, and could connect to a Web service published by ACME to order. This simple standards-based Web service request could easily and inexpensively be initiated by the FLIGHT systems, and just as easily and inexpensively be processed by the ACME order-fulfillment systems. ACME’s systems would process the order, ship the tires and bill FLIGHT. And, on the surface, that’s that.
Of course, the real world isn’t quite as simple. ACME will require certain assurances, such as the knowledge the order really came from FLIGHT; that the order has not been tampered with; that the initiating FLIGHT person or system was authorized to do so; that the order was not seen by competitors in pursuit of competitive insight; and that a solid audit trail exists to verify the order was generated, sent, received and processed. The paper-purchasing process originally handled these assurances, more recently the EDI VAN managed them, and the Web-services product that enables the business process now provides them.
Enter SOA and Web services security standards and products. Vendors, end users and industry standards have defined and agreed on a dizzying assortment of standards for ensuring the reliability and security of Web-services transactions. The elegancy through simplicity promised by Web services has not been lost, but it has certainly been obscured. The core standards addressing security layer easily into the basic SOAP, WSDL and UDDI model that defines Web services. The basic security standard is called WS-Security, which provides a mechanism to define security technologies applied to a particular message. This information is carried in the form of SOAP headers in the message itself. In this example, the SOAP header would carry credentials to authenticate the user or system, and often, additional information that allows the receiving service to authorize the transaction. It would also carry instructions to the receiving system on which elements of the message are signed and/or encrypted, and how it should verify the signature, or decrypt the message. Hand-in-hand with WS-Security, there are a wide array of standards used to provide message authentication, signature and encryption mechanisms.
There are different standards for representing user credentials, the most commonly accepted of which is the Security Assertion Markup Language (SAML). SAML allows an issuing authority to authenticate a user and issue a token, a SAML assertion, to confirm its identity to another system.
The most commonly used signature mechanism for Web services is described in a standard called XML-Signature, or XML-DSig, which XML-DSig provides a well-defined approach for cryptographically signing a message in such a way that the receiving system can prove that the message was undeniably sent by a particular entity, and also that the message has not been altered.
Cryptography plays an important role in ensuring message privacy. A standard, XML-Encryption, provides a way to encrypt anything in an XML document. Encrypting the message with a symmetric key, and then sending a version of the key encrypted so that only the intended recipient can decrypt the key to unlock the message, ensures privacy.
The real problems are ensuring that companies can determine which technologies are required by a business partner, that they can be implemented correctly; and that they can recognize when requirements change and can react appropriately to ensure seamless business continuity.
A suite of standards under the banner of WS-Policy addresses the technology part of the problem. WS-Policy standards include a means of defining and describing policies enforced by a particular Web service. WS-SecurityPolicy allows a provider to describe to potential users the various authentication, signature and encryption models it implements and requires. WS-Policy also includes a standard, WS-PolicyAttachments, for associating policy information with services in a UDDI registry and directly in the WSDL document that describes the service interfaces. Finally, not quite within the WS-Policy specification, but related nevertheless is WS-MetadataExchange (WS-MEX). WS-MEX provides a means for a potential consumer of a service to query the service to discover its policy requirements. The WS-Policy concept makes implementation and enforcement of policy a technology problem addressed at runtime by a suitable solution.
Of course, these standards and technologies are useless if organizations don’t implement or enforce them.
Alistair Farquharson is CTO of SOA Software; Ian Goldsmith is vp of product marketing at SOA Software.
