|Read more about this book|
(For more resources on IBM, see here.)
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.
- 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.
- 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+.
- Click on the Continue button.
- 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.
- Download the unrestricted.zip file.
- 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.
- 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.
- Stop all profiles associated with the binary installation.
- 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
- Change the working directory to security Java directory.
Change the working directory to <WAS_BIN_ROOT>/java/jre/lib/security
- Backup existing policy files.
Make a copy of the files: local_policy.jar and US_export_policy.jar located in the security directory.
- Install the Unrestricted JCE policy files.
Copy the policy files obtained in the previous subsection into the security directory.
- 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:
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:
- Log on to the ISC (Deployment Manager).
- 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.
|Read more about this book|
(For more resources on IBM, see here.)
Enabling stateful sessions
When using stateful sessions, the first communication between client and server must fully authenticate. If stateful sessions are not enabled, full authentication must take place for each request. Therefore, it is a best practice to enable stateful sessions, in order to eliminate the authentication overhead per request. Under this scenario, the appropriate session credentials are included in each request, which minimizes the authentication process of the requestor.
By default, stateful sessions are enabled, thus this task only calls for ensuring that they have not been modified. On the server side, this setting is available on the CISv2 inbound communications screen in the ISC. On the client side, the setting is found in the <Profile_Root_DirectoryTgt;/properties/sas.client.props file.
Configuring the server
In order to review and change if necessary the setting for the server, use this procedure.
- Log on to the ISC (Deployment Manager).
- Follow the breadcrumb Security | Global security | (Authentication | RMI/IIOP security ) CSIv2 inbound communications.
- Review the section Additional Properties.
The setting for session should match the configuration shown in the following screenshot:
- Save any changes made.
Configuring the client
The procedure for insuring that the session configuration is set to stateful on the client side is as follows:
Tuning user directories and user permissions
In the area of user registry and permissions, there are several opportunities to improve performance by making a few key modifications to the default settings. This section briefly describes some simple changes in the areas of user directories (LDAP) and user authentication.
When selecting an LDAP server as user registry, there is an opportunity to improve performance of the communication between the WAS ND7 administrative constituent and the LDAP server. In order to configure the LDAP, follow the breadcrumb Security | Global security | (User account repository | Available realm definitions ) Standalone LDAP registry to get to the LDAP configuration. The following screenshot shows the portion of the Global security page that is used to open the LDAP configuration page.
Reusing the established connection
In the normal course of interactions, WAS ND7 security components will communicate with an LDAP server on multiple occasions. For instance, when users log on to enterprise applications hosted in the WAS environment, the security mechanisms will collect the required data from the LDAP server. For this reason, it is important to reduce any overhead that may take place between WAS ND7 and the LDAP server. Selecting to reuse the connection will ensure to keep alive a connection between those entities after the connection has first been established. Selecting this option is particularly important if using the recommended SSL protocol between WAS and LDAP.
Therefore, on the Standalone LDAP registry configuration page ensure that Reuse connection is checked as shown in the following screenshot and highlighted by the maroon arrow pointing to the right.
Ignoring case during authorization
Another opportunity to improve performance of the interactions with an LDAP server is to ignore the case when performing LDAP default authentication. Furthermore, this setting may be required by the brand of LDAP server in use in your organization. For instance, one of the popular LDAP brands is the Sun One Directory server (rebranded as Oracle Directory Server) which requires this setting. It is recommended that you verify the requirements of the particular brand of LDAP server used in your environment to help you decide if this setting is supported, in which case it is recommended to do so.
So, in order to turn on ignoring case during LDAP default authentication, refer to the screenshot shown previously. The blue arrow pointing to the left highlights the desired setting, that is, Ignore case for authorization.
Tuning user authentication
In the area of user authentication to J2EE applications, there are several opportunities for tuning security parameters that will increase the performance of the user authentication process without compromising security. However, as always is the case when lessening security, care needs to be taken in analyzing a specific organization environment and its needs which are always unique. In this section, two of them, authentication cache timeout, and enabling SSO, will be presented as identified in the following screenshot. The screenshot was taken from the Global Security configuration screen. (Breadcrumb: Security | Global security.)
Increasing authentication cache timeout
In WAS ND7 environments, security information related to beans, access to resources and authentication credentials is kept in a cache. In our specific case, operations requiring authentication information first access the authentication cache in order to access the required information. Therefore, the cache helps to accelerate the continuity of such operations. Elements in the authentication cache that have not been accessed for the period indicated by the authentication cache timeout are removed from the cache. When a subsequent operation that requires the authentication information takes place, additional actions to obtain the required information are executed. These actions could involve accessing the user registry and perhaps even a database lookup. Such operations are expensive in terms of performance. Moreover, this type of tuning needs to take into consideration the following facts:
- In a non-secure environment, such as users accessing your application from the Internet, increasing the authentication cache timeout may allow a potential hacker from stealing an authentication token and give the hacker enough time to penetrate the system before the token expiration. This should not be the case if your application is accessed only within your intranet.
- A short period for the timeout will affect performance in that the system would have to request the desired information from back-end and support systems more often.
- A long period for the cache timeout may also affect performance if your application is used by a large number of simultaneous users since the memory used by the cache will increase accordingly.
The default value for the authentication cache timeout is ten minutes. You may wish to consider tuning this value in your load-testing environment by stressing your application under the peak user load and systematically increase the value of the cache timeout.
The selected value of the authentication cache timeout must be less than the value of the LTPA timeout, by default set to 120 minutes.
Infrastructure architecture tip
One thing to keep in mind is that the value for the authentication cache timeout can be modified at the global security level and overridden at the security domain level. What this means is that if your environment has a set of enterprise applications with similar security and user load requirements, they should be placed in the same custom security domain. This simplifies the configuration and maintenance of your environment.
In order to access the global security level authentication cache configuration screen, follow the breadcrumb Security | Global security | (Authentication [page section] ) Authentication cache settings. On the other hand, to access a security domain authentication cache settings screen follow the breadcrumb Security | Security domains | Custom_Security_Domain | ( Authentication Mechanism Attributes [expand] | Customize for this domain [select] | ) Authentication cache settings, as it is shown in the following screenshot.
Finally, to tune the value for the timeout, ensure that the Enable authentication cache box is checked. Followed by the desired minutes value, set in the cache timeout field. The following screenshot shows a timeout of 30 minutes.
It is not uncommon for an organization that employs WebSphere Application Server as its J2EE application server hosting environment to run a number of applications that require the same type of authentication credentials for users. In other words, in order for a user to authenticate against one of such applications, his credentials would be matched to the same user registry that other applications in the environment use. It, therefore, does not make sense on the user experience aspect of the environment to require users to log in individually to each application. On the other side, it is also expensive from the performance point of view, having to re-authenticate users every time they switch applications in the same environment (or domain).
What is needed in this type of setting is the capability to re-use the authentication credentials used in one application when attempting to access another application in the same domain. Therefore, the solution to this scenario is enabling and configuring Single Sign-On (SSO). In order to access the SSO settings page follow the breadcrumb Security Global security | ( Authentication [page section] | Web and SIP security [expand] | ) Single sign-on (SSO)|. On that page, check the Enabled checkbox and enter the name of the SSO domain under the Domain name field as shown in the following screenshot:
This article presented key elements that will help you in improving performance by lessening some aspects of security without compromising the environment. Consequently, after completing this article you would have learned about:
- Tuning general security aspects of WAS ND7 such as the administrative connector, security attribute propagation, and Java Cryptographic Extensions
- Tuning particular aspects of the active authentication protocol, improving the use of SSL, and stateful sessions
- Tuning user-related aspects such as LDAP and authentication
In the next article we will take a look at troubleshooting WebSphere security-related issues.
- FAQs on IBM Lotus Notes 8.5 [article]
- How to Set Up IBM Lotus Domino Server [article]
- Replication Alert Monitor: Monitoring Management [article]
- IBM WebSphere Application Server Security: A Threefold View [article]