Membership

Join the current members [2] of the Edugate federation by completing the membership forms below;

• Higher Education Institutions who wish to enable their members to access services in the Edugate federation should complete the Edugate Identity Member Agreement (see below) and (return it to the address below). This will complete the administrative step and allow HEAnet to complete or assist in the technical deployment [3] of the institutions Edugate Identity Provider Service.

• Higher Education Institutions (or departments, groups therein) or consortia from Higher Education Institutions, who wish to enable Edugate login to their services should complete the Edugate Provider Member Agreement (return it to the address below).

• Organisations who provide online services that are of benefit to the education and research of the members of the Higher Education sector should complete the Edugate Associate Provider Contract.

Agreements should be posted to;

Edugate Operator
HEAnet Ltd.
5 Georges Dock
Irish Financial Services Centre
Dublin 1
Ireland 
 
The Edugate test federation may be used to test or trial Edugate federated access without completing the membership agreements. Requests to join the test federation should be sent to noc@heanet.ie [4]. The current members of the test federation are listed  here [5]

How Edugate Works

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 [9]

The diagram and accompanying steps outlined below explain the flow of events that enable federated access.

[10]

1. User open his/her browser and requests the Service Providers (SP) website, when the website loads the user clicks a 'Login' link.
2. The SP will present a the user with a Discovery or WAYF (Where Are You From), this  may be the service providers own web-site or the Edugate shared WAYF website (http://wayf.heanet.ie [11]) and it displays a list of participating Edugate Identity Providers (institutions) to the users browser, the user selects his/her institution from the list.
3. The WAYF/Discovery redirects the user back to the SP including the details of users institution.
4. 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).
5. 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.
6. 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
7. 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 that institutions IdP.

b) the SP uses some other means to determine where the user is from (IP address range, cookie domain etc.)

c) the SP has 'WAYFless URL' that can be customised for each institutions IdP

d) the SP is able to respond to IdP initiated SSO, or unsolicited authentication responses.

Identity Federations

Edugate is a local instance of a globbal initiative

• Austria, ACOnet-AAI [12]
• Australia, Australian Access Federation AAF [13]
• Brazil, CAFe [14]
• Canada, Canadian Access Federation CAF [15]
• China, CARSI [16]
• Croatia, AAI@EduHr [17]
• Czechoslovakia, eduID.cz [18]
• Denmark, WAYF [19]
• Finland, Haka [20]
• France, Fédération Éducation-Recherche [21]
• Germany, DFN-AAI [22]
• Greece, GRNET [23]
• Hungary, eduID.hu (HREF Federation) [24]
• Ireland, Edugate [25]
• Italy, IDEM [26]
• Japan, GakuNin [27]
• Latvia, LAIFE [28]
• Netherlands, SURFnet [29]
• Norway, FEIDE [30]
• New Zealand, Tuakiri New Zealand Access Federation [31]
• Portugal, RCTSaai [32]
• Slovenia, SIArnesAAI Slovenska izobraževalno raziskovalna federacija [33]
• Sweden, SWAMID [34]
• Spain, SIR [35]
• Switzerland, SWITCHaai [36]
• Turkey, ULAKAAI [37]
• UK, UK Access Management Federation for Education and Research [38]
• US, InCommon [39]

Source: www.refeds.org [40]

Who is Edugate for?

Edugate is for the Irish Higher Education Community, it can be used in multple situations as outlined below;

Edugate FAQ

• I'm the IT manager for my institution, what services will my users have access to through Edugate?

You can use Edugate to provide Single-Sign-On (SSO) to Edugate participating services, your own internal services and services other external services. Some services require a subscription with the provider.

• As a service provider, do I still have to provision user accounts in advance?

In most cases, no, as many services support account provisioning on-the-fly (or 'just-in-time provisioning'). Provisioning on-the-fly creates accounts using the incoming user data provided by the institution when the user logs in. Only where the incoming data does not provide sufficient detail should bulk account provisioning still be necessary. Edugate can provide user, institution and role data that can be used to provision accounts on-the-fly.

• Must I be a member of Edugate to use federated access?

