Security is cited as the number one concern in building and deploying Web services today. Web services are inherently a different architecture that presents a whole new set of challenges.

You will have to reexamine many of the security aspects of your infrastructure, such as confidentiality, integrity, authentication, nonrepudiation, and cohesion. The bottom line is, you can build robust, secure systems today by leveraging your existing investment in security and taking advantage of new and evolving security standards. The business benefits of Web services are too great to hold up their adoption because of security concerns. Understanding the architectural issues will allow you to take advantage of this in your enterprise.

The Traditional Approach
Traditional applications are connection oriented, allowing many security details to be implemented at the connection level, and requiring a direct connection between the service provider and consumer. However, Web services are message oriented and lack the guarantee of a direct connection between service provider and consumer, so many traditional connection-oriented approaches to common security challenges are inappropriate or insufficient for a Web services security architecture. In addition, the introduction of Web services into an organization may be the first time that organization has ever allowed external users access to their business applications; the security practices and standards which are appropriate for inside use may be completely unacceptable when outside users are introduced. Creating an effective Web services security architecture requires a focus on achieving business requirements for your security architecture in the face of these two primary differences between Web services and traditional applications.

Confidentiality, ensuring that communications between a sender and receiver are private, is traditionally solved using connection-oriented security protocols such as HTTPS (or HTTP over SSL). However, Web services communications are message oriented, and may traverse many different "network hops" before they reach their final destination. Thus, the use of a connection-oriented protocol cannot guarantee confidentiality between a message's first producer and its final consumer.

Integrity, ensuring that communications are not altered between a sender and a receiver, is also traditionally solved at the connection level using error correction systems (such as CRCs and checksums) and connection-oriented security protocols (such as SSL). Connection-oriented security protocols that guarantee communications integrity have the same problem in ensuring integrity across all processors of a message as they do in ensuring confidentiality across those "network hops." They also suffer from an entirely different problem when used to guarantee communication integrity: message-oriented integrity should be confirmable for an extended period in the future. In other words, if a message is stored over a period of time, it should be verifiable at any point in the future that it still has not been modified. Connection-oriented approaches cannot guarantee this.

Authentication in a traditional application is usually solved using some type of user name/password combination while establishing a connection. The application can then assume that for the remainder of the connection, the authenticated user is still on the other end of that connection. Since Web services are message-based, and there is no single connection that connects a message sender with a message receiver, entirely new approaches to authentication must be employed to ensure that every message contains authentication information, and that this information can be confirmed for every message.

Nonrepudiation can be considered to be the combination of integrity (that a message was not altered in transit) and authentication (that a particular entity sent a message), and refers to the principle that a sender cannot deny that he or she sent a message, and a receiver cannot deny that he or she received it.

The Web Services Approach
Perhaps the most important requirement for Web services security architecture is one of cohesion. Developing a Web services architecture requires quite a bit of coordination between different systems, particularly when it comes to security. A typical organization may have legacy applications that are to be Web service enabled; external Web services; and enterprise applications that provide Web services interfaces to combine into a Web services architecture. Each of these might have a different set of security information, or even worse, an entirely different security architecture.

With the proliferation of security users, roles, domains, and realms that the Web services architecture will entail, it will be difficult to make enterprise-wide decisions and verify that enterprise-wide security standards are being adhered to. Therefore, a critical aspect of any Web services architecture must be a security management framework, allowing a centralized way to organize and coordinate the different security systems that will be present in the service-oriented architecture. Such a framework should enable setting and enforcing security policies across all Web services present in the organization.

The Use of Standards
Although the standards used in Web services are still evolving, some have already been proposed and adopted by the developer community (such as SOAP). Since the message-oriented nature of Web services communication and distributed nature of Web services networking pose entirely new security challenges, new standards had to be developed to ensure that Web services architectures can meet enterprise security requirements.

Because Web services share many technical similarities with Web applications, some techniques for securing Web applications can be directly utilized in Web services architectures. For example, the use of HTTP to transmit Web services messages is common, as is the use of HTTP over SSL (or HTTPS) to ensure connection-level security and the HTTP/Basic challenge-response authentication scheme for username/password connection-level authentication. Furthermore, the use of HTTP headers and cookies has also been applied to the challenge of communicating security and session information from the sender to the receiver.

