VuFind UConnect SSO
VuFind is the library catalogue system and UConnect is USQ’s custom SSO system that was developed. I’ve gone through and built an integration between the two which looks like the following:

I talk a bit more about VuFind, SSO and authentication in an earlier blog post.

Book Finder
This is primarily the work of Ken MacAlpine who is working on mobile technologies at USQ. Ken developed an SVG powered map of the top floor of the library to aide in the location of books. He put together a database of roughly where the catalogue numbers stop and start for each shelf on each side. It has been integrated into the catalogue and shows up as a “Show on Map” link for Toowoomba Main Collection items.

At some point in the future we will work to expand it to all campuses and collections. When it is clicked it appears in a new window like this:

It is aimed to be the same size as an iPhone display so that it fits neatly there. It also works in all browsers that support SVG. Fallback support is provided for IE since it doesn’t support SVG yet.

ePrints, RPCS and data conversion!
As an interesting exercise I also spent some time converting data from an internal reporting system, RPCS, into our open access repository – ePrints. This was a fun project which required connecting to RPCS’ MSSQL database and outputting an XML file for ePrints to eat. To do this I figured I’d pull out Web Matrix, Microsoft’s cut down editor for web developers. It feels on par with Geany though it has a built in web server, request tracking and a database explorer. It also integrates with the Web Platform Installer product which means I can easily install other applications. I used Web Matrix to kick start the Joomla! install for the Access All Databases research project as well.

The RPCS data is loaded into our ePrints system along side the Author ID project that existed there. We’re also pulling across the data from their system which is going to result in duplicate authors until we merge them down to uniques however doing so in an automated manner isn’t easily possible. There is a whole heap of work to get things together but all in all we’re doing well.

EQUELLA Moodle module
Last but not least I’ve been playing with the EQUELLA Moodle module. It adds an extra option to the Moodle resource drop down and enables access to select items from the EQUELLA repository software.

I’ve used Web Matrix here to deploy out a quick Moodle site utilising the same Web Platform Installer technology and managed to get up and running quickly with everything. The deployment of the module to our main Moodle environment would enable lecturers to directly select course readings to embed in relevant modules on their Moodle course pages – exciting!

USQ also developed the Virtua driver for VuFind. Virtua, the library’s integrated library system (ILS), doesn’t provide a driver themselves but sells a reasonably expensive layer which integrates with Drupal these days. Originally such a layer didn’t exist and the system operates by a complicated mess of reading directly from database tables and posting stuff to arcane undocumented web interfaces through an even older web application known as “iPortal” with a binary named “chameleon”. Much fun!

So one of the things that has been desired for a while is the ability to integrate with the corporate directory service and corporate single sign on service. Unfortunately the vendor product is an all or nothing: you either have everyone authenticating from the directory or you create accounts inside the ILS which can authenticate. Due to the nature of our Library and the non-USQ patrons (e.g. people who pay to join the library or reciprocal borrowers) we have we can’t easily just pick the LDAP option. That leaves us in a position where we have to have our own passwords distinct from everything else which leaves a bad user experience.

Fortunately VuFind has a pluggable authentication layer. This means that we can supply our own authentication to handle things. Great! Except that the list of authentication plugins was hard coded. Well not so bad, but easy enough to fix by altering the system to have more flexible support for authentication handlers.

So by default we have an ILS authentication handler which works fine. And for those non-USQ users we still want to use that handler because it works great right now. But we also want to have another one that hooks into our LDAP directory and integrates there. Now I could build a new magical plugin that handles both the ILS authentication and the LDAP authentication however I figured that this was a bit much and decided instead to build an authentication handler which allows chaining of multiple authentication handlers, creatively called “MultiAuth“. This allows chaining and processing of the fields to ensure that they are consistently used by all subsequent child plugins. Nifty!

