Over the past five years, the promise of enterprise information sharing has made great strides with the evolution of Web Services and the promise of Service Oriented Architectures (SOA). An architectural shift that moves us away from point-to-point client/server systems,

SOA provides new challenges related to propagating trust between services at multiple points in an n-tiered architecture. Many government and industry applications have mission-critical security requirements that make achieving strong enterprise security goals mandatory, and over the past few years, there have been great strides in creating mechanisms for achieving these goals in a SOA. The security solutions that exist, however, directly impact performance. The cryptography used to achieve enterprise security goals will also slow down your Web Service consumers and producers, so any good SOA architect will have to be smart and look at all the options. Focusing on performance, this article presents an approach of using SSL to complement some of the existing Web Services security mechanisms - in situations where it makes sense.

Standards such as WS-Security, the Security Assertion Markup Language (SAML), XML Signature, and XML Encryption are the "glue" for achieving classical security goals in Web Services. For example, using WS-Security SOAP messaging using XML Signature for signing the contents of the entire message would provide non-repudiation (and message integrity) for all messages. If the lifecycle of a SOAP message involves Web Service chaining, then certain cryptographic operations may have to take place between each Web Service consumer and every Web Service provider in the lifecycle to do integrity checks and signature validations. When client applications repeatedly send several hundred Web Service messages along this same chain, SOA architects should re-think this model. After analyzing your security requirements, it may make sense to re-factor your Web Services security solution in these situations. If there are Web Services consumers that constantly have interactions with the same Web Service providers, there may better-performing ways of achieving your security goals than having signatures and validations happening between them every time.

Figure 1 shows a simple example of a Web Service chaining scenario. A portal sends search requests to an enterprise search Web Service that delegates search requests to search providers that do data source searches and return the results. Looking at this scenario, we can effectively demonstrate a dilemma that we face when all messages are digitally signed with WS-Security SOAP messaging, and where much of the same chain is used repeatedly.

In our example, a Web portal sends searches to one enterprise search service, which propagates searches to multiple search provider Web Services in the enterprise. At every point of the message lifecycle, there will be four cryptographic operations - a digital signature when the request message is created, a validation on the receipt of the request message, a signature when the returned message is created, and a validation on the returned message.

Each one of these cryptographic operations uses asymmetric (public key) cryptography, which is computationally expensive. All in all, in a scenario with just four data sources in this scenario, 20 cryptographic operations have to take place for one search, which will have a direct negative impact on performance. For 1,000 searches, 20,000 cryptographic operations have to take place. In such scenarios where there's a promise of long-standing relationships between Web Service consumers and Web Service providers in your Web Service lifecycle, the concept of a "Web Service session" should be factored in.

