This page contains the details of the surveys and interviews that are being performed by JRA1.1 with user communities, research infrastructures, e-infrastructures, and other stakeholders of the AARC project.
Surveys
BioVel
BioVel supports researchers in the domain of ecology, biodiversity and ecosystems science.
The same requirements reported by BioVel in this document are also more in general applicable to the majority of the environmental sciences.
The use case of BioVel can be described with the following two trust relations:
- Relation between the end-users (for example the researcher) and service providers providing specialized domain specific data and analytical services.
- Relation between service providers mentioned in (a) above and the multi domain e-infrastructure providers like EGI.eu, EUDAT, PRACE, as well as commercial providers as AWS.
The first trust relation has to be secured (typically) by a username/password oriented SSO authentication and authorization mechanism. Service providers are unrelated to one another so a mechanism like that used with e-journals access has to be deployed i.e., persistence of sign-on available to multiple Service Providers for a timed period. Additionally, the persistent sign-on has to be capable of being delegated (automatically) to workflows / agents acting on the users’ behalf at the machine-to-machine level. Such workflows/agents may initiate transactions to multiple SPs in sequence.
The second trust relation between each community SP and a non community-specific service provider(s) is unique to each SP/FP pairing. There is no requirement for persistence across pairings.
The trust model, as has been initially described in the section 2.1.1 BioVel users need to access data repositories to search, access and upload data, and to access computing services to elaborate the data and then store back the results of their analysis. The BioVel community is leveraging on both internal service providers, for example for the data repositories, and on the European multi disciplinary e-infrastructures, for example to access computing capacity.
The community is accessing a number of heterogeneous service providers, single sign on (SSO) capabilities are fundamental to enable scalable workflows, together with an uniform authorization infrastructure. The workflows requires also to delegate the authorization of one user to a service to access data or perform actions on the user’s behalf.
BioVel foresee also to interact with citizen scientist, therefore some use cases may require the integration with low level of assurance credentials such as social media credentials.
AAI technologies
The community is still at the beginning of adopting federated identity/authorization solutions. Working closely with EGI and other service providers using X509 certificates as an authentication mean, the community is relying on the IGTF certification authorities federation. The overhead of obtaining and maintaining a personal certificate could though be seen as an excessive overhead by many new users. This solution is also not feasible for homeless users.
Penetration of federated identity management
Although BioVel management understands the need for federated identity management, the community has limited experience with federated AAI solutions. The research community has not already an AAI solution for the community in place, and therefore there is still need to acquire the needed knowledge.
Most of the users have credentials from their institutional IdPs, but the percentage of these federated in eduGAIN or other federations has not been assessed.
Currently the AAI federations, and AAI coordination activities, have been focusing on the end-user to Service provider direct interaction, in other words enabling simple SSO capabilities on the services. This approach is necessary but not sufficient to fulfil (probably) the BioVel requirements, which envisage a more complex relation between service providers, which need to interact to enable the workflows of the community. Delegation and uniform authorization across service providers will be fundamental bricks of the BioVel infrastructure.
The main barrier for BioVel is the lack of information and knowledge, and the community would benefit from a reliable and organized source of information, in form of online documentation, which can be consulted to take informed decision. Possibly integrate with trainings. Currently the information is very scattered and it is challenging to get the full picture that includes the IdPs documentation, the IdPs federations and the SP federations requirements and best practices.
The training and the documentation should be integrated with a support service and troubleshooting tools, to maximise the efficiency of the federations.
DARIAH
DARIAH-EU is the "Digital Research Infrastructure for the Arts and Humanities"; which legal form is an ERIC (European Research Infrastructure Consortium). The blocks composing the research infrastructure build on national initiatives.
Digital research methods are a fundamental part of the mainstream of humanities, arts and social sciences research. The digital arts and humanities are at a critical point in the transition from a specialty area to a full-fledged community with a common set of methods, sources of evidence and infrastructure. All of these are necessary for achieving academic and data driven scientific recognition. Information and data- intensive, distributed, collaborative and multidisciplinary research is now the norm in many scientific areas. The goal of DARIAH is to be an infrastructure that would ensure that the state-of-the-art of these collaborations is preserved and integrated, and that common best practices and methodological and technological standards are followed also in the field of AAI.
Currently the DARIAH community has almost 3000 active users.
Adopted Authentication & Authorisation Technologies
The DARIAH infrastructure blocks are built within national initiatives. AAI is based on SAML authentication combined with attribute aggregation. A DARIAH homeless account is available.
Personal data of users are stored in a central clustered LDAP server. Group memberships that provide access to services and Wiki spaces, as well as the user data are managed via a web-based administration portal. Attribute queries, as defined in SAML and implemented in Shibboleth, are used to aggregate information from the campus IdP and the DARIAH Attribute Authority implemented in the DARIAH IdP. A registration mechanism based on a central DARIAH SP ensures that all personal data that are are needed, but not provided by the Campus IdPs, are collected as self-asserted data from the user. The DARIAH IdP thus acts as an IdP-AA, but not as an SP, i.e. it is not a proxy.
Penetration of federated identity management
DFN-AAI/eduGAIN is feasible and being used by a number of users. However, there are lots of user accounts in the homeless IdP LDAP server for users that either have no federated IdP or with an IdP that does not release ePPN.
And there is some number of users that simply are aware that "a DARIAH account" can be their institutional account, who even do not try to log in via AAI, going for the homeless user option.
Authentication and authorization technologies
DARIAH user authentication is leveraging on the institutional IdP of their users, part of national federations such as eduGAIN federations, and the catch-all community IdP to host homeless users, who are a consistent fraction of the community user-base.
DARIAH is interested in SAML2, and OpenID/OAuth2 technologies, plus X509 credentials for legacy reasons.
It is important for the community that the authentication technologies are as much user friendly as possible. For the community is also important the support for delegation and non-web access, on top of the normal web accessible services.
Attribute release policies
DARIAH users will use either homeless IdP or one and only one campus IdP, with authorization and additional attributes provided by the VO via SAML attribute queries.
Having campus IdPs releasing ePPN is critical for DARIAH AAI. The community hasbeen working with a number of initiatives (notably CoCo) to improve the current situation. Thus more efforts should be made to scalably a) increase the number of such IdPs and b) find some way for to know whether a given IdP will release ePPN to DARIAH services (e.g. by respective entity categories of IdPs), still before the first user is affected and perhaps disappointed.
As an attempt to solve the, DARIAH decided that a) SPs must express eduPersonPrincipalName as required (via SAML metadata) and b) users' campus IdPs should honor this If not user will have to aplly for An DARIAH homeless account.
LoA management
DARIAH services are used for research and educational purposes only.
Therefore users are classified as : belonging to some research institution (access via eduGAIN qualifies for this, or an institutional e-mail address), or so-called citizen researchers.
Accounts that fall into the latter category are checked manually, i.e. mail communication to make sure that user is involved in research. Any institution that is not yet known (mail domains are stored) is checked manually as well, in order to be sorted into one of the two categories.
After this manual check there is no need for further information about differentiated LoA.