Tuning WebSphere Security

IBM WebSphere Application Server v7.0 Security

Secure your IBM WebSphere applications with Java EE and JAAS security standards using this book and eBook

Tuning general security

There are several general security aspects of a WebSphere environment that can be tweaked to either loosening or tightening the security level. This tweaking will have an inversely proportional effect on performance of the WebSphere system. This section briefly describes some of them.

Tightening security using the administrative connector

The administrative connectors are used for communication of various WAS ND7 components such as the deployment manager, node agents, application servers, and the wsadmin interface. On the one hand, by default the connector for communication between WAS ND7 components located in different physical hosts (remote connector) uses the SOAP protocol. On the other hand, the connector for communication between WAS ND7 components located on the same physical host (local connector) by default uses the IPC protocol.

The recommendation for the remote connector is to use the RMI connector. The reason for doing this is because the RMI API uses stateful connections, whereas the SOAP protocol uses stateless communication.

This parameter can be changed on the application servers Administration services page. In order to get to an Administration services page, one needs to follow a breadcrumb similar to: Servers | Server Types | Application servers | AppServer_ Name | Administration services. The resulting page should be similar to the one shown in the following screenshot:

It is always a good idea to perform a benchmark to ensure that performance is not being significantly affected.

Disabling security attribute propagation

Security Attribute Propagation (SAP) is the capability of WAS ND7 to carry principal (the caller) static and dynamic security related information from one server to another in the infrastructure according to your configuration. Static security information may include data normally derived from the user registry. On the other hand, dynamic security information may include information about the principal context such as the identity, IP, and so on.

If enterprise applications are not using this type of propagation, it is recommended to disable SAP in order to avoid its overhead. In SAP, security attributes would need to be serialized using Java serialization to carry out the propagation. Therefore, by disabling this feature, the serialization portion of the process is eliminated.

Disabling SAP is accomplished by adding and setting to false the property com.ibm. CSI.disablePropagationCallerList. The location where this property must be defined is at the global security level. Therefore, follow the breadcrumb Security | Global security | Custom properties. On that page you need to click on the New button and you will be presented with a page similar to the one shown in the following screenshot:

For additional information on Security Attributes Propagation, refer to the WAS ND7 Information Center link:
http://publib.boulder.ibm.com/infocenter/wasinfo/ v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/csec_ secattributeprop.html

Using unrestricted Java Cryptographic Extensions

The JCE have been part of the Java SDK since version 1.4.x. JCE, very succinctly, is the Java technology that offers a scheme and realization for encryption, key generation, and key agreement. In addition, the JCE policy files are the portion of the JCE which determines the strength of the encryption to be supported. Furthermore, due to several country laws, the JCE policy files that are included with the WAS ND7 SDK only enables to perform strong and limited cryptography in a way that can be shipped to any country in the world. For instance, the local policy file limits encryption of various methods to the values shown in the following screenshot:

IBM states that there is a possibility that the restricted policy files may affect performance. Therefore, it is strongly advised to use unrestricted encryption JCE policy files.

Warning: Before you replace the JCE policy libraries with their unrestricted version, it is imperative that you check your local laws regarding encryption.

Should you determine that it is permissible to use unrestricted encryption, the following procedure describes how to obtain and install the Unrestricted JCE policy files. In order to download the JAR files, you must be registered with IBM. Use your company’s authentication credentials when they are requested.

Obtaining the Unrestricted JCE policy files

The first stage in the procedure is to obtain from IBM the ZIP file unrestricted.zip that contains the Unrestricted JCE policy files.

1. Open the URL https://www14.software.ibm.com/webapp/iwm/web/reg/ pick.do?source=jcesdk〈=en_US.
   Using a browser open the Unrestricted JCE files page at https:// www14.software.ibm.com/webapp/iwm/web/reg/pick. do?source=jcesdk〈=en_US.
2. Select the libraries for version 1.4.2+.
   From the choices presented, select Unrestricted JCE Policy files for SDK for all newer versions. Version 1.4.2+.
3. Click on the Continue button.
4. Log on with your company’s credentials.
   Provide or update information as needed. Check the I agree check box. Click on the I confirm button.
