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:
The string used within the quotes is the vserver name of the SSL Offload virtual server. Each Access Manager component set will have different names for these things.
In the CLI:
set ssl vserver “Access Manager Access Gateway” -sslRedirect ENABLED -redirectPortRewrite ENABLED
set ssl vserver “Access Manager IDP Server” -sslRedirect ENABLED -redirectPortRewrite ENABLED
Enabling SSL Redirect (-sslRedirect) causes the NetScaler system to convert any HTTP 302 redirect responses from backend servers to HTTPS redirects.
In the CLI:
add rewrite action httpRewriteAction replace_all “http.res.body(50000)” “\”https://\”” -pattern “http://”
add rewrite policy HttpToHttpsRewrite “http.res.body(50000).contains(\”http://\”)” httpRewriteAction
The (50000) value references the number of bytes to scan through to replace. This number can be tweaked for the size of the page, 50000 was from the citrix support examples.
In the CLI:
bind lb vserver “Access Manager IDP Server” -policyName HttpToHttpsRewrite -priority 100 -gotoPriorityExpression END -type RESPONSE
This will rewrite the all IDP generated references of http to the https scheme. An example of this would be the following entry in the default login (login.jsp) page which includes the HTML form with an action tag indicating where the credentials are to be posted. The page itself includes the following:
<form name=”IDPLogin” enctype=”application/x-www-form-urlencoded” method=”POST” action=”<%= (String) request.getAttribute(“url”) %>” AUTOCOMPLETE=”off”>
When the JSP is executed, the following is sent back to the browser by the IDP server:
<form name=”IDPLogin” enctype=”application/x-www-form-urlencoded” method=”POST” action=”http://idp126.lab.novell.com/nidp/idff/sso?sid=4″ AUTOCOMPLETE=”off”>
With our policy defined above, the action tag will be rewritten to:
<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:
With the complexity of Web pages, many SSL terminators have issues rewriting all references in a web page from HTTP to HTTPS. The LAG must take responsibility for this work.
By default, the LAG rewriter will not rewrite the scheme if the proxy and back-end Web servers being accelerated talk the same protocol. In our case, all traffic into the proxy will be HTTP and all traffic to the back-end Web servers will also be HTTP – implying that no scheme rewriting will take place. Since the browser expects all links to reference HTTPS schemes, the LAG must be configured to automatically rewrite all HTTP references on Web pages to HTTPS.
When a user accesses a LAG protected resource, a corresponding Liberty Authentication request is generated by the ESP and sent to the IDP server via the browser. This authentication request includes multiple attributes, including information about the trusted Liberty SP generating the request, a target URL the user must be redirected to post authentication, and the contract to be executed at the IDP server. The target URL will be embedded in this Authentication request and will reference a HTTP resource. The LAG must be able to rewrite this HTTP request to HTTPS. An example of this is the following, sent by the LAG to the IDP via the browser
HTTP/1.1 302 Moved Temporarily Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=AF5484F1CD4D218C5404A17A0DA86E5A; Path=/nesp; secure Location: http://idp126.lab.novell.com/nidp/idff/sso?RequestID=idQgvQqocG6fgFrkeiUG6jlRD.LMk&MajorVersion=1&MinorVersion=2&IssueInstant=2010-05-18T13%3A53%3A26Z&ProviderID=https%3A%2F%2Flag129.lab.novell.com%3A443%2Fnesp%2Fidff%2Fmetadata&RelayState=MA%3D%3D&consent=urn%3Aliberty%3Aconsent%3Aunavailable&ForceAuthn=false&IsPassive=false&NameIDPolicy=onetime&ProtocolProfile=http%3A%2F%2Fprojectliberty.org%2Fprofiles%2Fbrws-art&target=http%3A%2F%2Flag129.lab.novell.com%3A443%2Fformfill%2Fphpinfo.phpentRef=u&AuthnContextStatemscell%2Fsecure%2Fname%2Fpassword%2Furi Date: Tue, 18 May 2010 13:53:26 GMT Content-Length: 0 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%3A%2F%2Flag129.lab.novell.com%3A443%2Fformfill%2Fphpinfo.php”. This needs to be rewritten to use the https scheme e.g. “https%3A%2F%2Flag129.lab.novell.com%3A443%2Fformfill%2Fphpinfo.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.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.