Testbed federation

MAMS is building a prototype federated Identity and Access Management (IAM) infrastructure for Australia's Higher Education (HE) sector. This infrastructure consists of Identity Providers (IdP) and Service Providers (SP) which trust each other, and the Federation to manage the trust between all parties. As a result, when a user wants to access a protected service at an external SP, instead of creating new guest accounts for external users, it allows an SP to leverage the user's account with his or her home institution to access it. In other words, the SP will receive all necessary user attributes from his or her IdP, which it trusts, and those attributes will determine the privileges a user gets at the SP. Below, we will try to answer some questions you might have.

What is MAMS? The Meta Access Management System Project (MAMS) at Macquarie University's E-Learning Center (MELCOE) is a three-year $4.2 million project sponsored by Australia's Department of Education Science and Training (DEST) as part of "Backing Australia's Ability" program. The project allows for the integration of multiple solutions to managing authentication, authorisation and identities, together with common services for digital rights, search services and metadata management. The project provides a 'middleware' component to increase the efficiency and effectiveness of Australia's Higher Eduction research infrastructure. What is the MAMS Testbed Federation? Our Federation allows Single Sign-On between institutions, so users can leverage their home institution's account to get access to another trusted institution's services. The MAMS Federation is the first Australian federation setup by the MAMS project, employing and building upon Internet2's Shibboleth technology. It uses SAML, the Security Assertion Markup Language, for asserting user attributes from the user's home institution's identity provider (IdP) to a service provider (SP). These attributes can be used for authorization which creates a trusted relationship between organizations. MAMS adopted Shibboleth's core Federation Trust principle and operates under Shibboleth 1.3. Joining the MAMS Federation will reduce the need for students, post graduate researchers, librarians and staff to maintain multiple accounts to access resources with various universities or organizations. What is a typical usage scenario? A typical use case of a user accessing a federated service goes as follows: Using a browser, the user attempts to access the service provider (SP) in the federation. As the SP does not know the user, she is redirected (using a HTTP302 redirect message) to the Federation's Where Are You From (WAYF) page. The Federation's WAYF asks the user where she is from, and she selects her preferred IdP (typically her home institution) from the list. She is then redirected to her IdP, which asks her to login if she hasn't already done so. Based on the target SP, which is conveyed to the IdP as part of the redirection, the IdP (after checking whether it can trust this SP) generates a SAML handle (an opaque identifier associated with her identity) and redirects her back to the SP with this handle. The SP, after extracting the handle, uses it to query the IdP about the user's attributes. The IdP sends some of the user's attributes (like role, email, affiliation) back to the SP, according to an attribute release policy (ARP), in a signed SAML assertion statement. Note that the ARP is controllable by the user and IdP system administrator. Based on the attributes, the SP gives certain access rights to the user and commences an authenticated session. Note that, in order to maintain transport security, all traffic uses SSL/TLS encryption. As a result, proper certificates are required when operating within the Testbed Federation. Types of Federation memberships? MAMS will deploy three levels of Federation membership by the end of 2006. Currently only Level 1 and Level 2 have been deployed; Level 3 Federation will be activated once the legal framework has been established. Level 1: Setup for testing and demonstration purposes. An IdP should not be trusted to assert anything truthfully about its users, nor should the SP be trusted to offer any valuable services. Any organization or individual can join Level 1 as an IdP either by using the MAMS Easy Install CD, or register and enter the details of their Shibboleth IdP that they have manually installed. Joining as an SP can only be done manually as there is yet no MAMS Easy Install CD for the SP. A Level 1 Certificate Authority has been setup as a quick and cheap method for issuing certificates needed by Shibboleth for entities in this Testbed Federation level. As a member of Level 1, they can easily upgrade themselves to the next level, by logging in to the Federation Management site using the password that was mailed to them earlier. Once inside, they can edit their IdP or SP and request that it be upgraded to a different level. Once their request, subjected to verification, has been approved, the details of their IdP and/or SP will be published in the metadata that is distributed to members belonging to higher Testbed Federation levels. Level 2: Membership in Level 2 means that an insitution wishes to offer actual services and/or act as an IdP to actual members within their organization. Due to the higher security requirements, manual verification of the organization wishing to join needs to be made. Furthermore, their sites would need proper commercial ceritifcates; certficates issued by Level 1 CA would not be accepted. An organization can request to join Level 2 by login in and modify their IdP and/or SP details. A member of the MAMS Testbed Federation administrators will then contact them to verify their details and check that all requirements have been met. Once approved, their details will be published in the Level 2 metadata. Level 3: From a technical point of view, it is identical to Level 2. Additionally, there will be a legal agreement binding the parties to the Federation (similar to InCommon in the US). What does an Identity Provider (IdP) do? Allow SSO, within the institution and federation. Maintain user attributes while protecting privacy. Know the SPs in the federation, so they only send user attributes to trusted SPs; and can format these attributes in a way the SP expects. Allow system administrators and individual users to control the attribute release. What does a Service Provider (SP) do? Control access to service (who can access what) based on the attributes received from an IdP, i.e. they implement attribute-based access control. Know the IdP in the federation, so they only accept user assertions from trusted IdP. What does a Federation do? Manages the metadata for the trust relationships between IdP and SP in the federation. Offers additional services, like a Where Are You From service (WAYF), which allows users to select their IdP.