...
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 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 remember exists in one of NvDs presentations but can't find>
...
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 is free in the Basic version
The Basic version provides everything that a small to medium-sized research community would need to start collaborating. If this is not enough, the Advanced version offers more features at moderate costs. The Advanced version is not free to ensure its sustainability. - eduTEAMS is using open source products that are freely available
The products used for the current components are CoManage, SaToSA and the CESNET Discovery Service (tbc). - eduTEAMS is allows connecting own web services to the Member Registration attribute authority service
This allows these services to consume authorization information (e.g. group membership).
There are multiple protocols that can be used to access authorisation information (e.g. SAML via AttributeQueries, VOOT, Oauth)
For most other comparable e-Infrastructure services this is not easily possible. - 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. - 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 communitieseduTEAMS is a generic collaboration management service and open to all research communities
Other e-Infrastructures were created with a particular research community in mind or specific purpose. Therefore, they often are custom tailored to these communities needs and requirements, which might be limiting for others.
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.
...
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.
...
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.
...
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
...