However, because Web services usually operate over XML rather than HTML, an entirely new set of standards has been under development to provide XML-specific security features. The XML-Encryption standard defines how to include encrypted data (which might be other XML elements) in an XML document, and the XML-Digital Signature standard defines how to encode a digital signature (which might be signing other XML elements) in an XML document. While these have direct applications to Web services security, they are specifications for the generic problem of encoding complex data structures (such as a digital signature) in XML.

An important part of a security system is its ability to propagate security context between processing nodes. This might happen between an end-user's machine and the first Web server it communicates with (in which case cookies might be used), or it might occur between two servers in a portal environment. A new standard, the Security Assertion Markup Language (SAML), being managed by OASIS, exists to allow the propagation and validation of security assertions in Web services architecture. The use of SAML as a security assertion specification provided the basis for the Liberty Alliance specifications. These specifications describe a system that allows federated user definition across a range of organizations with single sign-on from a particular identity provider.

With so many different standards defining different components of the Web services security puzzle, an effort was required to determine how to apply them to Web services. That effort, initially led by Microsoft, IBM, and VeriSign, resulted in the WS-Security specification, now being coordinated by OASIS. WS-Security attempts to provide a comprehensive approach to message integrity, authentication, and confidentiality by specifying how to include features such as digital signatures and encryption in SOAP documents, and is expected to encompass other standards, such as SAML, for security assertions.

The Security Architecture
A Web services security architecture should decouple the semantic meaning of your services from their provision, allowing you to manage a complex security infrastructure without changing your applications. This means that your services need to be concerned only with context-sensitive authorization decisions, rather than having to understand the vast scope of Web services security standards.

By decoupling service provision from service control, you control access to your Web services using different mechanisms for different consumers. This could be achieved by using a message router or other security intermediary. For example, most enterprises will have different security requirements for services being consumed within the company than for those being consumed by business partners. This allows you to deploy the service once, and manage your security requirements based on the characteristics of the consumers of your service, rather than the characteristics of the service you're deploying.

Furthermore, this approach allows you to "future-proof" your applications. Standards surrounding Web services security are constantly evolving. By delegating security, you allow your enterprise the ability to constantly keep up with new standards, providing better levels of functionality and interoperability without changing your services or redeploying your applications.

A Web service security architecture supports message confidentiality through:
1.   Encryption of the message itself
2.   Transportation-level confidentiality schemes

When a message is encrypted to ensure message confidentiality, any portion of it can be encrypted subject to the requirements of the encoding scheme used to include the encrypted data in the message. A Web service security architecture should support the XML-Encryption standard for encoding arbitrary encrypted data in an XML document, applied either through the WS-Security standard for encapsulating encrypted data in a SOAP message, or by arbitrarily replacing portions of the SOAP envelope (including the whole envelope as necessary) with an encrypted data element.

When sending messages, a managed external service can generate WS-Security-encoded and encrypted message bodies, which ensures that the message itself is confidential. It may also replace the entire SOAP body with a single XML-Encryption-encoded element for communicating with external services that don't comply with the WS-Security standard. Either system, when combined with proper certificate management, will ensure complete confidentiality between message producer and message consumer.

Transportation-level confidentiality is appropriate for applying confidentiality between point-to-point communication and for use when an external managed service does not support message-level confidentiality. In order to provide transportation-level security and authentication, SSL may be used as an option on any message transportation system that may use it. This can be used with client-side certificate presentation and validation for additional transportation-level authentication, and will ensure that even if message-level encryption is not used at least the transmission of messages will be confidential.

A Web service security architecture supports message authentication through the use of:
1.   Digital signatures included in the message itself
2.   Message-level Proof of Possession authentication schemes
3.   Transportation-level authentication schemes
4.   Security assertions made by trusted partners