So now that we have better pluggable authentication support and the ability to chain multiple plugins we’re getting close to everything we need. The USQ situation is unique in that students are issued with a barcode identical to their student number. This makes them easy to process because we can map them directly from the LDAP interface into the ILS system. Staff however present a much trickier problem. Staff are created with a custom barcode and identifier which is distinct from their staff username and unique from the staff payroll number. This means that we need to dereference their username back to their ILS identity. Fortunately this was already done: an alternate barcode in a particular format stored their payroll number for cross verification. Sweet! In the not so lucky bucket was the fact that the custom barcode format meant that I could do a direct mapping still and needed to write some custom code. So with some modifications to the Virtua driver to pull out the alternate barcode and grab their real barcode to log the user in.

So at this point a user can login using the LDAP credentials or the standard ILS credentials. For relevant staff and students this means they’ve got two options but thats better than nothing. This is great but it isn’t single sign on yet because they have to log into the library catalogue specifically and that isn’t fun! So bring on the single sign on!

USQ has its own SSO system that was developed which means the standard mechanisms don’t work (bummer!). Fortunately our ICT department has some smart people and they’re also PHP friendly which means that there was already a library and sample code sitting just begging to be integrated. Surprisingly with the rest of the LDAP stuff in place this was relatively easy. The library did the heavy lifting of authenticating the user and returning their details so we just have to replicate what we had before. Students go straight through since their usernames match their barcode and we do a lookup with the staff payroll number to backtrack to finding their actual barcode and then logging them into the system and sending them on their way.

Fortunately this is all now in place on the live system which is up and running.

My solution was to use token login to handle the actual request. The process is a tad convoluted, but the diagram should explain how the system works:

So the user logs into a remote service, which proxies a username to the Joomla! which is picked up by SSO HTTP in a custom component which generates a token using the detected username, redirects the user to the token login component (not through the proxy) which then lets the user log in and continue through the site.

So what we need to create is a new component to handle detecting the user, creating the token and them redirecting them. We can use the SSO HTTP plugin to handle detecting the remote user perfectly fine (this has already been tested) and the Token Login component can handle validating tokens and redirecting users.

Step 1: Prerequisites
I’m going to use the JAuthTools packages available from Joomla!Code. To install these, you will need to install the Advanced Tools package first before you get started. The latest version is Advanced Tools 1.5.1 available from JoomlaCode.

Once we’ve got the Advanced Tools installed, we’re going to need the JAuthTools 1.5.4 Core package. This will give us the SSO library that we’re going to use later on. We will also need the SSO plugins package (for the SSO HTTP plugin in our case) and the Token Login package. As we’re not using the user source plugins for this case (both LDAP and Session are provided by default) we don’t need to install them and since we’re going to write our own SSO detection component we don’t need to use the options offered by the SSO package.

Once we’ve got all of the prerequisites installed we can start building the component

Step 2: Building the component
So we’ll start building our component with the basic few lines all components require:

This basic check ensures that we’re within Joomla!’s confines or kills the execution if we’re not. From here, lets set up some basic variables:

These are two variables we’re going to use later. The landing page is used for token login to redirect the user to a page once they’ve been authenticated successfully. The autocreate option is utilised by the SSO system to determine if it should automatically create the user. Keep these in mind as we’ll use them later on.

In this next phase we’re going to take a copy of the current user and then use the SSO system to attempt to do the login. If its successful, the user’s ID will change and we can then create a token for them and redirect so they can login, if not we’ll redirect them with an error message:

So we get a reference to the user object, get a copy of the user ID, import the SSO library, create a new SSO authentication object and handle authentication. We see the $autocreate variable we initialised before used here. We could load the plugins ourselves and handle everything but the doSSOAuth call will handle this for us, create the users session and if requested attempt to create the user if they don’t exist. We can then check if the user ID’s are different and then create a token to direct the user back:

A sizable chunk of code. So we check if the user ID has changed (typically from unauthenticated to authenticated, we could also just check if the user ID != 0 as well). We then import the token login library, grab a copy of the database object and then create a new token.

