+

Search Tips   |   Advanced Search

Tune Web Services Security for v9.0 applications

The Java Cryptography Extension (JCE) is integrated into the 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 us to use cryptography to enforce this default policy. In addition, we can modify the web services security configuration options to achieve the best performance for web services security protected applications.

Use the unrestricted JCE policy files

Due to export and import regulations, the default JCE jurisdiction policy file shipped with the SDK enables us 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 supported by Web Services Security. If we have web services applications that use transport level security for XML encryption or digital signatures, we might encounter performance degradation over previous releases of WAS. However, IBM and Oracle Corporation provide versions of these jurisdiction policy files that do not have restrictions on cryptographic strengths. If we 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.

Fix packs that include updates to the SDK might overwrite unrestricted policy files and the cacerts file. Back up unrestricted policy files and the cacerts file before applying 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, we must check the laws of our country, its regulations, and its policies concerning the import, possession, use, and re-export of encryption software, to determine if it is permitted.

For WAS platforms using IBM Developer Kit, Java Technology Edition, v6, we 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 the 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.

(iSeries) To configure the unrestricted jurisdiction policy files for IBM i and the IBM SDK, complete the following steps:

(iSeries)


Tasks

  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 the 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)

(Dist)

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


Use configuration options to tune WAS

When using WS-Security for message-level protection of SOAP message in WAS, the choice of configuration options can affect the performance of the application. The following guidelines will help you achieve the best performance for our 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.

    The use of WS-SecureConversation is supported for JAX-WS applications only, not JAX-RPC applications.

  2. Use the standard token types provided by WAS. 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 WAS 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 used to insert nonce and timestamp elements into SOAP message parts before signing or encrypting the message parts, we 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 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 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 WAS v6.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. See Hardware cryptographic device support for Web Services Security for more information.


Related:

  • Overview of standards and programming models for web services message-level security
  • Hardware cryptographic device support for Web Services Security