In the case of a digital signature included in the message itself, a message router may approve a digital signature encoded using the XML-Digital Signature standard and included in the message using either the W3C SOAP Security Extension Digital Signature recommendation or the WS-Security standard for message-level security. An external service may also provide a digital signature in either one of these formats. In order to avoid "replay attacks," you should only sign and accept signatures that include the complete SOAP body of the message being transmitted.

When cryptographic message-level authentication schemes aren't used, the Web service security architecture should comply with the WS-Security standard for Proof of Possession Claims for authentication. While these are generally considered less secure, as they typically rely on unencrypted username/password schemes for authentication, they are invaluable when interacting with services that don't support more secure message-level authentication schemes. Organizations may also wish to deploy a Proof of Possession system where service performance is critical.

Transportation-level authentication schemes are most appropriate when the performance of a particular service invocation is critical, or a persistent, cryptographic authentication scheme is not desirable. Using one of these schemes, a client of the service would provide security credentials using a mechanism appropriate for the transportation scheme being employed (such as a user name and password or digest when using HTTP/Basic over SSL). While these schemes don't provide all of the benefits of a message-oriented authentication system, they are usually faster and easier to support with legacy clients.

When a trust relationship exists between two organizations, they may choose to allow each other to share sign-on responsibilities and trust assertions made by each other about principal-level authentication. A Web service security architecture should accept SAML assertions in incoming messages, and evaluate the originator of the SAML assertions for an existing trust relationship. When one exists for a particular security realm, consider a valid security assertion by a trusted partner to be equivalent to a local authentication request.

Once a particular inbound message has been authenticated by a message router, a set of security assertions is created and assigned to that message (or appended to it in the case of assertion-based authentication). These also come in the form of SAML assertions, which will then be propagated through the network. If an inbound message then results in an outbound message external service, those security assertions will be translated into authentication information (including SAML assertions), which may be provided to the external service provider.

Web services by their very nature bring together different consumers and providers, each of which may have its own user, authentication, and authorization model. In order to seamlessly bring together these different security systems and user models, a Web service security architecture should provide user management at the message router level.

A Web service security architecture should allow a site administrator to define a security realm for each category of system that has a different and incompatible security model. These can be managed by an existing directory server (such as an LDAP server or Active Directory Domain). When services are enabled, they are assigned to a particular security realm, which will then be used for managing authentication and authorization decisions.

Site security administrators may also define mappings between different security principals. These mappings can then be used to allow seamless user translation between different security realms. For example, a mapping can be used to translate from the user name allowed by a message router to the user name required by an external managed service, where each may be in a different security realm. This allows organizations to provide single sign-on functionality without modifying their existing applications, which is critical when some services are external to the organization.

While many enterprises have made an investment in a public key infrastructure to complement their other security initiatives, for those that have not, the reliance on public key cryptography in a Web services architecture can be daunting.

A Web service security architecture supports key management using:
1.   An internal key management facility
2.   An organization's existing XKMS service
3.   An organization's existing Java Key Store architecture.

Because many organizations have existing public key infrastructures that provide them with an XKMS service deployed inside their organization, or a Java Key Store-based system that allows access to central registration and certificate authorities, a key management solution allows the use of either one of these types of enterprise key management integration.

However, for organizations that don't have an existing public key infrastructure, but which want to use public key-based Web service security systems (such as XML Digital Signatures or Encryption), the organization should provide a key management facility internally that provides a centralized security realm based on certificate management, distributed private key management, and association of certificates and keys with user management facilities.

Conclusion
Security is one of the most critical aspects of your Web services management infrastructure. While the security standards are still rapidly evolving, they are certainly mature enough for enterprises to build robust, secure systems today. The benefit of exposing business systems as services is compelling. Understanding the differences in implementing a message-oriented architecture will allow you to take advantage of these new business opportunities.

Author Bio
Dave Stanton is a serial entrepreneur. Prior to founding Talking Blocks, he was CTO of Xpedior and founded Sage IT Partners (sold to PSInet). Dave has held management positions at Metropolis Software and Andersen Consulting, and is an MBA and graduate of the Air Force Academy. dave.stanton@talkingblocks.com