|
Wednesday July 24 2002 WS-Security Security for Web Services Web Services security has been the most talked about thing in the Web Services arena for quite some time now. If there's one thing that has slowed the widespread acceptance and implementation of Web Services, it's their lack of security standards. There also seems to be a cautious implementation schedule for many companies that are thinking about moving to the .NET platform. Partly because of security concerns I would imagine, and partly to give the technology time to grab hold. Nevertheless, security is still a major concern that holds back most of the Web Service implementations today. In April 2002, IBM, Microsoft, and VeriSign published a new Web Services security specification, WS-Security. The specification aims to help enterprises build secure Web Services, and applications based on them that are broadly interoperable. Eventually, this specification would be submitted for consideration as a standard, and looking at the amount of commitment that IBM, Microsoft, and VeriSign have invested in it, it should soon go that way. This specification proposes a standard set of SOAP extensions that can be used when building secure Web Services to implement integrity and confidentiality. WS-Security is the foundation for the Web Services blueprint that these companies have in mind. It also is the harbinger of an additional set of planned Web Services security capabilities outlined by IBM and Microsoft to deal with the increasing need for consistent support of more secure Web Services. Microsoft and IBM have produced a road map outlining the additional Web Services security specifications, which is available at http://www-106.ibm.com/developerworks/security/library/ws-secmap/. This road map is based on a radical approach to security and defines additional, related Web Services security capabilities within the framework established by the WS-Security specification. It follows an upward spiral in a continuum of evolution. What this means is that enterprises can incorporate the new specifications, as needed, into the different levels of their Web Services applications. The other proposed specifications include WS-Policy, WS-Trust, WS-Privacy, WS-Secure Conversation, WS-Federation, and WS-Authorization. We cover these in the Concepts section below. Concepts WS-Security supports, integrates, and unifies several popular security models, mechanisms, and technologies. We will cover these in the following section. This allows a wide array of existing systems to interoperate in a platform- and language-neutral manner in the context of present day Web Services. WS-Security defines a standard set of Simple Object Access Protocol (SOAP) extensions. These message headers can be used to implement integrity and confidentiality in Web Services applications. This specification also provides standard mechanisms for Web Services applications to exchange secure, signed messages. As we saw earlier, this will provide an important foundation layer for developers to build more secure and broadly interoperable Web Services. Another important factor of WS-Security is that it is a solid, open-standards-based security model and hence will develop rapidly, we hope. Coming to the specifications that are a part of the road map defined by Microsoft and IBM, we will see each one of them in brief:
WS-Security describes enhancements to SOAP messaging to provide quality of protection through the following features:
These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. Principles WS-Security provides for a generic mechanism to associate security tokens with messages. No specific type of security token is required by WS-Security. In this context, a security token is a representation of security-related information. This could manifest itself in different forms such as an X.509 certificate, a Kerberos ticket/authenticator, a SIM card based mobile device security token, or even a username/password combination. Whatever the actual implementation, the developers are insulated from these details while dealing with WS-Security. Since it is designed to be extensible, WS-Security supports multiple security token formats. For example, a client might provide proof of identity and proof that they have a particular business certification. Additionally, WS-Security describes how to encode binary security tokens. The specification describes how to encode X.509 certificates and Kerberos tickets as well. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message. One advantage of SOAP-based specifications is that since they use the SOAP extensibility model, they can be composed with each other to provide a rich messaging environment. WS-Security does not ensure security inherently, nor does it provide a complete security solution. WS-Security is a building block that is used in conjunction with other Web Services and application-specific protocols to accommodate a wide variety of security models and encryption technologies. Implementing WS-Security does not mean that an application cannot be attacked or that the security cannot be compromised. It only is a step ahead in making Web Services more secure, and as of now it is the best foot that enterprises can put forward to secure their applications. WS-Security is flexible and is designed to be used as the basis for the construction of a wide variety of security models including PKI, Kerberos, and SSL. More importantly, WS-Security provides support for multiple mapping with other existing technologies. This includes but is not limited to support for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption technologies. This specification provides three main mechanisms: security token propagation, message integrity, and message confidentiality. It must be reiterated here that these mechanisms by themselves do not provide a complete security solution. Instead, WS-Security is a merely the foundation on which secure applications can be based. These mechanisms can be used independently (to pass a security token) or in a tightly integrated manner (signing and encrypting a message and providing a security token hierarchy associated with the keys used for signing and encryption). Goals WS-Security aims at enabling applications to construct secure SOAP message exchanges. This specification provides a flexible set of mechanisms that can be used to construct a range of security protocols. As such WS-Security does not describe explicit fixed security protocols. As with every security protocol, significant efforts must be applied to ensure that security protocols constructed using WS-Security are not vulnerable to a wide range of attacks. Let us see how WS-Security addresses these targets that it has set out for itself. Quality of Protection When we talk about security in Web Services, there are three types of potential threats that need to be considered and addressed:
A message security model is defined to understand these threats. Message Security Model The WS-Security specification specifies an abstract message security model in terms of security tokens combined with digital signatures as proof of possession of the security token referred to as a key. Security tokens assert claims, and signatures provide a mechanism for authenticating the sender's knowledge of the key. This signature can also be used to bind with the claims in the security token. This assumes that the token is trusted. It may be interesting to note that we do not specify a particular method for authentication. The specification only indicates that security tokens may be bound to messages. This is where the power and extensibility of WS-Security lies. A claim can be either endorsed or unendorsed by a trusted authority. A set of endorsed claims is usually represented as a signed security token that is digitally signed or encrypted by the authority. An X.509 certificate, claiming the binding between one's identity and public key, is an example of a signed security token. An unendorsed claim, on the other hand, can be trusted if there is a trust relationship between the sender and the receiver. One special type of unendorsed claim is Proof-of-Possession. Such a claim proves that the sender has a particular piece of knowledge that is verifiable by appropriate actors. For example, a username/password combination is a security token with this type of claim. A Proof-of-Possession claim is sometimes combined with other security.tokens to prove the claims of the sender. Message Protection The primary security concerns in Web Services are confidentiality and integrity. WS-Security provides a means to protect messages by encrypting and/or digitally signing a body, a header, an attachment, or any combination of thees. Message integrity is provided by using XML Signature in conjunction with security tokens to ensure that messages are transmitted without modifications. The integrity mechanisms are designed to support multiple signatures, potentially by multiple actors, and to be extensible to support additional signature formats. Message confidentiality leverages XML Encryption in conjunction with security tokens to keep portions of a SOAP message confidential. The encryption mechanisms are designed to support additional encryption processes and operations by multiple actors. Missing or Inappropriate Claims The message receiver should reject a message with an invalid signature, or missing or inappropriate claims, as if it is an unauthorized (or malformed) message, as would be expected in a secure environment. WS-Security provides a flexible way for the message sender to claim the security properties by associating zero or more security tokens with the message. Requirements The Web Services security language must support a wide variety of security models. The following list identifies the key driving requirements for this specification:
The WS-Security is based on the existing standards and specifications. Hence it does not address how security contexts and/or authentication mechanisms that require multiple exchanges can be established. It also does not deal with Key exchanges, derived keys, or the methodologies for be establishing and determining trust. The WS-Security specification builds on XML Signature and therefore has the same algorithm requirements as those specified in the XML Signature specification. In addition to this, WS-Security specification recommends the following additional algorithms:
The Exclusive XML Canonicalization algorithm addresses the pitfalls of general canonicalization that can occur from leaky namespaces conflicting with pre-existing signatures. Decryption Transformation for XML Signature is used to sign messages before encryption. Advantages of WS Security WS-Security was released in April 2002. It came into being to address the security concerns that have been plaguing Web Services for quite some time now. As of now, it is the most comprehensive and elaborate attempt to add security to Web Services. WS-Security insulates development teams from the low level specific details of the technologies involved in implementing security. It also facilitates a rapid change of implementation between technologies without disturbing the existing interfaces between systems. WS-Security describes a model for implementing security in Web Services in conjunction with the other technologies and specifications identified in the road map. It also provides a framework for extensibility, which makes it faster to reuse existing solutions. Applications Let us consider of how WS-Security may be used in a real life scenario. Let's assume that a company wants to provide regular updates to customers at a charge, using a third-party billing company. In this scenario, the potential challenges would be to authenticate the user uniformly and consistently. For example, in Europe the postal service is offering to create X.509 certificates for customers. This involves checking and validating the user's identification and issuing a certificate similar to a digital certificate on a hard disk. Users use that disk and their password when they sign onto a system that is enabled for it. This is similar to an ATM card or a credit card. Software vendors could use this mechanism for subscribers. WS-Security being an open standard, it has the advantage that the third-party providers can plug into this system. Isn't it easier for them than it would have been if the two business partners had to create such a verification system from scratch? Summary The prime focus of the WS-Security specification is to describe a single-message security language that provides for message security that may assume an established session, security context and/or policy agreement. WS-Security also defines standards for:
WS-Security is flexible and is designed to be used as the basis for the construction of a wide variety of security models including PKI, Kerberos, and SSL. Specifically WS-Security supports for multiple security tokens, trust domains, signature formats, and encryption technologies. WS-Security is a building block that can be used in conjunction with other Web Services extensions and higher-level application-specific protocols to accommodate a wide variety of security models and encryption technologies. Given the investment and commitment of IBM, Microsoft, and VeriSign in this specification, and the desperate industry need for security in Web Services, this specification is all set to bring about a breath of freshn air to the trough of Web Service disillusionment. Now all we need is wide adoption of this standard. This article is based on the specification available at: |