Australian eResearch Infrastructure Proposal
Dr. Erik Vullings
From an interoperability point of view on Authentication and Authorization using Middleware,
Australia requires two frameworks: Shibboleth® for accessing common services found on the
Internet, such as portals, Institutional Repositories, Content Management Systems, Wikis, etc.,
and PKI for accessing Grid Services, Grid Storage Facilities and High Performance Computing
clusters, especially since most of these services are based on the Globus toolkit which requires
PKI certificates. And clearly, interoperability between those frameworks is required.
Additionally, from an eResearch point of view, many projects need a similar IT infrastructure: they
need a website to disseminate their results, a CMS, Wiki, Forum, Mailing List, Calendar,
Collaboration tools like Instant Messaging, VoIP, AV conferencing etc. As many of these projects
are only funded for short durations, a lot of valuable research time is lost by building these
common project IT infrastructures over and over again. Also, as some content must be protected,
and some content can be openly accessible, authentication and authorization becomes a major
issue.
MAMS (Meta Access Mgmt System) proposes to restructure existing services in three layers:
Layer 1: Federation Services, offers common services across the federation like a Where Are
You From (WAYF) service, which also contains a list of trusted Identity Providers and Service
Providers in the HE federation. In addition, it will contain the Australian CA and a MyProxy server,
both protected via Shibboleth. This will allow Shibboleth users to convert their SAML assertion
into a long-lived PKI certificate (of an appropriate LOA class) at the CA, or a short-lived (proxy)
certificate via MyProxy. Finally, it will have a Federation Gateway to move from and to other
federations.
Layer 2: Trusted Identity Providers (e.g. HE institutions) and generic Service Providers (e.g.
repositories), all protected via Shibboleth.
Layer 3: eResearch Project or Virtual Organization layer, which contains generic IT infrastructure
components that any eResearch project will require (compare this to web hosting facilities offered
by an ISP: you can select the services you need before you start your project, and it will be setup
for your use when you start). The main access point will be the VO’s Service Provider access
point, which is a recognized SP in the Federation, and therefore can receive SAML assertions
from an IdP. In addition, it will obtain a proxy certificate for users from the Federation MyProxy
server, so the VO portal (GridSphere) will have access to a proxy certificate which can be used to
access Grid/HPC services. The VO-SP will be integrated with a VO-IdP to access all Shibboleth
protected services within the project. The portal will also be enriched by a Group Manager, similar
to VOMS, so authorization within a VO can leverage this information.
Middleware Infrastructure
Federation Services
Federation Services
WAYF
CA
SP
Federation Members:
Identity Providers
&
Service Providers
Virtual Org. Services
(VO, e-Res. dept,
Institutions, Project)
IdP
MyProxy SP
server Fed. Gateway
SP
IdP
SP
IdP1@USYD IdP2@ANU
SP1: Repos.
SP2: CMS
…
…
Layer 1
IdPn@MQ
SPm: Wiki
Layer 2
SP: VOj
SP: Grid
VO Portal
SP: Forum
SP: HPC
MyProxy Client
SP: Wiki
VO IdP
SP: Storage
SP: CMS
Layer 3
Improving eResearch IT Infrastructures
MAMS is currently developing such a layer 3 eResearch collaboration platform, called the IAM
suite (Identity & Access Management suite, pronounced as [I am sweet]), which should enable
eResearch projects to get a rich, SSO environment right out of the box. Any additional software
development should be focussed on developing research-domain specific components, and not
on generic components that many environments will need.
The IAM suite should be configurable to suite particular needs, for example, to turn on or off
some components, or to choose between different alternative applications (e.g. choose Wiki1
instead of Wiki2). In addition, it would be good if the tools can be managed from a central body
(for applying updates and patches, helpdesk support, etc.), which aligns with the NCRIS vision of
supporting many different research areas.
As already indicated in the introduction, each IAM suite comes with it’s own IdP, including
ShARPE and Autograph (if necessary). We do this to avoid burdening IdP administrators when a
new project starts with adding many SPs: instead, only one SP needs to be configured for each
project.
Another often encountered problem is the access management of a suite of tools. It is envisioned
that we can leverage Shibboleth for solving this too by providing a group manager inside the suite
that can be used for authorization within external tools. For example, a Wiki can be configured to
have a public area and a private area, a group of authors, and some managers. When
Shibbolizing the application, we define three roles: member, author, and manager. Within the
Group Manager of the suite, we would define a group for each role, and the membership of a
group would be transported to the Wiki’s SP in a SAML assertion from the VO-IdP, and mapped
to the appropriate role within the Wiki.
A final note is that we prefer to use Open Source Software projects as much as possible for a
number of reasons:
 No licensing costs; no hassles with vendors
 Easier to Shibbolize if source code is available
 Often have a larger community that is more willing to help out than in case of vendor products
