Performance Considerations for Various Security Models for Oracle Service Bus

I'm just back from California after a week of intensive OSB 11gR1 deep dive training/education. In one of the sessions we reviewed some of the performance numbers related to various security models in the release. The role of performance testing in engineering is to ensure that there are no performance regressions from the previous release as well as look for hot spots/low hanging fruit to improve the overall performance of the product.

In my role with the A-Team, I get a slightly different set of performance related questions. These are basically of the form "How fast will this be in my environment?". This is obviously a question which has no magical answer. The myriad of factors affecting the performance of a complex network such as a SOA/OSB deployment cannot be simplified into a pat answer like "20% faster". So, what is the best that we can do in giving guidance to customers in selecting a security model for their SOA and setting performance expectations?

In my experience, there are two things that many customers leave until the very end of their deployment - security and performance. I'm not sure why, but I suspect because both topics are some what tedious and complicated and are not as "critical" as delivering the business functionality of the application. The best advice that I can give is to consider these non-functional requirements early in the development process and make sure that there is plenty of time to analyze, test and refine the solution. What makes this even more complicated is that security and performance can be diametrically opposed forces in a solution. The fastest approach is to have no security as well. Security always makes things slower...think about how fast it is to walk through an open door vs going the security screening at the airport.

Specifically, when looking at web-services security one choice confronting customers is to use username and password or SAML to identify the caller. In this discussion, assume that you have all of the passwords of the end users so federation is not a requirement, but rather an option. In order to do an "apples to apples" comparison, we need to think about the performance (latency and through-put) of a number of variations. Let's look at a few approaches:

• UsernameToken (UNT) clear text password over 1-way SSL
  
• UNT digest password over HTTP
  
• SAML Server Vouches with message signature over HTTP
  
• SAML Bearer assertion over 2-way SSL
  

Just to be clear, I did not include UNT - clear text password or SAML Bearer over HTTP because there are not secure on their own, excluding network security. In the UNT case, since there is a clear-text password, the request really needs to be over SSL. In the SAML bearer case, if you use HTTP or 1-way SSL, then anyone can send a request as any user if the SAML assertion is unsigned. Even if the assertion is signed, you could take that assertion and add it to any message. If you have signed assertions over 1-way SSL, the assertion is for the user but can be take and added to any request. This last use case is on the border for me, but for the sake of argument lets leave that one out of further discussion.

In looking at each of these 4 scenarios in a little more detail, I think we need to look at what happens at the webservice consumer, webservice producer, and at the user store/identity directory.

UsernameToken (UNT) clear text password over 1-way SSL

At the web-service consumer, generating a clear-text UNT token is very straight forward. In initiating the one-way-SSL, there is a certificate and hostname verification that needs to be done, but this is also fairly inexpensive. In creating the SSL connection, the entire contents of the HTTP request are encrypted and sent. At the web-service producer, the request is decrypted and then the password is validated against the directory. This can be a somewhat expensive operation, especially if this an LDAP bind. The HTTP response is encrypted again and returned to the consumer who decrypts and processes the response.

UNT Digest over HTTP

The client generates a nonce, a timestamp and then uses those to create a SHA1 hash of the nonce, timstamp, and password. The UNT token is then added into the request and sent to the producer. The producer retrieves the username from the UNT and then retrieves the clear text password from the userstore. This doesn't mean that the password is stored in the clear, but rather decrypted, so the password is decrypted by the consumer and the SHA1 has is generated. Computing the SHA1 hash is pretty quick, and unlike encryption/decryption of SSL, not impacted by message size. The response is returned, and processed. The consumer does have some extra work to do...validating the nonce. In most cases, the nonce is checked against a database and then if valid, persisted. This is an extra read and write, compared to simply validating the password.

SAML Server Vouches with message signature over HTTP

The client needs to either generate directly or through an STS a SAML assertion. Once the assertion and a timestamp are added to the message, a digital signature of at least the timestamp and the assertion are added. This addition of the assertion and signature will make the message bigger - 100s of bytes easily. On the producer side, the signature needs to be validated as well as the SAML assertion. How the SAML assertion gets validated is important. Assuming no STS, the biggest question is do I need to validate this user in the directory? If you're using OSB's Virtual User capability, then no - otherwise, you'll be going against the directory to validate the user. The response will be signed and returned back to the web-service consumer, where the response signature and time stamp need to be validated.

SAML Bearer unsigned assertion over 2-way SSL

On the web-service consumer side, a SAML assertion is generated. Unlike the sender-vouches cnfirmation method, the entire HTTP request is encrypted using a session key established via 2-way SSL. The consumer needs to produce a certificate identifying themselves to the producer, which the producer needs to validate - this is all done as part of the SSL handshake. Depending on the producer's set-up, validating the client certificate can be simple - check CA, to moderate - check the LDAP server to validate, to complex - OCSP or CRL checking. The security vs. performance trade off of certificate validation is not unique to this scenario. It comes into play in the SAML sender-vouches scenario as well. Also like the SAML sender-vouches, id you're using virtual users, then there is no need to go to the directory. Otherwise, you'll also have to validate the user. Finally, the HTTP response is encrypted and returned to the consumer.

Summary

As you can see from the above discussion, there are many factors to consider when selecting a model that meets both security and performance requirements. Probably the first thing to figure out is if transport level (SSL) is even a possibility. Transport level security puts all of the security there, so if messages are long lived or sent to multiple parties then some message level will need to be used. SSL also can have the advantage of being able to persist SSL session keys and make repeated trips to the same host faster vs. message level which (unless you're using WS-SecureConversation) you'll have some key set-up overhead on every request. Make sure that you've got your directory infrastructure appropriately scaled - each authentication method - UNT Cleartext, UNT digest, SAML and SAML with virtual users - have different profiles in their use of the directory. Finally, like any SOA the message size and network capabilities also profoundly affect performance.

So, there is no simple answer to how security will affect performance or what are generically best practices in this regard, but hopefully this post illustrates some of the issues and considerations that go into selecting an effective and scalable solution.