Tuning Web Services Security for Version 9.0 applications

The Java™ Cryptography Extension (JCE) is integrated into the software development kit (SDK) Version 1.4.x and later. This is no longer an optional package. However, the default JCE jurisdiction policy file shipped with the SDK enables you to use cryptography to enforce this default policy. In addition, you can modify the web services security configuration options to achieve the best performance for web services security protected applications.

About this task

Using the unrestricted JCE policy files

Due to export and import regulations, the default JCE jurisdiction policy file shipped with the SDK enables you to use strong, but limited, cryptography only. To enforce this default policy, WebSphere® Application Server uses a JCE jurisdiction policy file that might introduce a performance impact. The default JCE jurisdiction policy might have a performance impact on the cryptographic functions that are supported by Web Services Security. If you have web services applications that use transport level security for XML encryption or digital signatures, you might encounter performance degradation over previous releases of WebSphere Application Server. However, IBM® and Oracle Corporation provide versions of these jurisdiction policy files that do not have restrictions on cryptographic strengths. If you are permitted by your governmental import and export regulations, download one of these jurisdiction policy files. After downloading one of these files, the performance of JCE and Web Services Security might improve.

Avoid trouble: Fix packs that include updates to the Software Development Kit (SDK) might overwrite unrestricted policy files and the cacerts file. Back up unrestricted policy files and the cacerts file before you apply a fix pack and reapply these files after the fix pack is applied. These files are located in the {was_install_directory}\java\jre\lib\security directory.
Important: Your country of origin might have restrictions on the import, possession, use, or re-export to another country, of encryption software. Before downloading or using the unrestricted policy files, you must check the laws of your country, its regulations, and its policies concerning the import, possession, use, and re-export of encryption software, to determine if it is permitted.
For WebSphere Application Server platforms using IBM Developer Kit, Java Technology Edition, Version 6, you can obtain unlimited jurisdiction policy files by completing the following steps:
  1. Go to the following website: http://www.ibm.com/developerworks/java/jdk/security/index.html
  2. Click Java SE 6
  3. Scroll down and click IBM SDK Policy files.

    The Unrestricted JCE Policy files for the SDK website is displayed.

  4. Click Sign in and provide your IBM intranet ID and password or register with IBM to download the files.
  5. Select the appropriate Unrestricted JCE Policy files and then click Continue.
  6. View the license agreement and then click I Agree.
  7. Click Download Now.

[IBM i]To configure the unrestricted jurisdiction policy files for IBM i and the IBM Software Development Kit, complete the following steps:

[IBM i]

Procedure

  1. Make backup copies of these files: 
    /QIBM/ProdData/Java400/jdk6/lib/security/local_policy.jar
/QIBM/ProdData/Java400/jdk6/lib/security/US_export_policy.jar
  2. Download the unrestricted policy files from http://www.ibm.com/developerworks/java/jdk/security/index.html to the /QIBM/ProdData/Java400/jdk6/lib/security directory.
  3. Go to the following website: http://www.ibm.com/developerworks/java/jdk/security/index.html
    1. Click Java SE 6
    2. Scroll down and click IBM SDK Policy files.
      The Unrestricted JCE Policy files for the SDK web site is displayed.
    3. Click Sign in and provide your IBM intranet ID and password.
    4. Select the appropriate Unrestricted JCE Policy files and then click Continue.
    5. View the license agreement and then click I Agree.
    6. Click Download Now.
  4. Use the DSPAUT command to ensure that *PUBLIC is granted *RX data authority but that object authority is not provided to either of the local_policy.jar and US_export_policy.jar files, which are located in the /QIBM/ProdData/Java400/jdk6/lib/security directory.
    For example:
    DSPAUT OBJ('/qibm/proddata/java400/jdk6/lib/security/local_policy.jar')
  5. Use the CHGAUT command to change authorization, if needed.
    For example:
    CHGAUT OBJ('/qibm/proddata/java400/jdk6/lib/security/local_policy.jar') 
USER(*PUBLIC) DTAAUT(*RX) OBJAUT(*NONE)
[AIX Solaris HP-UX Linux Windows]

Results

After following these steps, two Java Archive (JAR) files are placed in the JVM jre/lib/security/ directory.

Using configuration options to tune WebSphere Application Server

When using WS-Security for message-level protection of SOAP message in WebSphere Application Server, the choice of configuration options can affect the performance of the application. The following guidelines will help you achieve the best performance for your WS-Security protected applications.
  1. Use WS-SecureConversation when appropriate for JAX-WS applications. The use of symmetric keys with a Secure Conversation typically performs better than asymmetric keys used with X.509.
    Note: The use of WS-SecureConversation is supported for JAX-WS applications only, not JAX-RPC applications.
  2. Use the standard token types provided by WebSphere Application Server. Use of custom tokens is supported, but higher performance is achieved with the use of the provided token types.
  3. For signatures, use only the exclusive canonicalization transform algorithm. See the W3 Recommendation web page (http://www.w3.org/2001/10/xml-exc-c14n#) for more information.
  4. Whenever possible, avoid the use of the XPath expression to select which SOAP message parts to protect. The WS-Security policies shipped with WebSphere Application Server for JAX-WS applications use XPath expressions to specify the protection of some elements in the security header, such as Timestamp, SignatureConfirmation, and UsernameToken. The use of these XPath expressions is optimized, but other uses are not.
  5. Although there are WebSphere Application Server extensions to WS-Security that can be used to insert nonce and timestamp elements into SOAP message parts before signing or encrypting the message parts, you should avoid the use of these extensions for improved performance.
  6. There is an option to send the base-64 encoded CipherValue of WS-Security encrypted elements as MTOM attachments. For small encrypted elements, the best performance is achieved by avoiding this option. For larger encrypted elements, the best performance is achieved by using this option.
  7. When signing and encrypting elements in the SOAP message, specify the order as sign first, then encrypt.
  8. When adding a timestamp element to a message, the timestamp should be added to the security header before the signature element. This is accomplished by using the Strict or LaxTimestampFirst security header layout option in the WS-Security policy configuration.
  9. For JAX-WS applications, use the policy-based configuration rather than WSS API-based configuration.

What to do next

In IBM WebSphere Application Server Version 6.1 and later, Web Services Security supports the use of cryptographic hardware devices. There are two ways in which to use hardware cryptographic devices with Web Services Security.