|
Wednesday March 13 2002 Web Services Security Current status and the future At the InfoWorld Next Gen Web Services conference in January 2002, 51% of the attendants considered security the single largest obstacle to general acceptance of Web Services. Are these fears warranted, or are these people just scared of something they don't fully understand? Is the security of Web Services so precarious? Can we overcome these problems so that businesses and the general public will trust these services? We'll take a look at these issues and give our evaluation of the situation. By security we mean the protection against unauthorized reading, modification, or destruction of information. Obviously, there are many degrees of security; we consider here the level required for e-commerce, where a system penetration could mean the loss of large amounts of money and of business prestige. There are two basic security models that apply to Internet systems: the access matrix, and Role-Based Access Control (RBAC) (see R. C. Summers, Secure Computing: Threats and Safeguards, McGraw-Hill, 1996). The most common model now is RBAC and most new systems support this model. Another concern is privacy, the right of individuals to have control of their personal information. A basic principle of security is the need to secure all the levels involved in the Web Service; any weak level will permit attackers to penetrate the system. These levels include:
We will call these levels the Web Service levels. It should be noted that they require supporting layers that we don't discuss in this article. The following diagram shows one of these supporting layers, the HTTP layer.
The Web Service Levels These levels consider the definition and storage of Web Services and their incorporation into business processes. The Workflow level is defined by languages such as ebXML (http://www.ebxml.org/, Introduction to ebXML), RosettaNet (http://www.rosettanet.org/), and BizTalk (http://www.biztalk.org/). There is another specification for this level: XLANG (http://xml.coverpages.org/xlang.html), originated by Microsoft. To my knowledge none of the organizations responsible for these languages has defined security standards or recommendations for security specifications (ebXML has recommendations for the catalog and description level). The next Web Services level is concerned with the cataloguing and description of Web Services. The Universal Description, Discovery, and Integration (UDDI) committee has defined some general security guidelines with few details (http://www.uddi.org/specification.html). These policies include:
On its part, the ebXML committee defined in May 2001 detailed security specifications for registries. These requirements apply to authentication, integrity, and confidentiality. They specify, among other things, that each request must be authenticated and any known entity can publish or view what has been published. There is already a good amount of research on XML security and a standard, XML Access Control Markup Language (XACML), is under development. This language is based on the access matrix model (see Summers) and can define authorization rules for each element of an XML document or for whole documents. A rule has a subject (requesting entity), a right (read, write, etc.), an object (the document element), and a condition (for example, day of the week when access is permitted). XACML (http://www.oasis-open.org/committees/xacml/) is being developed by a special technical committee of OASIS, and it combines work of the IBM Tokyo Research Lab and the University of Milano, Italy. Similarly as for transmission, each element of a document can be encrypted according to the XML Encryption standards mentioned below. Finally, the document schemas, DTDs, and DOMs can also be used to provide security. Because documents may contain links to other documents, the security constraints applied to a document must consider also the security of these links. These aspects, however, are mostly at the research stage and just starting to be considered in products. Because Web Services are used in distributed environments, their data, code, or descriptions must move across different security domains. If a Web Service moves to another security domain, it must carry its security restrictions so that the other domain can properly handle the Web Service. This propagation is done through the Security Assertion Markup Language (SAML, see http://www.saml.org/ and http://www.oasis-open.org/committees/security/). SAML defines authentication and authorization assertions encoded in XML. Similarly to the ebXML registry model, this security model appears rather ad hoc and does not follow standard security models, which may result in inconsistencies. Nevertheless, SAML has already been incorporated into several security products. The Communications Level The Simple Object Access Protocol (SOAP) defines the communications level. There are other protocols proposed for this level, but they have not gained general acceptance. SOAP itself has no security; all of its security comes from the SOAP Security Extensions. These extensions have been defined by the W3C XML Encryption Working Group (http://www.w3.org/Encryption/2001/). One of these standards, XML Encryption, defines a process for encrypting and decrypting messages considering the granularity of the message contents. This can be as small as one element (including start/end tags) or apply to the element content (between the start/end tags). Super-encryption is possible, where the whole message with parts encrypted can be encrypted again, as is done when SSL is used for secure transmission over HTTP. A variety of encryption algorithms can be used, including the Advanced Encryption Standard (AES, see http://csrc.nist.gov/encryption/). There is a related standard for digital signatures, also from the W3C. A SOAP message includes a header and a payload. As shown in the following diagram, SAML assertions can be included in the header or in the payload.
XML encryption protects the secrecy of the message. A Public Key Infrastructure (PKI) can be used to provide authentication, digital signatures, and key distribution. This PKI can be simplified by the use of XML Key Management Specification (XKMS), intended for the integration of PKI and digital certificates. For example, digital signature processing can be delegated to a Web Service in order to further simplify the PKI structure. XKMS is an open standard that applies to any vendor PKI approach. PKI can also be used without XKMS. Web Services Providers Several companies that specialize in component development are converting these into Web Services. They are responsible for the contents of the Web Services they provide. Web Services can be implemented in any language that can process XML, and may include a variety of functions. They may be quite complex and hide Trojan Horses or be infected with viruses or worms. Certifying that a program doesn't contain malicious software is what computer scientists call an undecidable problem; there is no method to guarantee that a given program is free of malicious code. Web Services will be trusted based on their origin and general fame, but there is no guarantee for the consumer. Certified software only proves the origin of the software and can guarantee a given functionality, there is no guarantee of the security of its contents. Naturally, vendors who develop their services carefully will be more trusted. As David Guinan said in his Software Development East 2001 keynote speech, Web Services are about trust. Conclusions We have looked at some of the aspects that have an effect on the security of Web Services. Web Services are indeed a very promising technology, and their use will continue to increase. We need, however, to be aware of the potential security problems that may occur. We have history as reference but undoubtedly there will be new problems. Currently, the Internet is not a safe place. On the positive side, we already have some promising security products and the basic frameworks for Web Services have sound security architecture. Further, cryptographic measures have solved some of the important security problems, such as authentication, message confidentiality, signatures, and non-repudiation, and all their power can be applied to Web Services as well. This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com Or purchase the extended PDF version of this article from:
Adobe Acrobat format (PDF) - 64K |