SSL page access through a TCP junction with “-c all” option

In this test case the client has an SSL connection to the WebSEAL server, which requires authentication and encryption, and accesses the Web page on the back end WebSphere® Application server via an unencrypted connection (TCP junction).

Using a page size of 5.8 KB

This test involves SSL access that compares software encryption against hardware encryption. Encryption occurs between the client and WebSEAL. The AES-128 encryption algorithm was used for encryption operations between the client and WebSEAL. In this test, only one handshake occurred. The -c option allows you to insert Tivoli® Access Manager-specific client identity and group membership information into the HTTP headers of requests destined for junctioned third-party servers. The HTTP header information enables applications on junctioned third-party servers to perform user-specific actions (such as SSO) based on the client's Tivoli Access Manager identity.

HTTP header information must be transformed by the back end server to environment variable format for use by a service on the back end server. Header information is transformed into a CGI environment variable format by replacing all dashes (-) with under bars (_) and adding "HTTP" to the beginning of the string. The value of the HTTP header becomes the value of the new environment variable.

The Tivoli Access Manager-specific HTTP header entries are available to CGI programs as the environment variables HTTP_IV_USER, HTTP_IV_GROUPS and HTTP_IV_CREDS. For other application framework products, see the product's documentation for instructions on extracting headers from HTTP requests.

The -c all option inserts all three types of identity information into the HTTP header. The addition of the -c option places additional processing overhead on WebSEAL.

Encryption algorithm: AES-128

Figure 1. 5.8 KB SSL page access through a TCP junction with -c all

eseal10

Figure 2 is a comparison between 5.8KB SSL page access through a TCP junction with the -c option and 5.8KB SSL page access through a TCP junction without the -c option.

Figure 2. 5.8 KB SSL page access through a TCP junction versus 5.8 KB SSL page access through a TCP with -c all

eseal11

Observations

The case with a single CPU shows only the improvement of using hardware cryptography. The additional workload had nearly no impact on the scenarios with one CPU as without -c all option because these runs are CPU constrained. The more interesting case is when two CPUs are used. In this case, the throughput degraded by 17% using cryptographic hardware even though there is some CPU capacity available. This indicated that the access to the Tivoli Access Manager introduced some latencies.

Conclusions

In the one CPU case, the -c all option does not have an impact on the throughput because WebSEAL is CPU constrained. In the two CPU case, WebSEAL is not CPU constrained and there is a small degradation in throughput as would be expected due to the additional processing required in WebSEAL to support this feature.