NON secure items?!?!?!?!

One of the security features of IE is often ignored. This feature is active when browsing a secure site (HTTPS), and it warns the user if the page tries to load files from other locations that are not secure. For example, a page could have an embedded link to an image file that is another server. While an image file is hardly a menace, there other scenarios where a non secure file in a secure site could cause trouble, and so this warning is shown. Unfortunately, most users will just click on "Yes", because that is all they can do from the browser side, but what if it happens to you, on your own server?

Well, there are many scenarios that could cause this, but I'd like to focus on one specific such scenario, with IBM Websphere being published through IAG. Normally, Websphere is an internal CRM application that runs on HTTP, but once it is published through IAG, it's hosted as HTTPS, and that starts the problem. Part of the websphere application, called DOJO uses Javascript to dynamically create some of the page, and that includes composing several links. When a site is published through IAG, it parses all the links on the page and modifies them to point to the IAG site in a process known as "Signing" or "HATting". However, when a page contains links that are composed using a script on the client-side, IAG may miss them and thus we end up with non-signed links. In the Websphere+DOJO scenario, this is exactly the case, and the user will get this message on every access.

What we can do? Well, on the client side, other than clicking "OK" each time, a user can set his security level to custom, and instruct the browser to ignore this situation, but that is not the best idea as it might expose the user to security threats (not to mention the fact that this needs to be done on all client machines for the entire organization). The correct solution is to modify the DOJO application to be aware of this scenario. IBM has this documented and can help its customers with this.

What else could go wrong? Well, this could also happen if the published website uses client-side code, such as JavaScript to dynamically alter the HTML page. In this case, the links in the HTML code is passed through the IAG filter in pieces, much like sneaking a gun through security inspection by taking it apart. This prevents IAG from signing the links. The solution to this would usually require writing a custom Application-wrapper code for IAG that will allow it to detect and sign the code properly.