ISAM for Web – Different login pages per junction

Update 15/05/2015:
It would seem that I may have over complicated this, we have a ISAM feature to do this already! 🙂
Apparently since TAM 6.1.1 we can use static management and error page templates per junction, as stated in the following technote:
http://www-01.ibm.com/support/docview.wss?uid=swg21587936

So feel free to choose your own adventure!

Different people access different applications. Different applications might want to look different even at the authentication stage. Using ISAM for Web, its possible to use a simple bit of JavaScript trickery to modify your login page to appear differently depending on the application that the user is trying to access.

In this post, I’ve put together a login page and set of accompanying resources that will appear differently in the browser depending on the junctioned resource the user is trying to reach. In this example, I’ve defined three different resources:

• Resources at the WebSEAL root: “/”
• Resources at the junctioned application “/demo/”
• Resources at the junctioned application “/test/”

The end result should look something like this:

This particular mechanism could be shaped a couple of different ways with ISAM for Web, in this article, I will make use of the standard ISAM for Web login form page templating, and the inbuilt macros available to the HTML. Another way this could be implemented is through an EAI, this would allow server side page manipulation, something that you cannot do with the WebSEAL login template.

Step 1: Crafting a base login page

When using Forms based authentication with WebSEAL, there is a few core concepts required:

• A Username Input Field named “username”.
• A Password Input Field named “password”.
• A hidden field called “login-form-type” with the value “pwd”.
• The form is POSTed to /pkmslogin.form

With this in mind, that is the base requirement for any custom login page.

WebSEAL also exposes a selection of macros that allow information about the request to be replaced into the templated HTML file. The minimum you would likely use in this scenario are:

• %ERROR%
  The hard-coded error message returned from ISAM.
• %URL_ENCODED%
  The requested URL cached by WebSEAL.

With that in mind, here is a base Login page:

Note the macros in their prefilled form. (%ERROR%, %URL_ENCODED%).

Step 2: Crafting the CSS per junctioned application

Next, I crafted some CSS pages, that would modify the look and feel of the three separate applications.

(Right Click and “Save Link As” to save them to your computer.)

Note: This CSS was based off a login page example from:
http://designscrazed.org/css-html-login-form-templates/

Step 3: JavaScript gluing it all together

There is three functions of JavaScript that I will add to this page:

1. Anti ClickJacking JavaScript code.
   Having just completed the article ISAM for Web – Clickjacking prevention it would be remiss of me not to include this feature.
2. CSS Styling based on the destination URL.
3. Displaying the ERROR text in an appropriately formatted box.

SEE ATTACHED HTML Sample above - WordPress isn't displaying the HTML properly...

Development Notes:

• I chose to hash the requested junction URLs to determine the appropriate CSS. Hence the names of the CSS files such as “3556498.css” for the /test/ junction. This was preferable to a set of If/Then statements in the code listing the available junctions and just created a layer of abstraction from the URL requested to the CSS that was supplied. It is equally plausible that you could configure the JavaScript to simply load “test.css” for the /test/ junction and “demo.css” for the /demo/ junction.
• The page loads “base.css” as a default, and relies on the ‘cascading’ nature of CSS to override it when a subsequent application specific CSS is added via JavaScript. In low bandwidth scenarios, it would be necessary to ensure that the base.css doesn’t load too much additional content that may never be displayed to the user.
• This example doesn’t show the use of Virtual Host junctions, but a similar mechanism could be achieved via the macros %HOSTNAME%, %HTTP_BASE% and %HTTPS_BASE%.

Step 4: Importing it all into ISAM for Web

a) Import the new login HTML into the login.html template file.
b) Place the CSS and accompanying images in an accessible location either on ISAM for Web under the Management root -> junction-root.

c) Apply an unauthenticated ACL to the CSS files so that they can be displayed without authentication.
You can either use an existing Unauth ACL – such as the favicon, or the isam for mobile unauth ACL, or you can make your own, following the steps described here:

http://www-01.ibm.com/support/docview.wss?uid=swg21406125

Optionally: If you’re loading your CSS files off the WebSEAL host and you’re running a version of ISAM that is 8.0.1.1 or older, you might need to add the MIME content type to the WebSEAL configuration file under the content-mime-types stanza:

[content-mime-types]
css = text/css

This will ensure the browser accepts the CSS as a style sheet.

Step 5: Testing

Test your configuration via your browser, I found using Firebug helped me to debug any issues with the JavaScript and CSS loading.

Ensure you test both HTTP and HTTPS, and watch for “Mixed Content” and also check for handling of incorrect URLs.

Step X: Adding a new Application

Subsequently adding a new application is very easy. Once you’ve created the new junction, attempt to access the URL for the application, and using FireBug watch for the requested hashed CSS file.

Now with your newly adapted CSS file to suit the new application, add this to your CSS store.

 

Update 15/05/2015:
It would seem that I may have over complicated this, we have a ISAM feature to do this already! 🙂
Apparently since TAM 6.1.1 we can use static management and error page templates per junction, as stated in the following technote:
http://www-01.ibm.com/support/docview.wss?uid=swg21587936