eResearch

You are here

Mirage / ACLS Integration

Background

The Centre for Microscopy and Microanalysis (CMM) uses a proprietary system called ACLS for managing a number of aspects of the Centre's business.  These include:

  • managing user and account records for UQ and non-UQ clients,
  • managing bookings for the Centre's instruments and ancilliary equipment,
  • managing user certifications,
  • implementing access control to selected instruments (via the ACLS console login app; see below), and
  • reporting on booked and actual usage hours.

(ACLS can do more than this via extra modules, but that is beyond the scope of this description.)

In summary, ACLS is core to CMM's "business operations" in serving its clients, both directly and indirectly.  CMM cannot abandon using it, and it would be a big software engineering project to replace it.

The Problem

A data management system such as Mirage needs to interface with the facilities provided by (in this case) ACLS.  The ACLS system manages and stores a lot of information that (ideally) relates to the data management functionality we are providing.  The problem is that ACLS is a closed system:

  • It is a closed source system.  With one exception (see below) external developers (such as ourselves) are given no access to the ACLS source code.
  • The ACLS server's database is closed.  It is implemented using technology that doesn't allow access from external software.  Furthermore, the schemas are not available.
  • The ACLS server provides no external APIs that could be used to access the information in the ACLS databases.
  • While it is theoretically possible to "screen scrape" the ACLS web site, the server tends to be unstable under load and there is a significant risk that screen scraping would trigger crashes.

Fortunately, we were able to get at least some information out of ACLS.

Proxying the ACLS Login Console

ACLS provides access control on instruments (or "facilities" as it calls them) by means of the "ACLS Login Console" application.  This is a Windows application that is installed on the instrument that implements a password controlled screen blocker.  To gain access, the user logs in using his or her ACLS user name and password.  The login console connects to the ACLS server which checks the supplied credentials (and a few other things) and responds to the console to say whether access is allowed.  The console then unblocks the screen.  (Actually the interactions are a bit more complicated than that ... but general principle is as described.)

The protocol that ACLS uses to talk to the login console app is proprietary and undocumented.  Fortunately, the ACLS manager (Dong Zhang) was willing to supply us with the source code of a couple of versions of the login console, which allowed us to reverse engineer the protocol.

What we have done is to insert a proxy server in between ACLS server and the login console.  The console is configured to use the proxy as its server, and the server is configured to accept requests via the proxy.  As the proxy relays the messages, it tracks who logs in and who logs out, and records the session in its own database. 

The Current State

We now have a working and stable system that consists of:

  • a Java library that implements various flavours of the ACLS login console protocol, both from the client and server sides,
  • an ACLS proxy service that can sit between the ACLS server (recent versions) and the ACLS login console (various versions), and
  • an ACLS adapter that provides a simple HTTP-based service for proxy login.

The code works for the versions of ACLS and the login console that we use, but given the nature an evolution of the protocol, we cannot make any claims for other versions, past or future.  

In order for proxying to work, you need to be running a recent version of the ACLS server that supports "Facility IDs".  (Older versions of ACLS rely IP address for "facility" identification which doesn't work if you insert a proxy between the client and server.)  You then need to:

  • create a "dummy facility" in ACLS for Data Grabber authentication,
  • update the existing ACLS faciliy details to add a "facility id" for each instrument,
  • create a "facility configuration" for each instrument via the Data Grabber's web interface, and
  • alter the configured ACLS server IP address in each installation of the ACLS console.

In Mirage, we use the session information recorded by the ACLS proxy to determine who owns the files as they come of each instrument.  This allows us to ascribe the data to the correct users at the point that they are ingested into the Mirage / MyTardis repository.  This avoids burdening users with a manual process of "claiming" their files before ingestion.

The Future

It is hard to see how we can do much more in terms of ACLS integration unless the ACLS suppliers:

  • make the ACLS source code and development process open,
  • modify ACLS to use a decent SQL database that could be queried from the outside, or
  • implement a comprehensive set of web APIs to allow external services to interact with ACLS.

The other alternative is for someone to design and implement an open source replacement for ACLS.  That would be a significant undertaking.