Athens-Federation Interoperability (Phase II)
The Federation Gateways have been designed as a solution to the need for institutions or Identity Providers (IdPs) and publishers or Service Providers (SPs) to be able to migrate to federated access management, whilst maintaining access to resources for all users. The Athens – Shibboleth Gateway allows Athens authenticated users to access Shibboleth protected resources, and the Shibboleth – Athens Gateway allows users authenticated by their home institution to access Athens protected resources. Both gateways will provide this service through the UK Access Management Federation.
The gateway development falls in to three phases:
||July 2004 -
|Funded as part of Athens development programme - Core Athens Grant|
Feb 2006 -
|Funded through JIIE grant|
||Nov 2006 -
|Funded through JIIE grant|
This plan covers phase II of the development
The scope of phase II is to take the prototype gateways developed in phase I and create robust, resilient and reliable gateway services ready for use within the UK Access Management Federation. All testing of the gateways will be achieved via membership of SDSS – the UK pilot federation service.
Gateway services, ready for full membership of the UK Access Management Federation.
Aims, Objectives and Scope
The aim of the project is to create robust, reliable and resilient Athens – Shibboleth and Shibboleth – Athens Gateway services, ready for the full membership of the UK Access Management Federation.
The objectives to support this aim are:
- Join the SDSS federation as both an IdP and SP to support primary gateway functionality
- Perform full code review, stress and performance testing of the Athens – Shibboleth and Shibboleth – Athens authentication processes through the external federation (SDSS)
- Establish a detailed maintenance programme for both gateways
- Establish project management and liaison with primary stakeholders (JISC, JANET, SDSS)
- Test the Gateway functionality with early adopter projects
The project will start in February 2006 in order to interact with Phase I of the development programme, and formally finish in August 2006 when the Gateways will be submitted for formal acceptance testing by an independent team appointed by JISC.
Design Specification: Athens – Shibboleth Gateway
The Athens to Shibboleth gateway allows Athens users (Classic or DA) to access Shibboleth protected services using their Athens credentials. The gateway is currently in early testing and supports the modified SAML1.1 profiles used by the Shibboleth 1.2 protocol.
This proposal is for the roll out of the Athens to Shibboleth gateway as a production level service, with the same performance and availability as the core Athens infrastructure. This will necessitate a full code review, stress and performance testing. A new server cluster (shared with the Shibboleth - Athens gateway) will be required to guarantee the performance and resilience across the whole distributed infrastructure.
A maintenance programme will be devised to ensure that bug fixes and maintenance releases can be scheduled alongside any other development work.
A development roadmap with the following enhancements is also under consideration:
- Support for the SAML1.1 Browser/Artifact profile.
- Support for Shibboleth 2 and other SAML2 service providers.
- Provision of virtual identity provider IDs, as requested by some Service Providers.
- Extended attribute sets.
- WS federation/trust service provider support.
- Statistics and logging services.
- MyAthens integration for Shibboleth services.
Shibboleth – Athens Gateway
The Shibboleth – Athens gateway (ShA gateway) enables Shibboleth Identity Providers (IdPs) to access Athens resources using Shibboleth for message exchange. The gateway exposes the Athens service as a Shibboleth Service Provider (SP), which is treated by an IdP in the same way as a conventional SP.
The ShA gateway currently implements the Shibboleth 1.2 protocol, based on SAML 1.1 and the Browser/POST profile for the transport of handle assertions. Additionally, the gateway supports the Browser/Artifact profile, but this is not a supported mode for Shibboleth IdPs (it is supported for use with the Novell iChain SAML extension, using SAML 1.0).
The gateway architecture supports pluggable authorisation policies to be applied to incoming user attribute information. We currently support 4 authorisation policies:
- Default resource allocation, based on organisation-wide entitlements. This is a minimal policy, which by definition is generous with entitlements. It is only typically used during integration testing.
- Permission-based resource allocation, based on a default permission set(s) administered through the Athens administration interface.
- Permission-based resource allocation, based on asserted permission set information, allocated by the organisational IdP, and administered through the Athens administration interface.
- Permission-based resource allocation, based on a default permission set(s), supplemented by asserted permission set information, allocated by the organisational IdP, and administered through the Athens administration interface.
The gateway will also implement a high-availability WAYF service to enable easy discovery of a user’s home organisation though a user-friendly web interface. This interface will incorporate a full-text search engine to search for an organisation, as well as a tree-based visual representation of organisations, based on categorisation by type and geographical location.
The gateway is currently implemented as part of the core Athens infrastructure and has been made available for several months now albeit that it has had very limited usage to date. To implement a full production service the gateway needs to be implemented on a new dedicated infrastructure (shared with the Athens to Shib gateway). Additional performance testing will be carried out to ensure the high availability and scalability of the service when integrated with a community wide Shibboleth federation.
There are a number of further enhancements proposed. These are ordered roughly in order of importance.
- Support for the Browser/Artifact profile. As mentioned above, we already support this for non-Shibboleth operation, using SAML 1.0. When the gateway was originally designed, the Shibboleth software only supported the Browser/POST profile. This changed with the Shibboleth 1.3 release. It would therefore be appropriate to support this in the gateway.
- Support for SAML 2.0. The upcoming Shibboleth 2.0 release will support SAML 2.0. Support for this in the gateway is therefore required as Shibboleth 2.0 will be a more attractive option for organisations who have a strong requirement to access Athens resources through the ShA gateway, when it is released.
- Tools to ease the migration from classic Athens to Shibboleth (through the gateway). Provide simple, streamlined mechanisms for users with existing Athens accounts to migrate to using an organisational login using Shibboleth and the gateway. This would enable an existing account to be attached to the Shibboleth login, while they are both in use by the user.
- Extensions to the WAYF service to interoperate with other WAYF services in different federations and additional of IP-based heuristics, and a Web Services interface.
- Support for a wider range of authorisation policies. The implementation of dynamic, attribute authorisation policies, based on an imbedded decision engine, perhaps utilising XACML.
The criteria against which the project will be measured are:
- Successful membership of the SDSS pilot federation as both IdP and SP;
- Successful acceptance testing by independent organisation appointed by JISC;
- Integration of gateways as an SLA under the JISC – Eduserv Framework agreement
It is recognised that JISC has also requested the following workpackages to be integrated in to the programme plan:
- write-up of the process of joining UK federation as an outsourced IDP;
- programme of work to convert non-gateway-compliant service providers;
- development programme of work to be included in the service specification for the gateways from November 2006;
- development of a service specification for the gateway approved by JISC Contracts Manager;
- formal gateway acceptance testing.
Eduserv will work with the JISC Programme Manager to integrate these areas in to the workplan.
Overall responsibility for development will lie with Edward Zedlewski, Deputy Chief Executive of Eduserv. email@example.com
Project work will be carried out by appropriate members of the Eduserv Athens Development team, and the Gateways will be specified as described in the Athens / Shibboleth Integration White Paper: http://www.athensams.net/local_auth/shibboleth/athens_ng_scoping_1.0.pdf.
Early Adopter users will be supported by the Eduserv Athens helpdesk, according to the usual service levels governing such support.