SSL (in this article I'll use the term SSL because the term has been commonly used to mean its replacement, TLS) has been in use for over a decade, and because it's typically used for client/server Internet solutions, it's gotten a bad rap when it comes to Web Services. While SSL doesn't lend itself to providing an overall solution for the distributed nature of Web Services, it can be used as a piece of the puzzle, complementing Web Services security standards to achieve security objectives between two points in a Web Service solution. Long-lived mutually authenticated SSL connections between two endpoints in the Web Service lifecycle can be used to create "Web Service user sessions" in a multi-tiered model where the same Web Service consumers and Web Services constantly communicate. If it's known that a relationship between two nodes in the solution is long-lived, it's a fair estimate that having a long-lived secure connection between those two nodes would eliminate the overhead of repetitive cryptography, providing better performance in repeated messaging.

Figure 2 provides an example of setting up such an SSL session between two points. If the portal is used mainly for enterprise searches via the enterprise search Web Service, a mutually authenticated SSL session can and should be initiated between the Web portal and the enterprise search service. It's well documented that establishing a SSL connection is where the performance penalty lies, since asymmetric (public key) operations are used and are computationally expensive. Once a long-lived session is set up between the two parties, however, symmetric (or "secret key") cryptography is used to renew the session and is much faster. A mutually-authenticated session between the two points in the solution would provide non-repudiation of the identities of the Web Service consumer and provider, and it would provide confidentiality and message integrity between the two points. Plain SOAP requests and responses can be used between the two points. Finally, it should be noted that after the SSL session is set up between the two points in the solution there will be four fewer public key operations for every search. Think of the impact of having 40,000 less public key operations for every 10,000 searches. The longer the SSL session is used between the portal and the enterprise search service in this example, the better the performance average will be over time.

Figure 3 shows a good performance comparison chart, showing simple SOAP requests between a Web Service consumer and a Web Service over time. Obviously performance will vary depending on the WS-Security toolkits you're using and depending on the ciphers used in SSL, but the purpose of this chart is to get an important point across. Initially the SSL setup makes SOAP-over-HTTPS much slower than signed WS-Security SOAP messaging. After a certain amount of time, the performance of SOAP messaging in a long-lived SSL connection is significantly better than the repeated cryptography used in signed WS-Security messaging. The response time of the request/response of signed SOAP messaging is constant; the SSL connection has a performance hit at the beginning, but the subsequent SOAP messages are faster. Over time SSL buys you the performance benefit of being much faster, achieving many of the same goals - message integrity and non-repudiation of the identity of the components involved - but with the added benefit of confidentiality, since encryption is used. (Imagine how much better performance would be over time if we compared signed messages that contained XML Encrypted elements between two points!)

This solution is not the answer for every use case. Because of the dynamic nature of SOA, you may not always be able to predict the paths of Web Service chaining and orchestration solutions. However, when you have more information about the routing and chaining of Web Service messages, using SOAP over long-lived mutually authenticated SSL sessions between constantly communicating points may satisfy your security requirements and improve performance.

Propagating Identity
Propagating identity adds an additional layer of complexity in a Web Service chaining solution. Using standards such as WS-Security SAML Token Profile, a messaging solution can be developed that propagates an end user's identity and authorization credentials in SAML assertions through every point of a SOAP request.

Commonly there are typically two trust models used in SOAs for propagating identity:

• A trusted infrastructure model, where a single SAML-issuing authority exists in the enterprise. In this model, the issuing authority validates the credentials of the user that may generate SAML assertions based on the user's identity and authorization credentials.
• A trusted client model, working in a "sender vouches" scenario. In this model, the authenticating client application is trusted to assert the identity of a user that it authenticates and the client is trusted to issue SAML assertions.

A typical example (ignoring some subtleties for simplicity's sake) is shown in Figure 5. For every SOAP request in this model, XML Signature is used by Web Service consumers and providers to digitally sign the entire SOAP message (including the already-signed SAML Assertion), cryptographically tying all elements of the SOAP message together and providing non-repudiation of the message contents by the sender of the message. In such a messaging syntax, the combination of the signature of the SAML assertion by the asserting party and the signature of the entire message by the sending party provide assurance of not only who the sender is, but the identity of the user involved - at every point in the Web Service chain lifecycle.

Identical to our initial example, there will be performance issues when propagating these identity credentials with WS-Security SOAP messaging. SSL can also be used here for performance benefits in situations where there will be long-lived relationships, but any solution would be more complex because the authenticating client (a portal in this example) may work on behalf of thousands of users. While a mutually authenticated SSL connection is a contract between two entities (the portal and the Web Service in our original example), we also have to have the explicit trust of the user who is using the portal. To do that, you can create the concept of a Web Service "user session" standing on the shoulders of SSL:

1)  Create a long-lived mutually authenticated SSL connection between the Web Service consumer and Web Service

2)  Send the signed SAML assertion from the Web Service consumer to the Web Service in the WS-Security header of a SOAP message (not signing the entire message)

3)  At this point, the response of the SOAP message may include in its header a Globally Unique Identifier (GUID) that can be used in subsequent SOAP messages over HTTPS to refer to the original SAML assertion that was validated.

4)  On subsequent messages over the SSL connection, send basic SOAP messages, with the GUID in the SOAP header, specifically referencing the "user session." If the SAML assertion's conditions (such as time constraints) ever expire, it's up to the Web Service implementation to throw a SOAP Fault, explaining that a new signed SAML assertion for that user is expected for continued activities on behalf of that user.