A nice article was recently published on IBM’s WebSphere Portal wiki about using a mixture of HTTP and HTTPS pages on a WebSphere Portal site. The reasoning for that approach is basically that you need to encrypt certain sensitive traffic, but don’t want to encrypt traffic for the entire site for performance reasons.
Before you go off and implement that solution, you should ask yourself a few questions.
- Is the performance impact of using https everywhere really a problem for YOUR site? Configure Portal to use https for all requests. This will be easier if you’re using a reverse proxy such as Tivoli Access Manager (WebSEAL) or CA SiteMinder. Perform load tests to compare and see if your SLAs will still hold up. If performance is fine with https for all requests.
- Do you have a lot of pages that would need to be encrypted, and will it change frequently? You’ll have to main sure you set the configuration parameter to ensure the page is encrypted, which is easy enough to do. However, the more pages you have that need this, the higher the chance of it getting missed. Also, if you’re using dynamic portal pages, ensure that you take those into account.
- Your users’ sessions can still be hijacked while on non-https pages. Do you care? Many sites secure just the login, but that’s not good enough if you really want to be safe. This is a calculated risk based on the type of content and functionality on your site. Even if your portal is intranet-only, you need to determine how much damage one rogue employee could cause.
- Do you have any page resources (css, JavaScript, images, etc) that have hard-coded URLs using http? This can give you the annoying messages that say your page has a mixture of HTTP and HTTPS content. Perhaps you can just change the link from http to https, or you might also need to get a little trickier and use mod_proxy or another technique to proxy an https request through your web server to the original http resource.
And finally, don’t forget to use ssl as appropriate between systems in your internal networks. This applies to connections from your reverse proxy to the web servers, from the web servers to WebSphere via the WebSphere plug-in, and from your portal system to any back-end services.
