What to look for when considering Edugate access to cloud or shared services

This guide is offers advice for departments from an HEI that are considering using Edugate as a means of access to a service provided by a non-member of Edugate. It assumes the HEI is already an Identity Member of Edugate (e.g. users at the institution can access the resources of other providers that are protected by Edugate).

Service provision for single-institution

Your institutions Edugate identity provider service can be used for authenticating users from your institution when accessing campus services hosted by third-parties off-site or in the cloud . The identity provider service can eliminate the duplication of usernames/passwords from the local username/password store to the service provider as it provides a single credential and single-sign-on. It is also much more secure solution, as the users existing campus password is only ever entered on the institution's campus login page (meaning the password never leaves the campus). Authorisation by role (e.g.. student/staff), by user or by group can be controlled at the institution or by the service provider.

The service provider can use your institutions Identity Provider service in one of two ways.

1. Using the Edugate Federation

In this scenario, the provider will join Edugate as an Associate Provider member, this means the technical (SAML) metadata describing their service will be added to the Edugate Metadata so that your institution will know how to interoperate with the providers service. It also allows the institution to use the Edugate Resource Registry to manage the metadata exchanged between both parties and to manage the exchange of user attributes without having to edit or reconfigure the institutions Edugate Identity Provider service. This arrangement also has the added benefit if HEAnet's Network Operations Center being available to assist in the event of any technical problems relating to federated access between the institution and the provider, it also provides a legal framework covering the exchange of user data (as described in the Edugate agreements). It is important to note that the providers membership of Edugate doesn't mean that all other institutions are entitled to use their service (the service provider can filter out all other institutions on their side).

What to ask the vendor for?

The vendor should be asked for if they support the SAML2 profile as described on SAML2int.org profile of SAML2. The vendor should also be asked if they can support remotely hosted SAML2 metadata in an automated way. Either in a format that contains multiple identity provider entities or a single entity. The vendor should be able to handle user attributes as described in the Edugate technical specification (or simply, the eduPerson attribute specification). The vendor should also be asked if the service will provision user accounts on-the-fly (using the attributes from the identity provider) or if accounts need to be provisioned in advance of the user accessing the service for the first time. Lastly, the vendor should be asked if they will be able to complete and the Edugate membership agreement and comply with its terms.

2. Bilaterally

A bilateral arrangement can be agreed between the institution and the service provider so that the service provider doesn't have to join Edugate  in order to provide federated access (thus avoiding the obligations that  Edugate membership brings). End users will not  However, the institutions IT department would have to make changes to the Edugate Identity Provider service locally to facilitate a bilateral setup, they will also have to provide the institutions identity provider metadata to the provider (and each time the metadata changes). HEAnet can only provide support for federated access within the Edugate federation, which means the local IT departments should be asked if they can facilitate a bilateral arrangement.

What to ask the vendor for?

The provider should be asked if they support SAML2 (or better, SAML2int.org), and user attributes of the eduPerson attribute schema or person, organizationalPerson, or inetOrgPerson schemas found in most campus LDAP directories. The vendor should also be asked if the service can provision user accounts on-the-fly (using the attributes from the identity provider) or if accounts need to be provisioned in advance of the user accessing the service for the first time

Shared-service or services for inter-institutional collaboration/alliances

The primary goal of Edugate is to provide an access platform for inter-institutional access. Departments or research groups that operate any web-based service that needs to authenticate users from the HEI sector will benefit from Edugate by avoiding the user account provisioning process and password management issues that are associated with accounts (users of the service will also benefit by not having to remember credentials for your service). The bilateral arrangement described above could be used, but it would need to be extended to a multilateral arrangement, and thus, each IT department from the HEI's that indented to access the shared service would be required to make changes to their campus identity provider service. However, this approach could be used if the provider was unable to comply with the terms of the Edugate agreement. Access via Edugate would not require any changes to the existing identity provider on campus, and the Edugate agreement would already cover most of the topics that require agreement between all-parties, management of the federation relationship between the provider and the HEI's using the providers service can be easily managed through the Edugate Resource Registry web-based management tool. The relationship would also be supported by the HEAnet NOC and subject to change management control.

What to ask the vendor for?

The vendor should be asked for if they support the SAML2 profile as described on SAML2int.org profile of SAML2. The vendor should also be asked if they can support remotely hosted SAML2 metadata in an automated way. Either in a format that contains multiple identity provider entities or a single entity. The vendor should be able to handle user attributes as described in the Edugate technical specification (or simply, the eduPerson attribute specification). The vendor should also be asked if the service will provision user accounts on-the-fly (using the attributes from the identity provider) or if accounts need to be provisioned in advance of the user accessing the service for the first time. Lastly, the vendor should be asked if they will be able to complete and the Edugate membership agreement and comply with its terms.

What if SAML support is not provided by the vendor?

Using REMOTE_USER

If the provider doesn't support SAML natively within their service, but does support 'external authentication' via the REMOTE_USER HTTP Server Variable (or similar). The addition of the Shibboleth Service Provider Plugin will allow SAML to be handled by the plugin, and the REMOTE_USER variable to be populated for subsequent use by the providers application. However, the web-server preferred by the provider would need to be compatible with Shibboleth (see Shibboleth downloads for compatible web-servers) and the provider of the service would need to support the Shibboleth plug-in as part of their offering. Other integration options are outlined in the Edugate Integration Guide for Service Providers).

Using Edugate as a self-service account provisioning engine.

Where SAML support is not available, and the REMOTE_USER option is not possible. Edugate can still be used as a self-service provisioning engine, this would require the vendor to create a registration page powered by Shibboleth (or equivalent) to provision the users application account, while the benefits of a single-credential and single-sign-on may be defeated in this scenario, the vendors will still have the ability to distinguish valid users from an institution  from the general public.