Skip to Content

Guide for HEI departments considering Edugate access to cloud/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.

Who is Edugate for?

Edugate provides a single access mechanism that can enable access to online resources supporting alliances, research collaboration, consortia and shared services. Now users can use the credentials issued by their institution to access Edugate enabled web-sites and benefit from a personalised and persistent experience, with privacy features that put the user in control.

Enable users to use the campus directory credential to access Edugate enabled web sites beyond the campus boundary from anywhere, whilst protecting the campus directory from unnecessary searches and the user credentials from use on web sites beyond your control. 
 

Your patrons are individuals, not IP Addresses!
 
Enable publishers to provide users with a consistent and personalised experience regardless of their location or the device they are using.
Improve the end-user experience by providing Single-Sign-On and reducing the frequency of prompts for campus credentials.
Connect your patrons to your subscribed resources, regardless of where the user performs their search.

Restrict access to your club or society web-site to valid campus users without needing the campus IT department to provide you with access to the entire campus user database.
For student unions, Edugate enables online elections that can authenticate all students currently enrolled without needing to expose campus credentials or personal information.

Example: UL Students Union

Provide your suppliers with a means to interact with all campus members. Whether its parking management, physical access management, catering or sports facilities, Edugate can provide a secure means to validate staff and student status. Access cards or tokens can be issued online in a self-service manner, removing the some, if not all, of the paperwork.

Example: Apcoa Parking Management

When establishing any online service that will be used by multiple institutions, Edugate will provide a means to authorise access to the service by user, role or institution without having to issue usernames/passwords or other credentials to the users of the service.
Most research projects are collaborations and when it comes to hosting collaborative tools or sharing documents and data, Edugate enables the hosting partner to seamlessly grant access to the project content.

Example: NDLR Repository
Example: HEAR and DARE

Campus IT managers and IT security officers are increasingly reluctant to synchronise user credentials or open up campus directory services to applications that are hosted in the cloud. Even locally hosted managed applications that require the campus credential to be processed by the application present a security risk. Edugate is built on the open SAML federated access standard that is used in the financial services, aerospace and governmant eID and provides Single-Sign-On without the risks.

e-Government
Whether it's a central or local government service that needs to validate that a student is a current student, Edugate can open up the potential for numerous e-Government services for students (e.g. Grants and Tax Credits)

e-Commerce
When offering a student discount online, relying on a campus email address leaves the offer open to abuse since many institutions offer 'email for life'. Edugate will allow you to know if a customer is a current student and which institution the customer is affiliated to.