Overview Edugate is an implementation of Federated Access, it works by a service provider and an identity provider agreeing a basis of trust between them, this trust is partly managed by the HEAnet, the operator of Edugate. The identity provider authenticates their users credentials and then provide basic user details to service providers. The service provider then decides what level of access the visitor is entitled to based on the users details.
A good overview of federated access can be obtained by watching the 5 minute video provided by JISC Access Management
The diagram and accompanying steps outlined below explain the flow of events that enable federated access.
- User open his/her browser and requests the Service Providers (SP) website, when the website loads the user clicks a 'Login' link.
- .The service provider redirects the user to a Discovery or WAYF (Where Are You From) web-site, this web-site may be the service providers own web-site or the Edugate shared WAYF website (http://wayf.edugate.ie).
- The WAYF/Discovery service sends a list of participating Edugate Identity Providers (institutions) to the users browser, the user selects his/her institution from the list.
- The WAYF/Discovery redirects the user back to the SP including the details of users institution.
- Now the the SP knows where the user is from, it redirects the user to the users institutional identity provider (IdP) website, where the IdP will prompt for the users institutional credentials (only if the user does not already have a web-session at the IdP), the user will enter his/her credentials which will be checked against the institutional user repository (step 6).
- If the credentials are verified, the IdP will fetch user information* from the institutions repositories and present an invisible HTML Form that will be pre-populated with encrypted user information. The form is automatically submitted** by the browser to a location on the SP's website.
- The data* will be decrypted, and used to create an authorised session between the user and the SP. Optionally, the data will be used to create a persistent SP user account (session) or match a user to existing/stored user account (or session), the SP may also present a 'terms of service','privacy policy', prompt for 'consent' for further processing of the data received
- All subsequent requests by the user are handled by the service provider hereafter.
*The data may vary from an opaque identifier known only to the IdP and SP to the full set of data as described in the Edugate Technical Specification.
**The user may be prompted for consent by the IdP before the data is sent to the SP, in which case the users consent will be recorded in a database.
NOTE: Steps 1-4 can be skipped by the SP in any of the following cases;
a) the SP web-site is used by only one institution, in which case the SP can redirect users back to the IdP.
b) the SP users some other means to determine where the user is from (IP address ranges, etc.)
c) the SP has dedicated 'login links' on it's website for the IdP's it works with (only works if the list is relatively static)
d) the SP is able to handle IdP initiated SSO, or unsolicited authentication responses, generated by IdP's with that functionality
| Attachment | Size |
|---|---|
| HowEdugateWorks.gif | 23.56 KB |
| HowEdugateWorksLG.jpg | 37.72 KB |


