Friday 8 June 2012

Getting intranet website authentication wrong

Website usability is as important for internal sites as for publicly accessible sites, yet for some reason the corporate whip-crackers are willing to accept substandard implementations when only their employees are being forced to use a service. The points below are problems in a leave management system provided by a major international company. It is unclear whether this international company or their local implementation team is responsible for the usability idiocy but here are some of the more annoying design problems:

  • Authentication integration. In most large corporations some form of central authentication service is typically available. There is very rarely a need to reinvent the security wheel by having internal websites with their own username and password authentication system. This is one of the worst usability failures as it is pure laziness by the implementer to use the out-of-box authentication rather than integrating to the central authentication service.
  • Username selection. Assuming laziness wins out and the site implements its own internal authentication, try to allow logical usernames. An employee ID code is a great database key but expecting employees to memorise their employee ID is totally ridiculous, particularly for a system they are not accessing daily. If you are unable/unwilling to let the users log in with their network credentials at least allow them to use an easy to remember username, their email address at the company for example.
  • Password constraints. Continuing with the custom authentication assumption, try to minimise user frustration with password selection criteria. Weak passwords are obviously a security concern but for internal sites where local network access is required this is less of an issue. Simplistic password constraints only serve to frustrate users. The most ridiculous (actual) example is not allowing repeating characters, thus the strong password "M@ss!veAtt4ck" is rejected yet "Idiot123" is allowed. This is not increasing security, it is needlessly annoying your users.
  • Reset password process. Should the user need to reset their password, try to simplify the process. On the login screen there will typically be a "Forgot password" link, it is really trivial to use the username already entered on the login page to populate the reset password page. Requiring the user to re-enter the username on the reset password page is redundant, even if it is an easily remembered value. Similarly, once the password reset is complete (via email redirect for example) rather populate the username on the login screen automatically, or preferably log the user in automatically with the newly created password.
The issues above only relate to the process of logging into the website, it is not hard to imagine the (un)usability of the rest of the site.

Thursday 7 June 2012

Bash script to extract dependencies from Java WebStart

A quick script to retrieve all the WebStart artifacts from a JNLP file and generate a corresponding classpath:


#!/bin/bash


SERVER=http://server:8082/e-calypso/
wget -Nrq -nd $SERVER/html/jaws/calypso.jnlp
CP=""
for jar in `cat calypso.jnlp | grep jar | cut -d"\"" -f 2`
do
        CP="$CP:./lib/"`echo $jar | cut -d"/" -f 3`
        wget -Nrq -nd $SERVER$jar
done
echo $CP > classpath


The function of the script is pretty simple, it retrieves the JNLP file from the server and then extracts all jar references in the file to retrieve the corresponding JAR files. As the JAR files are being retrieved they are added (in the correct order) to a variable to be used as the classpath. 

The need for this script arose from a requirement to have a client application launch using the correct dependencies and classpath ordering as used by the WebStart application. An alternative approach would have been to create a new WebStart JNLP with the new application as the entry point, unfortunately this was not practical given the organisational constraints (no access to deploy the change and 6+ week lead time for deployment via the approved process).

Some useful side effects of this approach:
  • It can be used to launch the application in the JNLP without requiring a WebStart launcher
  • The application can be launched with additional JVM arguments not supported by WebStart
A few notes on the script (as always):
  1. The -Nrq command line option to wget uses time stamps (-N) to ensure only new files are downloaded. The existing files are overwritten (-r) with the latest version, rather than having a number appended to the file name as is the default behaviour for wget. The output from wget is suppressed by the -q option so as not to print out unnecessary information.
  2. The -nd command line option prevents wget from creating directory structures when retrieving the files, this simplifies the classpath creation.
  3. The generation of the classpath could be improved with a regular expression rather than expecting a specific format in the JNLP file.