You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

 

The purpose of this page is to assemble content for the eduTEAMS site on the GÉANT public website.

About eduTEAMS

Scientific research is at the heart of every European University. Nowadays, such research is no longer an isolated activity. With the capabilities of the internet to connect not only people but also resources, sciences have evolved into e-Science where individual participants in an experiment, paper collaboration or users of specific Research Infrastructures come together from a wide range of countries and organisations.

Authentication and authorisation infrastructures (AAI) are required to regulate who can gain access to resources in such distributed environments. While federated identity and eduGAIN go a long way to enabling such access policies, in many cases, research groups of all sizes need additional specialised infrastructure built on top of eduGAIN to manage group and authorisation information, and also to integrate users from a wide range of environment, connecting them to their services, and also to other generic services such as storage and compute provided by any eInfrastructure provider or even commercial entity.

eduTEAMS is being designed and piloted by GÉANT in two variants to meet those needs:

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

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>

How eduTEAMS Works

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 individuals'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 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.

Use Cases

A simple collaboration Use Case:

<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:

  1. Alice and Bob need access to a wiki service,

  2. the wiki service requires authorisation in the context of the research collaboration as only some members of the collaboration are allowed in,

  3. the operator has been given the authorisation to manage members in the membership management service,

  4. 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,

  5. 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. 



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>

 

eduTEAMS News

Use this item for updates about pilot transitions etc.

 

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

  • No labels