5. Download the unrestricted.zip file.
6. Click on the Download now link.

Installing the Unrestricted JCE policy files

Once the policy files have been downloaded, you can proceed to install them.

1. Log on to the host where WAS ND7 is installed.
   Do this procedure for each WAS ND node (Deployment Manager host and node hosts), that is, every host in which you have installed the WAS ND7 binaries for your environment.
2. Stop all profiles associated with the binary installation.
3. Extract the JAR files.
   Create a temporary directory and in it un-archive the content of unrestricted. zip. The content is two JAR files: local_policy.jar and US_export_policy. jar
4. Change the working directory to security Java directory.
   Change the working directory to <WAS_BIN_ROOT>/java/jre/lib/security
5. Backup existing policy files.
   Make a copy of the files: local_policy.jar and US_export_policy.jar located in the security directory.
6. Install the Unrestricted JCE policy files.
   Copy the policy files obtained in the previous subsection into the security directory.
7. Restart the WAS ND7 environment.

Tuning CSIv2 connectivity

In WAS ND7, the Common Secure Interoperability Version 2 (CSIv2) is the authentication protocol used by EJBs. CSIv2 is the security protocol that undertakes the stipulations of CORBA security for interoperability authentication, delegation, and entitlements. Therefore, if your environment is using EJBs, the following tasks can improve performance without compromising security.

Using Active Authentication Protocol: Set it only to CSI

When an enterprise WebSphere environment is made up of WebSphere Application nodes of multiple versions, there may be a need for setting the CSIv2 authentication protocol to both, CSI and SAS (Security Authentication Service). However, in WAS ND7, the SAS has been deprecated for communicating with WAS versions 5 and newer. Therefore, it is highly recommended to set the property com.ibm.CSI. protocol to the value csiv2. When the protocol is set to CSI, WebSphere ND7 eliminates, on both server and client, a call to an interceptor for each request that a client makes.

In order to configure the protocol to CSI, the file <Profile_Root_Directory>/ properties/sas.client.props must be edited by adding the line shown below:

com.ibm.CSI.protocol=csiv2

Other possible values for this property are:

• ibm: Should be used if the clients connecting to the WAS ND7 environment are hosted in a WebSphere Application Server version 4 or earlier setup
• both: Should be used if the clients that communicate with the WAS ND7 environment are hosted in WebSphere Application Server installations versions 4 or earlier and versions 5 or newer

In order to make the change effective, the complete WAS ND7 cell needs to be restarted.

Enforcing client certificates using SSL

When a WebSphere client sends secure requests to an enterprise application hosted in a WAS ND7 setup, the requestor can be authenticated either using a user ID and password combination or an SSL certificate. Since the channel is already secure, employing ID and password to validate the communication adds overhead to both client and server. Therefore, it is recommended to select the use of client SSL certificates to perform the authentication of client requests.

The configuration to enforce the use of certificates for authentication can be done at the global security level or at the security domain level. The recommendation is to do it at the global security level and use this setting in all security domains.

The procedure to set the use of certificates over user IDs and passwords at the global security level is as follows:

1. Log on to the ISC (Deployment Manager).
2. Follow the breadcrumb Security | Global security | (Authentication | RMI/IIOP security) CSIv2 inbound communications.
   Refer to the next screenshot to identify the link to the CSIv2 inbound communications.

• Enforce the use of client SSL certificates.
  Set the following parameters as shown in the following screenshot:
  • Client certificate authentication (required)
  • Transport (SSL-required)
  • Message layer authentication (never)

    

    Note, however, that if client fails when the message layer authentication is set to never, it may need to be modified to the supported value.

• Ensure not to override setting in security domains.
  Finally, for each security domain that is defined in your WAS ND7 environment it is recommended to set the RMI/IIOP security using the global security settings, as shown in the following screenshot:

  

  However, if additional customization of the security domain RMI/IIOP is needed, ensure to set the values for CISv2 Transport Layer and CISv2 Message Layer as those shown in step three.

• Save the changes of configuration. Log off.