In 2008, the Australian Access Federation (AAF) project was starting to ramp up and research was undertaken to determine the best-of-breed tools available to manage a large, ambitious SAML 2 based federation such as the project had outlined in its design phase.

After some review it was decided that software called Resource Registry, which was developed by SWITCH, was the most complete (and possibly only!) option and successful deployment of that tool went ahead in late 2008.

However, there has been significant growing pains associated with the tool as the AAF has matured and there is much functionality missing which needs to be created. Having performed a review of the current codebase and the available skill sets within the AAF, it was decided in Q3 2009 to proceed with the development of a new tool called 'Federation Registry'. This tool would provide new functionality critical to the operation of the federation in small phases and over time would grow to be the only management tool in use.

As a result the following guiding requirements were present when making the decision to design and develop the Federation Registry:

• A focus on managing end-to-end in a complex SAML2 based federation.
• The basic ideas and functionality promoted by Resource Registry were sound and should continue with some additional polish.
• The data stored in our Resource Registry is critical and should be able to be imported to the new tool at regular intervals (until Federation Registry becomes the primary source).
• PHP was suboptimal for our existing skill set and already developed libraries. A Java based solution was preferable.
• Embedded SQL in multiple files is not nice to deal with in an ongoing capacity. In fact having to update SQL queries at all is not good for future maintainability.
• The tool must be web based and fully integrated with SAML 2.x compliant SP software (initially Shibboleth).
• Flexible, potentially complex workflows should be available for all operations in the Federation Registry, particularly in relation to component creation, modification and deletion that will effect the federation metadata document.
• The tool must allow multiple administrators from multiple partner organisations to perform tasks related to their federation components (specifically IDPs and SPs).
• The tool must be able to help AAF administrators and support personnel to gain a decent understanding of what is going on in the federation and allow them to access fine grained reporting to determine the current federation status, member adherence to AAF policies and promotion of AAF usage statistics to executive committees and other management folk.
• Be highly extensible from the database through the various layers to the web presentation layer to allow for future requirements to be developed and deployed in a cost effective, agile manner.

Implementation Technologies

Having played with various Java web technologies, including wicket, struts2 and others, it was decided that the solution would be built on Java 6 and the open source Groovy/Grails platform offered by SpringSource which provides many benefits:

• Groovy operates on the JVM but is a lot more expressive in terms of syntax - this saves hours of development time.
• Grails provides a full database to presentation layer solution saving considerable development time.
• Grails wraps the complex Hibernate ORM solution in a layer called GORM allowing us to do away with SQL queries and also the complexity of Hibernate XML configuration files.
• The Grails ecosystem provides a range of open source plugins which are easily installed and leveraged again saving much time and cost in development.
• Extending a Grails application with new web content and functionality is easy and straight forward.
• Groovy and Grails testing frameworks are significantly more advanced over the base JUnit 4 offerings.
• Groovy and Grails can utilise all existing Java libraries.
• Java developers are easily able to adapt to the Groovy/Grails combination.