Skip to Content

Service Provider Integration Guide

There are two steps to becomming a Service Provider member of Edugate, the first step is the completion of the Edugate Agreement (see The second step is the technical implementation, service providers must support SAML2 access to their service. This may already be supported by the service providers web-server or web-application, where it is not the following options can be considered.

1. SAML Protected Proxy
Use of a web-server proxy service such as EZproxy or mod_proxy may be sufficient where the web-server also supports a SAML plug-in, in this scenario the proxy service is protected by a SAML plug-in (Shibboleth or otherwise), when the user has authenticated via the SAML plug-in the proxy service delivers the requested content. Note however, that in most cases the proxy service may not be able to transfer any SAML user data to the requested resource and thus features such as personalisation, or role based authorisation would not normally be possible.

2. Application integration with SAML
Many of the applications used in the academic sector already support SAML either natively or using a web-server plug-in. The Shibboleth web-site maintains a list of known web applications that can be integrated with Shibboleth, SimpleSAML also maintains a similar list (seeSimpleSAMLphp). Where the web application does not already support SAML or the proxy option is not suitable, adding support for SAML through application code can be achieved by either;

  • Invoking an API that implements the SAML protocol
  • Processing web-server variables set by a SAML plug-in
  • Implementing the SAML protocol directly in your code.
  • OpenID or OAuth gateway

1(a) SAML API libraries.

1(b) SAML Webserver Plugin

  • Relying upon web server variables is an option if there is a SAML plug-in (Shibboleth or otherwise) for your web-server. In this scenario the SAML plug-in acts passively by invoking SAML authentication when a specific URL is clicked and setting server variables (or headers) that are populated as a result of the authentication phase. Theses variables can then be extracted by standard application code for custom authorisation and personalisation purposes. Some applications may support the standard header variable REMOTE_USER, if your SAML Plugin can set this header it may be possible to integrate SAML into your application without any further application code. There are a number of web-server plugins that can enable SAML access to the web-server, these are divided here into open source or commercial implementations.
  • Open Source
  • Shibboleth ('Service Provider' for Apache/IIS/Java)**
  • CAS (for Apache)
  • Guanxi (for Java)
  • ZXID
  • Forgerock OpenAM*
  • JBoss Picketlink
  • SimpleSAMLphp**
  • Commercial
  • Microsoft Active Directory Federation Services**
  • Ping Federate
  • Tivoli Federated Identity Manager**
  • Oracle Identity Federation
  • Novell Access Manager 
  • Entrust Identity Guard
  • Entrouvert Larpe
  • Netweaver IDM
  • RSA Federated Identity Manager
  • NTT Federation Manager
  • Ubilogin
  • Symlabs Federated Identity suite
  • Eduserv OpenAthens SP

* These products are known to be interoperable with Edugate.
**HEAnet have experience integrating these products

1(c) Implementing SAML natively in your code

  • If your web application cannot be integrated using third party code, applications/plugins or proxies then implementing SAML natively in your own code will be your only option, as with any protocol specification some parts of the protocol remain unspecified. However, the sub-specification will significantly reduce the development effort by elliminating protocol features that Edugate does not use and by clarifying many of the areas where the protocol specification is unclear.

1(d). OpenID or OAuth bridge

  • SimpleSAMLphp, and possibly other products as outlined above, can be configured as a gateway or bridge between a SAML identity provider and an OpenID/OAuth Relying Party. This may be useful if your application already supports OpenID or OAut


Usage Models
There are two common approaches to using Edugate, the first uses Edugate for one-time verification, this is often used by providers of student-discount. The second approach is more suited where the user will login to the service frequently or where the provider wishes to avoid issuing credentials to end-users.

One-time verification model

Service providers may use the federation for one-time verification which allows service providers to verify the identity and/or affiliations of a user so that the provider can provision a local user account for the users of the service. This allows the service provider to retain control over the user accounts it issues and may lessen the burden of integrating federated access into the service. The same scenario can be used at a later date to reconnect users with forgotten accounts or to provide a self-service password reset feature. Service Providers should bear in mind that a second credential may lead to high attrition rates due to the inconvenience of having to login using a set of credentials that has to be remembered. Service Providers that intend on using Edugate for one-time verification may find that the pseudononymous attribute 'eduPersonTargetedID' and role attribute 'eduPersonScopedAffiliation' particularly useful. A student’s affiliation may change during the academic term and should be revalidated at least once a year.

Single-Sign-On model
Using Edugate for Single-Sign-On can remove the need for service providers to maintain user credentials whilst providing a very convenient feature to users. Service providers may be able to avoid account management entirely for federated users if they find that Edugate and its members provide sufficient data so as to enable personalisation, authorization and persistence. Service Providers may still have to permit access to users who are not from an Edugate participating institution, a SAML bridge can be used to allow users login to the service using a social identity (e.g. Facebook, Twitter, Google, Yahoo! or LinkedIn). An example of this bridge can be seen at the LIR website (select 'Login' and then select the Social Login option. A bridge will present your application with a standard user object, regardless of whether the user his/her institution identity service or a social identity.

WAYF/Discovery Service Considerations.
When adding SAML support for services that will be accessed by more than one home organisation/institution a choice will need to be made on whether to use the Edugate central WAYF/Discovery Service or to develop similar functionality within the application code. Service Providers are advised to follow the best practice guidance at The Edugate centralised WAYF should be used as a last resort as it introduces an external dependency and can confuse users when logging in (as the look and feel of the WAYF website will be different from your website). Another important feature that your code should support is the automatic processing of frequent changes of digitally signed, remotely hosted metadata as the identity providers details that your application may be required to support may change frequently (e.g new webserver, new certificates etc).

Developer Resources.
A test identity provider service is provided, this can be used to test the login process to your service provider during development. The test identity provider log file can be viewed online, it shows the SAML authentiation reqeusts that were received from your SP, and the SAML responses that were returned. To register for an account on the test identity provider visit

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.

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)

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.