The purpose of this page is to assemble content for the eduTEAMS site on the GÉANT public website.
About eduTEAMS
Academic research has always been characterized by intense collaborations between people and groups from different institutions. Modern IT and especially IT networks have transformed the form of these collaborations: researchers can access and share data remotely, they can access online resources such as journals or scientific instruments.
In this context, Authentication and Authorisation Infrastructures (AAI) have been developed to regulate who can gain access to which resources. Federated identity and eduGAIN go a long way to enabling such access policies for single users or research groups belonging to the same institutions. Thanks to single-sign-on they have built a scalable environment.
When they originate from researchers in different countries and institutions, research collaborations sometimes need additional specialised infrastructure so that they benefit from the same benefits in terms of AAI. eduTEAMS is being built on top of eduGAIN to address this need. eduTEAMS aims to simplify the management of group and authorisation information. It aims to enable the integration users from a wide range of environment, connecting them to specific services (such as instruments), and also to other generic services such as storage and compute provided by any eInfrastructure provider or even commercial entity. Just like Identity Federations and eduGAIN, eduTEAMS aims at scalability and give this possibility of integration for services provided by any eInfrastructure, Research Infrastructure or long tail simple collaboration.
In order to meet these needs, eduTEAMS is being designed and piloted by GÉANT in two variants which will be deployed and evaluated in two successive phases:
Phases 1: Basic service:
- includes Membership management, Identity Hub for non eduGAIN users, Basic Groups, and Basic Provisioning
- allows end users of eduGAIN members to be able to login
- has infrastructure operation provided by GÉANT
- is offered to users at no additional cost
Phase 2: Advanced service:
- includes the same features as the basic offering, plus Advanced Groups, Attribute Management, Advanced (de-)Provisioning, SP proxy, Attribute Aggregation
- Is private to eScience community operators and end users authorised by them
- Includes operations and consultancy provided by GÉANT
- Is offered on the basis of a per community contract and cost
<Suggested graphic - something wooshy connecting groups of people to information>
Who benefits from eduTEAMS
eduTEAMS is intended to help research collaborations manage access to their services where there are users in multiple institutions or countries, and where access toe services also depends on an individual's role or status within a collaboration.
- The collaboration gets the benefits of federated identity management for authorisation by integrating with eduGAIN, plus the benefits of a persistent identifier for a user that is specific to a collaboration.
- The collaboration gets the benefits of being able to work with researchers outside the footprint of eduGAIN e.g. using a social ID, without that ID being directly connected to a given service.
eduTEAMS supports XXX of the features identified in by the FIM4R Federated Identity Management for Research Group as key for research collaboration
<Show that chart that i remember exists in one of NvDs presentations but can't find>
eduTEAMS also benefits end users by allowing them to use their home organisation credentials to access services outside their campus in a privacy preserving, secure way.
eduTEAMS benefits national identity federations by enabling their infrastructures to more easily serve complex federated authorization needs without increasing individual national investment.
Why use eduTEAMS
eduTEAMS offers a jump-start to for international collaborations consisting of people (i.e. researchers) that would like to securely and easily work together using online collaboration tools. Find below an overview of the situation where a research community relies on eduTEAMS with federated login compared to a research community not relying on federated login:
Research Community Perspective
| Criteria | Without eduTEAMS | With eduTEAMS |
|---|---|---|
Account Provisioning | Accounts have to be created for each member of the research community, which requires collecting name, addresses, etc. beforehand. Keeping the user data up-to-date will required to periodically ask the users or their organisations for any changes, which is a unreliable and cumbersome process that will likely result in stale and inaccurate data within a few months. | Creating accounts on eduTEAMS Member Registration service can be as easy as having a list of email addresses with which participants are invited. Thanks to federated login via eduGAIN, accounts (incl. name, organisation and more) can automatically be created upon first login. Up-to-data user data from the user's home organisation is available on every consecutive login at a service, which easily allows service to always the the most up-to-data data. |
| Identity Management | Keeping identities/accounts up-to-date has to be done by research community on its own, depending on architecture even multiple times on every application that is used collaboratively. | Identity management is done by users home organization or - in case the user uses the eduTEAMS Identity Hub - the the user himself. It's in the user's home organisation self-interest to keep data as up-to-date as possible and the same is true for the users or that organisation. They also have a high interest to keep their identity data up-to-date because they for example want their name spelled properly on diplomas or staff insurance documents. |
Credential Management | Credentials (passwords) have to be created, properly protected, securely distributed and reset by a research community on their own. | Credential management is entirely done by user's home organisation (i.e. university), which has a high self-interest to do a good job there because the same user account used to access eduGAIN services like eduTEAMS is also used by the users to access organisation-internal services like student enrollment or sensitive internal staff web services. |
| Implementation Time | Designing an robust and scalable architecture to facilitate online collaboration within a research community takes quite some time and experience. Often research communities are good at their field of research but less knowledgeable when it comes to design, develop and operate IT architectures. Therefore, doing this on their own, a research community might need quite a lot of time that it typically does not have in case the research project lasts only for few years and researches would like to start working together right from day one of the project start. | With eduTEAMS a research community can rely on a solution that was designed by experts in their area who have several years of experience and who have helped build the underlying infrastructures (e.g. eduGAIN) and software (SaToSa, Discovery Service). Relying on this knowledge and the already available infrastructure that was custom-tailored for the needs of research communities saves a considerable amount of time. |
| Scalability | Adding more applications to be used in research community in the worst case requires managing yet another set of identities or it will require this application to be connected to the central user directory of the research community, which might be easy to do but will require users to enter their password yet on another web service. Also, collaborating with users from other research communities and maybe accessing their web applications is not easy to configure. | Adding an additional web application to a set of applications used by a research community is relatively easy and scales well. Collaborating with users from another research community (e.g. to grant them access or get granted access on a shared application) is relatively trivial as each service can define its access control independently and in a very flexible but powerful way if one of the popular SAML implementations is used. |
| Costs | Deploying an own solution to enhance collaboration in a research community might seem very easy, just set up a wiki or some other open source tool and start collaborating. Starting small and simple is fine for only a hand full of people and very few services. The more people and services that have to collaborate, the more know how and work is needed to operate the services properly. This is costly and finding qualified staff to do this is difficult. It then might be tempting to outsource operation to an external company or use a free service (e.g. Google Apps). Both options have disadvantages when it comes to vendor lock-in and data privacy issues. Also, commercial services often custom-tailor their services for businesses that work differently than a research community and the larger the company the less they might be interested to add changes for their offering to make it more attractive for research communities. | eduTEAMS envisages a freemium model where the eduTEAMS Basic version is free for all research communities to try and use and the eduTEAMS Advanced version will then cost a bit, which is also to ensure its sustainability and further development in the long term. eduTEAMS is operated by GÉANT, a non-for-profit organisations which is owned and controlled by the European National Research and Education Networks (NRENs) that themselves are owned and/or controlled by the universities and research institutes in their respective countries or the governements. Therefore, offering services to education and research is GÉANT's main purpose.
|
Service Operator Perspective
| Criteria | Without eduTEAMS | With eduTEAMS |
|---|---|---|
| Effort for Deployment | Initially, little deployment effort is needed for an application that already contains an own user management and access control mechanisms. In the long term, if multiple applications are used by a research community, deployment efforts are still slightly smaller than with eduTEAMS but identity management becomes a much greater scalibility bottleneck as is written below. | Moderate for the first time because an OAuth implementation or a SAML Service Provider has to be deployed (and potential code to access group information via VOOT). |
| Identity Management | Either done by the research community as a whole (see above) or has to be all done by service operator in case the application's own user management is used. In the later case, this can be quite some effort to do properly for more than a hand full of users. | Not needed, done by the user's home organisation (i.e. university, research institute). |
| Data Quality | Degrading quickly after user account was provisioned by research community | Personal user attributes are released by user's home organisation (e.g. university) that has a good interest to keep data up-to-date |
| Access Control | Unless a shared user directory is used, access control rules have to be defined per service per user, which is quite some effort and needs frequent adaptations | Easy to define access control/authorization rules based on group membership data |
| Security | User has to authenticate at each service with his credentials. The more services are used, the higher the risk that one of the services is compromised and thus the user credentials are compromised | Service never gets users credentials. Even if service is compromised, the user credentials are not affected by this, only the user's data on this service. |
User Perspective
| Criteria | Without eduTEAMS | With eduTEAMS |
|---|---|---|
| Ease of Use |
|
|
| Security | Credential (i.e. password) has to be entered on every service, which increases the risk of entering the password on a compromised service | Credential is provided on one login page only, the one of the user's home organization or (in case of the eduTEAMS Identity Hub) on a social network provider (i.e. Facebook or Google) |
How is eduTEAMS different from e-Infrastructures like EUDAT, EGI, INDIGO DataCloud, ...
(Work in progress, has yet to be reviewed/verified)
- eduTEAMS consists of a set of services that are all fully relying on eduGAIN
There is not a single eduTEAMS service but multiple independent but harmonized services including:- The eduTEAMS Identity Hub, an Identity Provider for users without federated login
- eduTEAMS Member Registration, a platform that allows managing groups and processes
- eduTEAMS Discovery Service, a service that allows one to easily custom-tailor the list of organisations that users can choose from to log in
- eduTEAMS allows to easily connect own web services to the Member Registration attribute authority service
Services can consume authorization information (e.g. group membership) for access control.
Multiple protocols can be used to access authorisation information (e.g. SAML via AttributeQueries, VOOT, Oauth). - eduTEAMS was created and is operated by the people who created eduGAIN
The experts who created eduTEAMS also helped create the national identity federations and eduGAIN. - eduTEAMS is a generic collaboration management service
Some e-Infrastructures were created with a particular research community in mind or for a specific purpose. Therefore, some of them are custom tailored to a particular research community's needs and requirements, which might be limiting for others. Some e-Infrastructures offer way more features than eduTEAMS but this comes at the cost of complexity.
eduTEAMS was created from the ground up as a generic collaboration service for small to medium-sized research communities.
How eduTEAMS Works
The Basic eduTEAMS service combines work flow components provided by COmanage with a SAML Attribute Authority, the VOOT Protocol and Oauth in order to provide information to the service provider to make an authorisation decision. It also provides a choice of authentication possibilities, from a classic federated Identity Provider within eduGAIN to a social identity such as a Google ID via the Identity Hub.
COmanage delivers the VO Membership service which features:
- a registry for research collaboration persistent Identifier
- research collaboration specific Workflows for onboarding
- a limited set of custom attributes
- access through eduGAIN IdPs & Identity Hub
The SAML Attribute Authority implements the SAML attribute Query protocol which...? What does the SAML AA do exactly?
The VOOT Attribute Authority is a RESTfull, OAuth2 shielded resource providing group and attribute information stored in the <which?> using the VOOT protocol towards the Service Provider.
The Identity Hub proxies multiple external identity providers to one single persistent SAML2 IdP. This allows research collaborations to use one endpoint for all Guest/External Id scenarios, while at the same time allowing the endusers to choose the service they prefer.
All these components are packaged and presented as a unified service to the research collaboration.
From the perspective of an example use case, the operator of the research collaboration uses the membership management facility delivered by COmanage in order to on-board participants and assign them roles in particular groups. (. (What does Oauth do?). When a user authenticates, either via their IdP (identity provider within eduGAIN) or via the Identity Hub, <something something persistent identitfier>. The VOOT protocol correctly communicates the collaboration specific information in a standardised way to the SP that can then make the decision.
At each stage privacy is preserved by....and security maintained by....
Use Cases
A simple collaboration Use Case:
Insert comparison table: without eduTEAMS / with eduTEAMS
<Suggested graphic - two people working on a document while in two different countries>
This workflow provides an example scenario of how the proposed Basic service offering would help a research collaboration when editing a shared wiki belonging to the collaboration.
The scenario hypothesises three types of end users:
- An operator who is in charge of managing membership of the collaborations' users;
A user called “Alice”, who is a collaboration user who can login using a home institution account; and
A user called “Bob”, who is a collaboration user who has no home institution.
In order to complete this scenario successfully, the following tasks need to be accomplished:
Alice and Bob need access to a wiki service,
the wiki service requires authorisation in the context of the research collaboration as only some members of the collaboration are allowed in,
the operator has been given the authorisation to manage members in the membership management service,
Alice has the role of "wiki space admins" within the research collaboration which makes her the manager of a space in the wiki service, and she has been delegated the ability to manage members of the "wiki space editors" group,
Bob becomes a member of the "wiki space editors" group and is able to edit the content in the wiki service.
To execute this flow, the operator first needs to be able to make the Alice and Bob members of the research collaboration. To this end, the operator uses the Membership management service to make users members of the research collaboration by issuing invites. In response to the invite, the users should log in to the Membership management service and provide some basic attributes ie. information necessary to decide if they should access the service.
It is assumed that Alice will log in using a federated login authenticated via her home institution which is available in eduGAIN. Bob has no home institution, and therefore uses an External ID provider to log in with his Google ID. The operator evaluates the information received about the users and makes them members of the research collaboration. As they have membership, both users are assigned a Persistent Identifier, which is specific for this research collaboration. With the Persistent Identifier assigned to them, both users can now authenticate at services provided within the context of the research collaboration.
However, the collaboration may have services they want to restrict to only some members based on role in the collaboration. Therefore, to determine whether they have any roles within the context of the research collaboration, the wiki services queries the membership management service and the Simple Groups service. To assign Alice the "wiki space admin" role, the operator can add her to the appropriate group. This group is managed with the Simple Groups service by the operator. After being assigned group membership of the "wiki space admins", can Alice log into the Simple Groups service, and add Bob to the "wiki space editors" group.
When Bob logs into the wiki service, the wiki service queries both the Membership management service to get Bob's Persistent VO Identifier and the Simple Groups service to find that Bob has the correct role, "wiki space editors", which allows him to edit content in the wiki space.
If your organisation would like to pilot eduTEAMS please contact us by...<form goes here>
How is eduTEAMS being created?
<suggested pic - an actual team picture if possible>
eduTEAMS is being created in the GN4-2 Project by a team made up of experts from NREN Identity Federations, GÉANT Ltd. and people experienced in working with the needs of both campus and research organisations.
The development team first looked at the use cases of several major pan-European eScience communities, Research Infrastructures and e-Learning collaborations in terms of their use of federated authentication and identifies the needs and challenges they are facing. In the initial phase of the project, an open survey was set up allowing any community to specify requirements and highlight the challenges they are facing. The survey was publicised at key events and on mailing lists and by direct invite to participate. In addition to this survey, the project team also conducted a study of the AAI infrastructures currently used or planned in Europe so that the needs of communities of different sizes and involved in different e-science disciplines were understood. VOs in the field of learning were also included. The requirements listed in the Federated Identity Management for research communities (FIM4R) paper [FIM4R] were also assessed. The development team then reviewed all the requirements to find commonalities and derive a set of generalised requirements across the various communities. These requirements were segmented into two service offerings, Basic and Advanced.
Once the requirements were defined and segmented, the team analysed a combination of commercial, open source, federation and custom developed components to determine which best met the requirements for the basic service, before designing an architecture, implementing integration and carrying out custom development, contributing upstream to existing open source developments where they were chosen. The final steps are integration, packaging and pre-pilot testing. For the advanced service, a research collaboration will have the opportunity to specify some particular components to be included.
Read more about the background to eduTEAMS at http://www.geant.org/Projects/GEANT_Project_GN4-1/Deliverables/D9-2_Market-Analysis-for-Virtual-Organisation-Platform-as-a-Service.pdf#search=VOPaaS
When will eduTEAMS go live?
<Put roadmap here, with feature list and contact details>
If your organisation would like to pilot eduTEAMS please contact us by...<form goes here>
eduTEAMS News
Use this item for updates about pilot transitions etc.
If your organisation would like to pilot eduTEAMS please contact us by...<form goes here>
editorial comments
Using https://www.geant.org/Services/Trust_identity_and_security/eduPKI as the baseline example, the central part should contain real info about the development, rather than news and quick links which are better at the side IMO
Proposal for additional pages:
- screencast/movie with overview and demo
- why use eduteams? what does one gain/benefit/
- how to use eduteams (e.g. how to connect an SP consuming membership attributes)
- terminology (CO?VO?)
- presentations (previously shown)