Form Based Authentication for WebSphere Portal

I have been meaning to post about this for a few weeks now but have been flat out on some great wins for ISW. A cou[ple of great Portal wins and a couple of new Connections sites. (I might post about these shortly).

One of the methods of authentication with WebSphere Portal is Form Based Authentication. This is effectively where the client/user connects to the Portal login page and automatically enters the user name and password into the appropriate fields and then "POSTS" the form. This triggers the authentication and logs the user on.

The reason why we were looking at this is we were trying to get SearchBlox working for a client that was interested in using it to index and search their WebSphere Portal. SearchBlox is quite similar to the Google Mini search appliance in that it only support Basic HTTP Authentication and Form Based Authentication (Google Search Appliance offers a number of other means of authenticating over and above these).

So to test Form Based Authentication out with Websphere Portal I initially thought I would create a simple Widgit in my Notes client sidebar. To configure the widgit you simply create a web page widgit and choose the Form Option (HTTP Post). The widgit wizard then loads the page and you choose the logon form and enter the appropriate field values for the username and password. This works a treat and delivers a simple Widgit that will take you to the portal and log you on via Form Based Authentication. Nice!

So having done that and showing that WebSpere Portal does support Form Based Authentication I figured it should be simple to get it going with Searchblox. And it should have been! When you configure Searchblox you point it to the logon page, specify which fields to use, and provide the username and password for the fields. Simple really! But this is where I went slightly wrong.

I made the mistake of pointing the Form URL to the Portal login page. I ran the indexer and all I would get was about 4-5 pages indexed. These were the pages off course that were unauthenticated pages. Searchblox wasn't getting authenticated. After messing around for a few hrs I just couldn't figure out what was going on. Then it came to me! Off course I was pointing to the Portal Login Page which was wrong. I should have been pointing to the Login Form in the Login Portlet!

Using Firebug you can drill into the source of the Portal Login Page and find the Form URL that you need to use. As you can see in this source code the Form URL is available. Once I realised this I updated the Searchblox settings to use this URL for the Form Based Authentication URL and ran the indexer again. Off it went, logged into the site, and indexed the entire site successfully!

Websphere Application Server - First Steps Not Working - Need to learn to crawl before your can walk;)

I was just doing a fresh install of Websphere Application Server Network Deployment for a new Connections customer. Having installed WASND DMgr and installed the fixpacks I was next going to create the first server profile prior to the Connections Install.

Alas when I ran the First Steps Console it would simply not start! Everything else seemed fine. Dmgr would start, ISC was fine. But First Steps just wouldn't go!

After a little research I found this:

On Windows® platforms: The First steps console might not start if you use Mozilla 2.x as your default browser and it is installed in a location containing a space in the path name. This problem can also occur if you use Windows to start the First steps console associated with profiles installed on i5/OS platforms. To rectify this problem, perform one of these actions:

• Install Mozilla into a location without a space in the path name.
• Alter the registry key to remove the space.
• Temporarily set Internet Explorer as the default browser and then set Mozilla as the default browser. This automatically removes the space from the registry key.

Surely Not! I was using Firefox as the default browser though......So I changed the default browser to IE and tried First Steps again and it worked! Not great that this occurs but at least it is easy to get around.

Customising a WebSphere Portal Theme - Remove Signup and Edit My Profile Link

I have recently had the requirement to customise a Portal Theme a couple of times and every time I do it I fall for the same gotcha's so I thought I would document the process so I can remember next time. I recently modified a Theme to remove the Signup and Edit My Profile Links. Dave Hay shows us one way of doing this using XMLAccess however sometimes modifying the theme is required for other reasons as well.

The main reference on how to do this is the Info Center (http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/dev/dgn_crthm.html) however there are a couple of steps that arn't terribly clear so I have recorded what I did below here.

The easiest way to build a theme is to take an exiting one and modify it.

First copy an existing Theme
Copy the following directories and files contained within -
...\wp_profile\installedApps\portal1\wps.ear\wps.war\themes\dojo
...\wp_profile\installedApps\portal1\wps.ear\wps.war\themes\html\Portal
...\wp_profile\installedApps\portal1\wps.ear\wps.war\themes\html\psw

Then copy all of the tld files from the WEB-INF/tld directory in wps.war into the theme WAR's WEB-INF/tld directory in order to get support for all the custom tags used for themes and skins.

I found the description of the above a little confusing so maybe this screen shot helps to explain what the directory structure of your new theme should be.



Now to modify the Theme (to remove the Self Care links)
Now you can modify the theme quite dramatically but here I just want to remove the selfcare and signup links.

Find banner_toolbar.jspf in the html/MyThemeName directory and edit it. Now basically what we need to do is comment out the appropriate bits. Don't be mislead by the comments in the document as they arn't exactly worded well. Basically you just need to comment out the sections that refer to the selfcare and signup


Now a key step/gotcha in the process is to Edit and Save Default.jsp as well. This updates the timestamp so that Default.jsp will be recompiled with the updated jspf elements. It seems that if you don't do this then it just doesn't work.

Package & Deploy the Theme
This part wasn't so bad. Just follow the doco - http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/dev/dgn_crthm.html

Importing a Theme
and again this part isn't too bad. http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/dev/dgn_crthm.html

So once all that is done all you do is apply the Theme to your Portal pages. You might need to flush your cache and if you use a Proxy that cache's as well you might need to refresh that.

WebSphere Portal Express 6.0

A Lotusphere announcement that I missed (thanks Dave) was WebSphere Portal Express 6.0. We have looked at previous versions of Websphere Portal for a number of our clients in Australia in the past however as most of the Australian market is SMB it really was too big. We looked at Workplace Services Express however it didn't quite have the flexibility of the full Portal. So with the announcement of WebSphere Portal Express 6.0 it is great to see IBM continual commitment to the SMB space.

We have already been using IBM Lotus Component Designer (Previously Workplace Designer I think) and it really is a great tool for us Domino developers to move into the Portal space. Maybe a good project for me would be to integrate Workplace Forms with WebSphere Portal Express 6.0!!