The Edugate federation is comprised of Irish Higher Education Institutions and Research Organisations that have agreed upon a standard procedure for exchanging information about users and resources to enable access and use of those resources and services. The Edugate federation is a service operated by HEAnet in co-operation with HEAnet client institutions 
Join the current members  of the Edugate federation by completing the Edugate Agreement below;
Agreements should be posted to;
5 Georges Dock
Irish Financial Services Centre
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 firstname.lastname@example.org . The current members of the test federation are listed here 
|EDUGATE RULES.docx ||67.48 KB|
|EDUGATE AGREEMENT.odt ||36.77 KB|
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.
*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.
Edugate is a local instance of a globbal initiative
Source: www.refeds.org 
Edugate is for the Irish Higher Education Community, it can be used in multple situations as outlined below;
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.
Eliminate the need for sharing the entire campus population of userid's in bulk form with other campus departments by offering an authentication service that is highly secure and only shares the necessary amount of users data for the minimum set of users.
Reduce multiple account stores by leveraging the time and effort your department has invested in the campus directory. Significant helpdesk cost savings can be realised by reducing the number of credentials that are issued for each user. [Gartner estimates that a typical user calls their help desk 16 times per year, with a quarter of those calls related to password reset issues, each of these calls last an average of 42 minutes]
Consolidate user accounts onto on a single campus directory, users will remember their credentials thus allowing for stronger credential controls (e.g two-factor authentication or strong password policies).
Improve the productivity of campus users by eliminating multiple account provisioning processes and leveraging the single-sign-on capability of Edugate. [ Meta Group estimates that the elapsed time for a user account provisioning request can take anywhere between 6 and 29 hours, resulting in a 36% loss of productivity and 26% loss of efficiency] Many of the cloud service providers offering Software as a Service (SaaS) support federated access that is compatible with Edugate. Avail of such services in a more secure manner by ensuring user credentials never leave the campus.
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. The Cloud Security Alliance is an alliance of well known organisations in the ICT sector, they recommend SAML as the preferred access mechanism (see their white paper at www.clouldsecurtiyalliance.org )
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
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.
Further details for libraries... 
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
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.
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
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.
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.
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.
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.
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 ) before joining a second federation.
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.
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.
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.
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).
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.
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.
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).
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.