SSL acceleration is a method of offloading the processor-intensive public key encryption algorithms involved in SSL transactions to a hardware terminator, or accelerator. This may be a separate card that plugs into a PCI slot in a computer that contains one or more co-processors able to handle the SSL processing, or a dedicated (and expensive) hardware device.
The most computationally expensive part of an SSL session is the stage where the SSL server (the Identity or Proxy server in the case of this document) software is required to decrypt the SSL session key (an asymmetric key) that has been sent to it from the SSL client (usually a web browser). This is known as the SSL handshake. Typically a hardware SSL terminator will offload processing of the SSL handshake while leaving the server software to process the less intense symmetric cryptography of the actual SSL data exchange. As well as handling the handshake, the terminator acts as a proxy handling all SSL operations and leaving the server seeing only unencrypted connections.
The benefits in terms of performance of the Access Manager server are very high, often resulting in faster performance, and higher throughput.
Although this document focuses on the Citrix Netscaler SSL terminator rewriter configuration, the Access Manager configuration settings will be the same for any SSL terminator. The SSL terminator administration guide is available at http://support.citrix.com/servlet/KbServlet/download/23213-102-645234/NS-TrafficMgmt-Guide.pdf. The actual setup of the SSL terminator was based on the following example - http://www.citrix.com/site/resources/dynamic/accessAnswers/SharePoint_Deployment_Guide.pdf.
In the following setup:
Figure 1: Network overview
Although there are GUI methods to do all of this, most of the examples in the Citrix documentation and web site tend to list the CLI solutions. For this reason, we have gone with the CLI options.
Most of the changes are for the IDP server and NOT the LAG ; the LAG, as shown in section below, is capable of rewriting the references itself.
The configuration instructions assume that the SSL Offload vservers have been created for the LAGs and the IDP servers. We have used the logical name of "Access Manager Access Gateway" for the LAG vserver, and "Access Manager IDP Server" for the IDPs. Vserver setup details are available from the links referenced in the Introduction.
To enable all the rewrite functionality needed, do the following:
<form name="IDPLogin" enctype="application/x-www-form-urlencoded" method="POST" action="<%= (String) request.getAttribute("url") %>" AUTOCOMPLETE="off">
<form name="IDPLogin" enctype="application/x-www-form-urlencoded" method="POST" action="http://idp126.lab.novell.com/nidp/idff/sso?sid=4" AUTOCOMPLETE="off">
<form name="IDPLogin" enctype="application/x-www-form-urlencoded" method="POST" action="https://idp126.lab.novell.com/nidp/idff/sso?sid=4" AUTOCOMPLETE="off">
With the Netscalar taking care of the rewrites of HTTP to HTTPS on the Identity Server, the only changes required on the Access Manager side are for the Linux Access Gateway proxy servers. There are three particular cases where the LAG must have it's scheme rewritten correctly:
HTTP/1.1 302 Moved Temporarily
Set-Cookie: JSESSIONID=AF5484F1CD4D218C5404A17A0DA86E5A; Path=/nesp; secure
Date: Tue, 18 May 2010 13:53:26 GMT
Via: 1.1 lag129.lab.novell.com (Access Gateway 3.1.1-265_eng_600589-7AA324FFCBA4D4ED)
The target parameter, embedded within the Authentication request references "http://lag129.lab.novell.com:443/formfill/phpinfo.php". This needs to be rewritten to use the https scheme e.g. "https://lag129.lab.novell.com:443/formfill/phpinfo.php"
There are two cases where the LAG sends redirects back to the browser:
The following two files exist on the LAG to handle the first two cases above (a and b), whereas the SSL terminator will handle the later case. The SSL terminator will handle any 'Location' HTTP header rewrites generated by the Web server or LAG.
# touch /tmp/.rewriteAlwaysHTTPS
If this touch file is enabled, the Linux Access Gateway rewrites all HTTP links to HTTPS before rendering the pages to the browser.
# touch /var/novell/.ForceHTTPSSchemeInESPRedirection
In this case, the original URL accessed by the browser is rewritten with the HTTPS scheme. This ensures that the traffic is sent back to the browser after the authentication contains the right protocol (SSL/TLS).
# /etc/init.d/novell-vmc restart
Any time a change is made to a touch file, the VMC services must be restarted on the LAG for the changes to register.