So with the token, we set the username to be that of the currently authenticated user (which we know is correct), set the expiry to be the present time plus an hour. Since this data is only ‘temporary’ we don’t bother with JDate and just use the server time. If the server transitions to or from daylight savings there could be an issue but since the user should be redirected rather quickly that seems like an unlikely possibility. We set the number of logins that the token is valid for, which for this case is only one and then we set the token’s landing page to be the value of $landingpage that we set before. Once we’ve set all of the data we call the ‘store’ function to save all of this to the database which will also trigger the generation of the login token.

Since the session we’re currently in is invalid, we destroy it for a bit of extra security and then we redirect the user to the token login component. Since this request will get proxied as a redirect to the real site (hopefully the proxy doesn’t rewrite the redirect header coming back otherwise this will fail), token login can then authenticate the user (again) and create a session for them without the proxies’ interference. There is however one last part of our component, which is the else case for if the user doesn’t get detected:

So if we don’t detect anything, redirect the user to index.php with the message ‘Invalid SSO Request’. Too easy almost!

So for reference below is the final completed component file, don’t forget to update the values of $landingpage and $autocreate:

The first step in all of this is to install JAuthTools. The Context Login bit is mostly self contained so once you’ve got my Advanced Tools extensions installed you should be able to install the extras package. You can grab the 1.5.1 version of the Advanced Tools extension off Joomla!Code at http://joomlacode.org/gf/download/frsrelease/6797/22390/com_advancedtools.tgz and install directly in Joomla!. The next item we’re going to need is the helper package, the best way to grab this is to install the JAuthTools Core Package from http://joomlacode.org/gf/download/frsrelease/9530/36171/pkg_jauthtools_core.tgz which will also give you SSO and User Source libraries as well. The JAuthTools Extras Package contains both the context login module and the Advanced GMail authentication plugin. The extras package also has the LDAP user plugin and the Advanced LDAP plugin but we’re not going to use that today. The current version of the extras package is 1.5.4 (just released!) and you can grab it off JoomlaCode at http://joomlacode.org/gf/download/frsrelease/9530/36195/pkg_jauthtools_extras.tgz and you can also install this directly into Joomla!.

Once you’ve got everything installed, you can get to work. The first place we need to go into the Module Manager in the Administrator and look for Context Login. It’ll be there but it won’t be published by default. Opening it up we’ll see a lot of the params that we know and love from the core built in login module but we’ll also see some params immediately below the caching option called “Contexts”, “Require Context” and “Default Context”. The “Contexts” param is a text field that allows you to enter a per line entry of contexts. In this case we’re going to have two different contexts: one for the main GMail domain (gmail.com) and another for a Google Apps for your Domain (say “yourdomain.com”). Perhaps you’ve got a few of these domains that you want to limit people to so what you can do is enable the “Require Context” option. This will enforce a given context upon the module and remove the ability for the user to be flexible. Keep in mind that this isn’t added with the request, only a context ID is sent which is then looked up and found on the remote site. The last option is the default context to use which is set to -1 initially but can be set to the index of the context (starting from 0). This changes the context select box with the default selected and is purely a cosmetic setting. Once you’ve put in a few domains, you can enable the module and position it somewhere. If you want to put in some extra settings you can also do this like you would do with the normal login module.

The next step is to configure the Advanced GMail plugin. The Advanced GMail has all of the features of the existing GMail plugin and then some. If you’re currently using the GMail plugin, disable it first before you switch to the Advanced GMail plugin. The Advanced GMail plugin has a few configuration options such as “Apply Suffix” (similar to contexts but limited to only a single domain), “Username Suffix” (used with Apply Suffix, a single domain name such as “gmail.com”) , “Verify Peer” is a SSL configuration option that should be left on unless you’re having seriously strange issues (at this point, change host!) and that leaves us with “Use Contexts”. This is a simple option that has “Yes”, “No” and “Require”. What this then causes it to do is look for a context in the request and then apply the context if it finds it. The “Require” option will then enforce the use of contexts and will fail the user if the contxt doesn’t line up properly. The last option is a ‘username’ blacklist. This is a list of usernames that the plugin should never authenticate for which is useful for accounts that you may not control (e.g. ‘admin’) to prevent people logging in using it. This is an extra security feature that I’ve introduced and is certainly recommend using. Enable the plugin and we’re off!

