To ensure that we have properly configured WebLogic Server for SOAP encryption, we now run a few of simple functional tests. In the first test, we use SOAPSonar to submit a SOAP request without an X.509 certificate embedded in it. You can do this by turning off the WS X509 Token Task in SOAPSonar. As expected, we get a SOAP Fault that indicates that the endpoint, WebLogic Server, requires an X.509 token:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header /> <soapenv:Body> <soapenv:Fault> <faultcode>soapenv:Server</faultcode> <faultstring>Failed to get token for tokenType: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</faultstring> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope>
In the second functional test, we turn the WS X509 Token Task in SOAPSonar back on and send a SOAP request with an X.509 certificate
cert1024 that is registered with
DemoTrust.jks. Figure 7 shows the request message with the SOAP Body and the X.509 embedded in the SOAP Header.
When SOAPSonar makes the SOAP request with the embedded X.509, WebLogic Server parses the SOAP request, extracts the X.509 token from the SOAP header, and checks with the trust key store,
DemoTrust.jks, whether the presented X.509 is registered as a trusted X.509 certificate. Since the X.509 certificate
cert1024 is registered as a trusted certificate, WebLogic Server proceeds to apply the SOAP Body encryption policy configured in Step 4. The result of the encryption policy is shown in Figure 8.
The SOAP response in Figure 8 shows the SOAP body is encrypted with the content placed in the
EncryptedData element. The X.509 token data shows that
cert1024 certificate is used for the encryption. The content in the SOAP body response is now confidential and can be decrypted only to the original data format by anyone with a private key. Within a SOA, SOAP decryption may occur at a consumer, producer, or intermediary gateway such as AquaLogic Service Bus.
For the third and final functional test, select the
cert2048 in SOAPSonar, as show in Figure 6, to inject it into the SOAP request header. On submitting the request with
cert2048 embedded in it, you get:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header /> <soapenv:Body> <soapenv:Fault xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <faultcode>wsse:InvalidSecurityToken</faultcode> <faultstring>Security token failed to validate. weblogic.xml.crypto.wss.SecurityTokenValidateResult@314c3b[status: false][msg [ [ Version: V1 Subject: CN=cert2048, OU=development, O="software, inc.", L=waltham, ST=ma, C=us Signature Algorithm: SHA1withRSA, OID = 1.2.840.1135184.108.40.206
The response is a SOAP fault indicating the security token presented was invalid. This occurs since
cert2048 was not registered with
DemoTrust.jks as a trusted certificate. To add certificates to a Java Key Store, download keytool, a command-line utility by Sun Microsystems. Remember to restart WebLogic Server for changes to the Java Key Store to take effect.
The WebLogic Server platform provides message-level encryption and signatures by using public and private keys. Users have an option of picking key pairs depending on corporate security policies. Small key sizes are efficient but are less secure. Larger key sizes are more secure but end up chewing considerable computational resources. Figure 9 shows a normalized graph of SOAP encryption for different key sizes plotted on the x-axis. All observations are normalized to the 512-bit key size since 512 bit key is the smallest key size tested and therefore has the highest performance (and lowest security). Starting from 512 at 100%, increasing the key size for encrypting the SOAP message, one should expect performance degradation owing to higher overhead of cryptographic operations.
Figure 9. Relative key size profile for message-level encryption in WebLogic Server
Large key size operations, especially private key operation required for signatures (and decryption) are computationally expensive. Public key operations required for encryption and signature verification are not as computationally intensive as their private key counterparts. Key sizes beyond 2048 bits are rarely used in practice and unless there is a strong reason to do so, one should stick to either 1024- or 2048-bit keys for Signatures and Encryption. BEA recommends 1024 or higher key sizes.
Consider using a crypto accelerator such as nCipher Hardware when larger than 1024-bit key sizes are necessary. Instructions for configuring the nCipher JCE provider are available in Securing WebLogic Server.
SOAPSonar is a .NET-based client that interacts seamlessly with the Java-based WebLogic Server. The seamless interoperability is evident across multiple aspects of this Web services interaction:
This article shows you how to set up message-level encryption for WebLogic Server, and how WebLogic Server provides the necessary granularity to encrypt SOAP messages. Understanding key management and fundamentals of PKI is essential for setting up message-level encryption policies. Equally essential is making trust management an integral part of corporate security policies. Knowing which X.509 keys are valid and trusted is essential for establishing trust, and systems like transport-level security and message-level security are only as good as the handling and management of corporate cryptographic keys.
The .NET and Java platforms interoperate surprisingly well. SOAP messages assembled by a .NET-based client, SOAPSonar, are readily digested by the Java-based WebLogic Server 9.2. More impressive is the ability for WebLogic Server to consume SOAP messages with X.509 embedded in SOAP requests generated from a .NET-based client.
The power of interoperable and granular message-level encryption is now available to ensure that data privacy is enforced beyond transport protocols. Within a SOA, privacy-related policies can now be tested and enforced at the message level, ensuring that, regardless of the transport security, information is protected from intentional or inadvertent leaks.
Mamoon Yunus is CTO of Forum Systems and a pioneer of SOA Gateways and Firewalls. Prior to Forum, Mamoon was at webMethods where he developed XML-based technology.
Rick White is the co-founder of Fusion Multisystems and also the co-founder of Forum Systems. Previously, Rick was the co-founder of Phobos Corporation, a traffic management solutions company that was acquired by Sonicwall.