No, you can agree bilateral or multi-lateral federated access agreements with organisations you trust outside of any federation. However, this approach will become unmanageable once the number of applications begins to increase and will result increased effort for your organisation.

• Can I be a member of more than one federation?

Yes, however, being a member of more than one federation will increase the effort required to manage your federation software. It is recommended that institutions should first check if the federation you are a member of has any plans to join an interfederation scheme (such as that provided by eduGAIN [43]) before joining a second federation.

• Can I use Edugate within my organisation? 

Yes, Edugate can be used to deliver SSO within the organisation. Organisations that use Edugate internally as their SSO solution or use similar federated access without being a member Edugate. Using Edugate internally can enable applications to share user data between applications while at the same time reusing the same credentials and sessions. Access control decisions can be easily defined to allow easy selection of which applications are open to external access by other federation members users.

• Can I replace my existing SSO solution with Edugate?

​Yes, as explained above Edugate can provide internal SSO to your users. However, there may still be specific cases where your existing SSO solution may be a better fit than federated applications. Organisations who wish to replace their existing SSO solution with Edugate should plan an application-by-application migration strategy and use the same user repository for SSO and Edugate.

• Can I integrate Edugate with my existing SSO solution? 

Yes, in fact some SSO products (such as CA Siteminder, Tivoli Access Manager and Sun Access Manager) can be easily integrated with Edugate, others can be integrated using the SSO solutions API and a certain amount of customisation. In either case there are there are two integration possibilities to integrate Edugate with your SSO solution. Firstly, as a service provider (SP) you should create an access control rule (ACL)in your SSO solution for external users who will access the applications you decide should be accessible externally. Your federated access software should request external users to authenticate using the home credentials and then authorise the user based on the users attributes, when this has been successful your SSO solution should then issue a SSO session token or cookie (using the ACL described above) that can then be reused on any SSO protected application. Getting your SSO solution to trust an Edugate session may be trivial or difficult depending on your SSO solution, but the benefit of not having to retrofit Edugate to all of your SSO enabled applications will make any effort worth it. The second option is to make your SSO authentication system issue an Edugate session so that when your users visit other organisations protected resources they are not prompted to authenticate. Again, the degree of integration effort will vary, but the benefit here is that your users experience a seamless login to external resources and will need to familiarise themselves with the SSO login screen only. A variant of this solution is to use the same user repository for Edugate that your SSO solution uses, but this will more than likely mean that the user will be prompted for login on a screen different to your current SSO solution.

• Can I use Edugate in parallel with my SSO solution?

​Yes, rather than integrating your SSO and Edugate as described above, you can run both solutions in parallel. You should use Edugate with applications that will be accessed internally and externally and use SSO on applications that will be used internally only. Another consideration is your applications native support for SSO or federated access, applications that will be accessed internally only may offer better native support for Edugate than SSO, in these cases you should choose to use federated access over SSO (in other words if your SSO solution requires you to significantly customise your application you should investigate how much customisation is needed for Edugate before deciding).

• Which of my campus resources should I enable Edugate access to? 

You should enable Edugate on any of your resources that will be accessed by users who belong to another organisation and if the service is hosted off-campus and requires user authentication.

• If authorisation to resources is based on user attributes, does that mean I will have to modify the schema of our student repository?

In almost all cases, the answer is 'No'. Most federated access software allows identity providers to map attribute names from the schema of the user repository to the federation schema, this mapping can be as simple as a one to one mapping or more complex. Where mapping is not possible, the existing campus schema can be extended rather than amended to support the Edugate schema. 

• The Edugate schema does not contain enough data to fit my needs, what options do I have?

There are two options, you can agree to extend the schema with the co-operation of selected Edugate identity providers or your can synchronise the missing data outside of Edugate (Edugate can still be used for Single-Sign-On purposes).

• Users at our institution have a frequently used faculty credentials and less frequently used institution credentials, which should credentials should we use for our Identity Provider?

Firstly, you should consider using Edugate or SSO internally to help you consolidate on a single user repository. If this is not feasible, you should have two choices, you can either use the single institutional repository or configure your identity provider software to query all your faculty repositories. Using multiple repositories is a practical option when there is no overlap on user id's between repositories, otherwise it becomes difficult to define queries to simulate uniqueness.