Once both the module is configured and enabled as well as the plugin you should be able to see it in the front end. From here you can see the form and log into to it, selecting your context and then logging in appropriately.

Today is Melbourne Cup day, being the first Tuesday of November, so we had a luncheon of sorts and a drawing for the horses. Didn’t win, the food was good, I’m $10 poorer and such is life.

I’ve been spending more time at work using my Mac as a primary machine. Since I’ve moved to Exchange from Domino (or Outlook from Notes), I’ve gotten Evolution on Linux mostly working (with the exception that it doesn’t automatically look up names for emails which is tedious) and Apple’s Mail and Address Book both playing nicely with Exchange. I do miss the fact that I had Notes on my Linux desktop and things mostly worked albeit slowly and consuming large amounts of memory, but it worked with all of the features available normally. Mail’s ability to due autocompletion is what is drawing me back to it as a client, which when you start writing emails is actually more useful than you would think. Its still not up to par with the Notes autocomplete which was quite cool and a lot more advanced than either Mail’s or Outlook’s (I get Outlook via Citrix).

I’ve also been trying out NetBean’s PHP Early Access through a nightly build (has the ability to create PHP projects from existing sources) and I’m impressed with it. I tried it out because I wanted to try out debugging with my PHP instance and the dated version of Eclipse I had (3.2) seems to have issues – more than likely my fault – and I don’t want to waste time on trying to fix something. NetBean’s installed and worked almost instantly, however it took me a while to find where I could change the params to get J! to route items properly. I managed to work out the bug that I was having without too much issue. I knew what it was but not where it was: turned out to be exactly what I thought, an assignment operator used instead of the append operator. The Subversion support seems to be a bit off and doesn’t work yet, so I’m not quite ready to ditch Eclipse yet – but I’ll try with later versions to see what I get.

I had a chat with the principal (we have principal, manager, director, CEO as our chain of command) about the projects that I’m doing and the ones I’m interested in so I’ll have to do some paperwork and business cases for the new projects and justify items. We’ve recently got a new manager who is trying to find where everything is so part of this is explaining everything so that he can get a grasp of the way the system works.

Then I spent the majority of the afternoon with one of the ITS guys working through how our Citrix boxes work with Flex profiles and the mandatory profiles filling in the gaps in his knowledge and how different parts of the system and why items might break or behave in a particular way. I think he’s worked out how it works and he’s even figured out why a few issues are happening. So nothing exciting but useful.

