Any one with a Tivoli Access Manager for eBusiness installation that they've inherited knows two things: It is a complex product and it can be quite difficult to get things working right. Once you do get things working right, like most IBM products, it is bulletproof and runs pretty much always.
Integrating the WebSEAL component with an F5 BigIP though can be pretty interesting, to say the least. Recently I had to change the load-balancer sitting in front of WebSEAL to an F5 BigIP LTM based solution. This was primarily driven by me not wanting to manage two different front-end load-balancers. This post is meant to chronicle items that I could no longer do in WebSEAL when front-ending the WebSEAL proxies with an LTM. Note: I **could** have used Direct Server Return on the LTM but I didn't want to because of the BigIP functionality that is lost when using Direct Server Return. These have been documented at length in an F5 DevCentral blog post, which you can find at the DevCentral site . Below are a few issues/items that arose and required some attention because of problems that they produced for the site.
ITEM 1: WebSEAL IP Address Based Authentication No Longer Works
The BigIP LTM, as I have noted quite frequently, is essentially a reverse proxy as far as your upstream load-balanced nodes are concerned. All requests from the LTM appear as if they are coming from your LTM, not from your end-user. Therefore, WebSEAL-based IP Address Authentication will no longer work. Interestingly, even though WebSEAL can pass an X-Forwarded-For header to an app server that it sits in front of, it won't do much with the X-Forwarded-For header that the BigIP LTM sends to it. So, if you utilize IP Address-based authentication in WebSEAL, you can disable it because you will need to move that functionality up into the BigIP. One of two things will happen if you don't do this. If you allow your internal IPs access to otherwise customer-IP-restricted junctions so that monitors or internal support people can get to it, chances are good that the IP address of your BigIP could be part of that list of internal IPs. This results in effectively allowing ALL access to that junction, (because all requests are seen as coming from the BigIP). If you don't allow internal network access to customer-IP-specific junctions, then moving to a BigIP effectively disables ALL access to that junction.
This is actually too bad because even though it takes some time getting the POP and ACL settings defined, no programming or scripting knowledge is necessary to set this kind of thing up. As far as I know, the only way to restrict access to resources based on IP Address on a BigIP is with the use of an iRule. iRules are a pretty flexible way to do all sorts of interesting things to traffic entering and exiting your web sites and the only real downside is that you need to know the Tcl scripting language in order to write them. To keep this article from becoming book-length, I've linked to another post on this site
that provides a basic iRule that you can use as a skeleton to create your own IP Address restrictions for WebSEAL Junctions.
ITEM 2: Terminating SSL on the BigIP Requires SSL to WebSEAL Too
Under normal circumstances, when WebSEAL receives a request, it inspects the protocol used to access the site and rewrites the response back from the application servers to the browser using the correct protocol. So, if you terminate SSL at your WebSEAL tier but use HTTP between your webseal servers and your app servers, any URL that gets streamed back to the browser will contain the junction name and the correct protocol.
If you terminate SSL at the BigIP but do not also use SSL between the BigIP and your WebSEAL servers, WebSEAL sees all requests coming in over unencrypted http and will rewrite all responses as http accordingly. Depending upon browser settings and browser version, your users could see a lot of warnings in their browser regarding a mix of secure and insecure elements.
So, if you terminate SSL at the BigIP, you will also need to terminate SSL at WebSEAL. You can still utilize irules at the BigIP level and you don't have to license a CA signed certificate for your BigIP and all your WebSEAL servers. You can use a CA signed cert at the BigIP tier and use self-signed certificates at the webseal tier. You can even use host specific self-signed certificates at the WebSEAL tier if you desire--all we really care about here is that WebSEAL sees the request coming in over SSL so that it can rewrite responses back to the browser using https in the protocol portion of the URI. A future post will deal with what needs to be done to set up SSL between BigIP and your WebSEAL servers.
ITEM 3: WebSEAL Quality of Protection Levels and Protocol Redirects
Related to Item 2 above, if you now terminate SSL at your BigIP, you don't **necessarily** need to worry as much about protocol redirects or SSL Quality of Protection.
Quality of Protection levels in WebSEAL for purposes such as removing SSL2 support or weak encryption ciphers will need to be duplicated (in another irule or simply by modifying the Client SSL profile for that site
.) on your BigIP. You can leave them enabled on your webseal servers but the important thing to remember is that your end-users will no longer be interacting directly with WebSEAL over SSL connections. Those quality of protection levels will only impact ssl connections from your BigIP. Terminating SSL at your BigIP means that SSL connections from browsers will not pass-through to WebSEAL.
Deployment Guide Series: IBM Tivoli Access Manager for E-business 6.0