...
Authorization based on community attributes is less relevant for the photon and neutron use case, since the authorization is entirely regulated by the service providers who enable users to access their services.
ELIXIR
ELIXIR is building a sustainable European infrastructure for storing, analyzing and sharing biological data , supporting life science research and its translation to medicine, agriculture, bioindustries and society. ELIXIR unites Europe’s leading life science organisations in managing and safeguarding the massive amounts of data being generated every day by publicly funded research. It is a pan-European research infrastructure for biological information.
The infrastructure is organized in vertical platforms, one of which is the ELIXIR compute platform. The authentication and authorization related infrastructure (“AAI”) is part of that platform and will provide user identity and access management services for the ELIXIR services (“Relying services”).
Actors in the ELIXIR AAI are currently natural persons. The ELIXIR AAI can be later extended to cover also machine accounts (e.g. servers and portals
ELIXIR AAI will be deployed gradually in the ELIXIR EXCELERATE project starting in September 2015.
Trust models and workflows
The overall ELIXIR architecture is split into three main layers. The bottom layer comprises external authentication providers and serves as a source of identities to the middle layer, i.e. the ELIXIR AAI layer. More specifically, the ELIXIR AAI layer consists of the ELIXIR Directory as a main storage of user data, related services to manage the user data, and services to authenticate the user. The upper layer is composed of relying services for the ELIXIR users. Those relying services can utilise data from the ELIXIR directory. A brief overview of each component follows.
External authentication providers authenticate an end-user and deliver their authenticated (external) identity to the ELIXIR AAI. ELIXIR supports both Home IdPs (e.g. via eduGAIN inter-federation service) and Common IdPs (Google, LinkedIn and ORCID).
The ELIXIR Proxy IdP is an authentication proxy that authenticates an end-user using an external IdP or their internal ELIXIR password (if they don’t have an external identity), and relays the authenticated identity and associated attributes to the Relying services. The ELIXIR Proxy only passes authenticated users’ attributes to the Relying services for authorisation. Associated with the ELIXIR Proxy IdP there is also a service where an end-user can consolidate his/her external identities and the ELIXIR identity, by logging in using the ELIXIR password and/or two or more external IdPs consecutively. The ELIXIR Proxy IdP can also support step-up authentication or credential translation.
The ELIXIR Directory is a central storage which stores identity and attribute information on each ELIXIR user. ELIXIR users can use the attribute self-management service where they can self-manage some of their own attributes (such as preferred language and ELIXIR password), register other identifiers (ORCID, social ID), change their ELIXIR nickname associated to the attributes in the ELIXIR Directory
ELIXIR must ensure to provide some of its services only to the users with an affiliation with academic institution. The ELIXIR AAI will provide a bona fide based status application for bioinformatics researchers, so that the community can vouch for them.
The ELIXIR group management puts strong emphasis on delegation of rights. Group managers can add users to groups via invitation, directly and, in the future, by importing group information from external systems. All group information is exposed to the ELIXIR Directory.
The Dataset authorisation management component is used by ELIXIR users where they can apply for, and dataset owners approve, access rights to datasets. The access rights are exported to the ELIXIR Directory and/or directly to the Relying service that enforces the access rights.
CLARIN
CLARIN is the Common Language Resources and Technology Infrastructure, which aims to provide easy and sustainable access for scholars in the humanities and social sciences to digital language data, and advanced tools to discover, explore, exploit, annotate, analyse or combine them, wherever they are located. CLARIN is building a networked federation of language data repositories, service centres and centres of expertise, with single sign-on access for all members of the academic community in all participating countries.
At the moment, the CLARIN infrastructure is still under construction, but a growing number of participating centres are already offering access services to data, tools and expertise. The goal is to facilitate access to restricted language resources available within CLARIN.
Thus, rather than requiring academic users to register a new username and password for each individual web application, users should be able to login with their existing institutional credentials by leveraging on IdP federations.
Trust models and workflows
CLARIN established a task force for the AAI integration in 2013, and the community is deploying AAI integrated solutions. In most countries the IdP systems of the universities and other research institutions offer a high level of traceability of users which is very relevant for allowing access to restricted corpora.
Another obvious benefit is the single sign on, lack of local accounts, increasing password security for the users and making user management easier for service providers.
CLARIN is following actively developments in the AAI field e.g., by establishing and maintaining CLARIN Service Provider Federation.
The CLARIN infrastructure includes about 1000 SPs and IdPs from 220 institutions in 33 countries. Potentially the user base could be 100.000 users (students and researchers of humanities).
For homeless users CLARIN has deployed a community IdP.
In general the experience of CLARIN with FIM is Good within a National Federation, limited in trans national federations (IdP/SPs do not trust each other, insufficient attribute release, no description of the participants).
Most IdPs offer decent login pages, SAML error messages are often very cryptic and give the wrong impression on what side (client or server) the root cause of the problem is, and the services and tools are not implemented to deal in a transparent way with missing attributes.
Adopted Authentication & Authorisation Technologies
CLARIN users are using, or will use, both their institutional credentials federated and not federated in national federations. Plus the CLARIN catch-all IdP, in order – if possible – to avoid the use of social credentials.
CLARIN use cases involves both web-based and non-web based access to services, and also delegation capabilities, which are being currently tested.
Training on how to deal with the shortcomings of FIM would be helpful: SAML error messages, testing connections, how to request attributes in foreign federations. CLARIN addresses some of the issues via the Service Provider Federation. We also attempt to address these issues ourselves, but most of them are generic FIM issues.
There should be more information for IdP operators on how SPs use them and what problems they have to solve.
Attribute release policies
The CLARIN use cases would benefit by scalable policies for attribute release, this is one of the main issue while integrating new IdP with the research infrastructure. One example of actions towards this direction is the GEANT Data Protection Code of Conduct, which is a requirement to become a CLARIN B centre.
LoA management
For CLARIN LoA management is relevant Yes, LoA is highly relevant: We would like to be able to trace users back to real persons and also have reliable user data to determine the user’s status (for example if they are students or staff).
Attribute management and community managed authorization
Missing attributes not released by the IdPs are handled case-by-case. In the worst case via the homeless IdP. A dedicated project Attribute Authority is in testing.
The CLARIN Service Provider Federation solves the necessary coverage for our project, although even then limited attribute release or complex SP acceptance policies make IdP-SP interoperability difficult in some countries. In eduGAIN, countries with Opt-In are not well covered and are not sustainable in this respect. Moreover, 6 countries are behind > 1000 IdPs in eduGAIN (July, 2015) leaving ca 300 to the rest of the world, so it would be nice to see IdP coverage in eduGAIN improve.