And finally I had fun with Kerberos. I built the Kerberos module on the SLES10 server, installed it, restarted Apache and tried to get it to work. On my Mac both Safari and Firefox requested a username and password instead of using a Kerberos token and IE6 in my Citrix session seemed to just go in a weird infinite loop. I slowly worked through my entire Kerberos configuration on the server until I got to looking at the keys. It turns out that the keys were created with the wrong virtual host name for the server which is causing the issues. The keys for the real server name actually worked fine when I got around to testing them which proves that everything will work once I get the keys. The last part is a fix to the Citrix system which for some reason think that the intranet site is actually on the internet, but I’m assured that this should be easy to achieve. Getting Kerberos up and running was pretty easy ignoring the faulty keys compared with some of the nightmares I’ve had getting items to play nicely together. I’ll probably add something to my guide (http://sammoffatt.com.au/jauthtools/Kerberos) on it, to help with items.

Who knows, I may have even figured this Kerberos thing out!

First up for today is a personal thing, I completed a rather largish Uni assignment today which reminded me of all of the pains that come with C++, but to follow that I returned to working on my filesystem in C, which is just more pain. I got a quick response back, and almost full marks (96%) so I’m happy for all of the time I put in to get it done and how its probably far more complicated than anything else that will be submitted (it used Boost Signals and a whole heap of other things that I don’t think will ever be taught in the subject for a long time). But hey, thats just Uni!

Today I finally managed to get Pentaho, some business intelligence (BI) software, to play nicely with Novell eDirectory’s LDAP interface. I must have missed the option, but Pentaho doesn’t seem to accept anonymous binding to the LDAP server, which means I need to bind as a user. By default our users funnily enough have less access than the anonymous account (which is actually a proxy account with full browse permissions). The solution was simple enough: we shunted our dummy Pentaho user into the same group as the anonymous proxy account and everything worked. So I’ve now got Pentaho using LDAP for authentication (yay!) and a MySQL database to get its role/group permissions. Funnily enough when its all said and done the documentation is pretty close to the mark.

But once I had that I don’t have an ability to manage the groups/roles within Pentaho, so I end up having to write some small PHP to manage that. Luckily I worked on a project a while back that I called “Joomla! Central Management for Users” which basically connected directly to MySQL databases of Joomla! installs and altered the users. I had originally built it with a plugin infrastructure in mind so that I could plug other stuff into it later. Starting this morning it only had a ‘connector’ for Joomla! 1.0 via MySQL and LDAP, now it has one for the Pentaho security tables. This means I can easily copy users from LDAP or Joomla! into Pentaho without too much issues and has a debugged user interface already. But wait theres more!

When I was originally developing the tool I wrote a query language for it. See, SQL is a great language for databases, but its a bit hard to apply in situations where you don’t quite need all of that power. So I wrote my own query language. Its quite simple it can validate simple attributes and allows for set operations within “Sites” (a site is a container for users and groups). So for example I want to see all of the users who are on our web site but not in our LDAP directory:
existsin “Web Sites” and not existsin “LDAP”

Primitive sure, but it because writing a large SQL expression for something simple. I hope to expand on it, but it already does what it needs to do for the time being.

So I’ve covered query languages, LDAP and BI! All I need now is the filesystem news. Today there was a whole heap of fan fare on Slashdot about the ZFS news from Apple, whilst thats cool and all (especially since I don’t mind Apple’s UI), I personally have my own filesystem that I’ve gotten back into to do some work on. It also happens to be a Uni assignment due on Friday! So I’ll be back to working on that and hopefully I’ll have it to a nice stage that I can do some lightening talks at linux.conf.au!

Recently I released JDiagnostic, a tech demo of a tool that I hope will evolve into a launching pad for a wide range of useful tools, tests and diagnostics. At present it solves the above stated problem: MSAD integration. Its a step by step wizard configurator for Active Directory, with tests along the way. At the end it configures the LDAP SSI and Joomla! LDAP mambots with as much details as it can (what you’ve supplied) leaving you hopefully with a consistent and working Active Directory setup, without the pain of having to read through logs to see what is happening.

You can check out JDiagnostic on the Pasamio’s Projects FRS page.

Well, I’m glad you asked that question, because I’ve got it covered as well! I’ve written up a simple starters guide on how to get an LDAP server up and running and get Joomla! authenticating into it. Its mostly step by step and I’ve tested it out running Debian and Mac OS X 10.4 with the standard OpenLDAP instances that ship with those environments. Not only that but when you complete the tutorial theres a sample configuration for both Joomla! 1.0 and 1.5 so you can get up and running easily!

Lastly I’ve released 1.0.3 of JAuthTools for Joomla! 1.0 which adds support for LDAP powered administrator login (previously it relied on caching your password from the front end), a small refactoring of authentication options and some fixes in the XML files for missing or short descriptions. As always this is tested against Microsoft Active Directory, OpenLDAP and Novell eDirectory to see if they work and there are samples of known good set ups for those environments.

So you’ve read all of this and you’re wondering where you can the information from so heres the answer: for JAuthTools 1.0.3 you can go to the File Release Section on Joomla!Code, for the sample guides, the alterations required to the Joomla! Core to get back end login and much more documentation you can check it out at the JAuthTools wiki.

So what are you waiting for? Good luck!