Improving the Request for Proposals Process
In an ideal world, we would prefer to see the current RfP process improved by:
 Signing in-principal contract with the grant-funding body before submission. The reason is to
avoid delays after funding has been received, and since there is often little to negotiate, no
need to postpone it. Furthermore, it shows commitment of the organization to the project,
which is important.
 Signing the Federation agreement for joining as an SP
 Include a brief summary of the project’s main problem statement, the stakeholders affected
by this problem, the ideal solution they are striving for, and what would happen if they
wouldn’t do anything. Also include a list of deliverables and the desired project URL.
 Submitting a checklist with components that you would like your SP to have
 Installing the IAM suite: Between the informal decision to fund a proposal and the public
announcement, install the IAM suite in the desired domain, include the components that have
been checked, and add the summary and deliverables list to the project’s home page. The
public announcement can now leverage the project’s homepage to point to it for further
information.
Generic Components of the IAM suite
We see the need for two categories of generic components: small and simple components that
can easily fit as portlets inside a portal such as GridSphere provides, and more advanced
applications that are better used standalone. In the latter category, think of applications like a Wiki
or a Forum. Current development efforts are directed towards:
 A Shibbolized version of the JSR168-compliant OSS GridSphere project: this will be the
project’s main entry point, acting as the known and trusted SP in the Federation, consisting of
the following additional portlets (besides the ones that already come with GridSphere):
o Login option for non-Federation members
o Group Module for managing groups
o Authorization Manager for setting up RBAC for external Shibbolized components
o Presence indicator, indicating the status of its members’ communication tools (e.g. is the
person currently online for Instant Messaging, VoIP, etc.)
o Shibbolized version of IM, so we can use Shibboleth to link a member’s existing IM
account with his identity
o MyProxy client to obtain short-lived proxy certificates from the Federation MyProxy server
o A Content Management System, FedoraWeb, based on the Fedora institutional
repository (either internal to the project, or acting as the project’s front end for the
institutional Fedora implementation). Note that Fedora should be searchable using our
Authenticated Federated Search engine, which can do a distributed search across
institutional repositories on behalf of a locally (at the IR) authenticated user.
o VO-WAYF, for finding a Virtual Organization’s IdP members
o VO-IdP, with ShARPE and Autograph (optional), to manage which attributes to release to
which SP. Note that basic identity information (e.g. eduPerson) will be derived from the
Federation member’s IdP, but this information is enriched with attributes defined in
GridSphere, e.g. group membership, IM account name, VoIP accounts etc.
o Calendar application: might be external too
o PeoplePicker (starting soon): selecting members in the federation
 External applications:
o Wiki
o Forum
o In the near future, we may add other tools like Grid-specific tools or applications like
WikiCalc; this will mainly depend on requests coming from the eResearch community.
IAM Suite
Federation
Italic: After July 2006
h
arc
Se
Receive
assertions
AFS adaptor Federation SP
Fedora
(internal or
external,
e.g. IR)
GTK
GTK
Storage
Cluster
GTK
Specific
tools
GTK
Equipm.
via
IdP
VO-WAYF
GridSphere
VO-IdP
GroupModule
ShARPE
AuthN IM
Autograph
FedoraWeb
Receive
proxy cert.
Lo
gin
MyProxy
Presence
PeoplePicker
Calendar
AuthZ Mgnr
Re
c
ass eive
ert
ion
s
VO-SP
VO-SP
Forum
Wiki
VO-SP
VO-SP
LMS
Etc.
“Not our main focus”
Who Could Use the IAM Suite
Its intended audience is primarily focused at eResearch projects and Virtual Organizations or
Virtual Communities as they are sometimes called. A simplified version of the suite can be used
as a Federation gateway (similar to the myVocs project, but including a WAYF, allowing you to
enter additional Federation specific attributes, and the option to manage ARPs using ShARPE): it
consists of a trusted SP accepting all IdP’s SAML assertions in the own Federation, and
converting it to IdP endpoints sitting in other Federations (and vice versa). Clearly, it could also
be used for departments or organizations that don’t have a web presence yet.