James Dalziel, Macquarie.U: Deployment Strategies for Joining the AAF Shibboleth Federation

Abstract

Trust Federations have emerged as alternatives to services running their own accounts. Identity provider, Service provider, trust federation connecting them -- with policy and technical framework.

Trust federation requires identity providers to establish who there is and how we know about them; the identity provider joins the trust federation; a service provider joins the trust federation, and gives user attributes to determine access.

The MAMS testbed federation has 27 ID providers (900k identities), 28 service providers -- from repositories to wikis to forums. The core infrastructure, including WAYF (Where Are You From service), is already production quality. MAMS working on software to help deployment.

"AAF" (Australian Access Federation) is the legal framework; "Shibboleth Federation" is the technical framework: the fabric to realise the legal federation.

A Shibboleth federation does not require Shibboleth software: it only commits to Shibboleth data standards. Shibboleth software is the reference implementation, but there are others.

Principles for federation have been formulated and are available

Deployment models. Do allow partial deployment models. Requirement AAF Req14 has core and optional attributes, and identity providers can limit deployment at first to staff who will be known to use the federation, rather than blanket all staff. Could have separate directory for just that staff, with just their core attributes. Alternative: staff only deployment, or full staff identity records and partial student records.

Also facility for the federation to map between native and AAF attributes.

Shibboleth version 1 is most safe to use; Shibboleth version 2 can be used with due caution to interoperability. OpenID supports weaker trust than a proper education federation; it can be added to a Shibboleth Identity Provider as a plugin.

Service provider: need to connect the Shibboleth Service Provider software (or equivalent) to your software; then determine the required attributes for access. Could specify authentication protocol as attribute; service description contains one or more service offerings. Can use "People Picker" to nominate individuals rather than entire federation. Could specify other policies on top, e.g. fees; that's a non-technical arrangement.