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

Compare with Current View Page History

« Previous Version 13 Next »

Requirements gathering

Communities contacted

The following communities, either represented in AARC consortium or external, in contact with AARC JRA1.1 or other tasks. Contributing to the definition of the AARC plans.

  • DARIAH
  • CLARIN
  • WLCG
  • ELIXIR
  • PARTHENOS
  • ARIADNE
  • BioVel

Other stakeholders/target for the questionnaire

  • Education/Cloud providers for education
  • Libraries
  • IdPs

Summary of the answers collected

BioVel

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.

EISCAT

The main use case for authentication and authorization in EISCAT is to grant access to datasets to the institutions/users who are eligible to download the data.  Federated AAI could also make easier the accounting for the data usage.

The control over the access to the datasets have been done, so far, using the IP address of the client. But with the extensions of the use base, including additional affiliates, service providers will need to adopt a more sophisticated authorization mechanisms, with a user-by-user granularity.

Also, the logging of who downloads data is not done, meaning there is no way of communicate to the users any new information of problems with the data they have taken. Also, for the reporting to the owners, there is no information taken for what kind of study the data has been downloaded.

The use case here, would be a good way for authentication of who and possibly why they download data. An 'EISCAT' certificate for users, including who, why, when, how the user will handle the data. One could think of different levels of the certificate for different levels of data.

Currently EISCAT is not using AAI solutions directly integrated with the services.

CLARIN

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.

EGI

EGI is a resource infrastructure. The main goal is to enable users to access the distributed infrastructures.

The process to access EGI services is illustrated in the above picture:

The user, on the left, obtains a personal certificate from a certification authority recognized by EGI, then the user adds the information about their VO to the certificate generating a X509 proxy. To be able to do so the user must be authorized by the VO manager, to simplify the PI of their collaboration, who controls the membership of the VO they are managing.

All the needed information (user identity, Vo memnership, additional roles and capabilities within their VO) are shipped to the EGI services that use these information to authorize the access to the services. Generally access to services is regulated by VO membership: a service provider supports a number of VOs and users can search for the services enabled for their VO. Finer grained user authorization is possible but not often applied since the scale of the infrastructure. The AuthN/AuthZ process is based on the trust between CAs federation and the service providers federation, plus the trust between the service providers and the user communities (VO).

X509 authentication has proven to be scalable and to work for almost any use case, from a technical point of view. New user communities prefer to use other technologies for the authentication, for example username/password based authentication.

EUDAT

Federated access has been one of the goals from the beginning of the EUDAT project. EUDAT infrastructure is designing a new service called B2ACCESS to enable the integration of federated IdP with the EUDAT services. The use cases for this service are:

  • Integrating new IdPs and enabling SSO for the users using credentials they already own
  • Providing an EUDAT unique identifier for the users
  • Providing additional attributes associated to the user identity
  • Providing catch-all IdP for homeless users

This solution may support also non federated IdPs, nevertheless it would benefit from federated identity management relying on the LoA and the other best practices implemented in a federation.

As technical solution for B2ACCESS EUDAT is deploying unity-idm.

The level of information available is different in each of the communities and needs to be tackled case by case as more and more communities join the EUDAT infrastructure.

In general the EUDAT experience with AAI solutions is good both in terms of usability and quality delivered. The technologies currently enabled in EUDAT are X509 certificates, SAML2 and OpenID Connect/OAuth2.

B2ACCESS is not yet integrated in eduGAIN, but this is high in the list of priorities, currently it is under testing with an handful of IdPs and users.

FMI

FMI would support many applications cross institutions and countries, but currently the academic AAI have issues in cross-country interoperability, and interoperability – for example – with social media credentials. FMI uses a commercial AAI solution, Auth0, and it works very well for the FMI use case, one example is the integration with a commercial service such as dropbox, which was very easy and fast.

The experience with academic IdPs  has been difficult because of the bureaucracy involved, and the limitations for attribute sharing.

D4Science

The main benefits in FIM highlighted by D4Science are:

The easiness in taking part in several research communities by using a single set of credentials.

Less barriers for users in accessing services exposed by different research communities.

Adoption in conjunction with Access Delegation, Federated access enables capability to build composite services built on top of services spanning across different identity domains.

 

In general using using the SAML Web Browser SSO profile tools are user friendly and they fulfill the user expectations, where such expectations are SSO capabilities with a adequate level of security.

 

Adopted Authentication & Authorisation Technologies

BioVel

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.

DARIAH

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.

ELIXIR

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.

EGI

EGI is a highly distributed infrastructure, multi-disciplinary, integrating more than 300 resource centres (service providers) and almost 20,000 users grouped in 200 user communities called Virtual Organizations (VO). Currently, authentication and authorisation within EGI is enabled through a X509-based Public Key Infrastructure (PKIX), based on the Interoperable Global Trust Federation (IGTF) and EUGridPMA Certification Authorities federation.

X509 technology, and in paritcular X509 proxies, enables some of the most important capabilities for EGI: scalability, command line access and delegation. The user actions are usually initiated by submitting a request with attached an X509 proxy, this means that in case of bulk submissions of - as an example - thousands of computing tasks, the services do not need to contact the IdP or the attribute authority of the users thousands times, since all the needed information are in the proxy. The X509 credentials work with no issues with command line commands, and the proxy implement a form of delegation (impersonation) that allows a service to perform a defined set of actions on behalf of the user.

From a technical point of view, X509 authentication has proven to be scalable and to work for almost any use case. However, new user communities prefer to use other technologies for the authentication, for example username/password based authentication.

There is a capillar network of certification authorities and registration authorities, distributed among the EGI partners, which can be contacted by users to obtain a certificate. EGI runs a catch-all CA to support users who - for any reason - cannot access an existing CA.

To bridge different authentication technologies with X509, the EGI partners and the user communities are deploying science gateways and portals where users can authenticate with username/password, and access the resources through web-based tools and interfaces. The portals are then generating short-lived X509 credentials that are used to access resources.

The most common mechanism used to bridge between IdPs and X509 are the robot certificates, which can generate programmatically short lived X509 proxies that are used to access EGI services. One of the drawbacks of this solution is that the real user identity is hidden behind the robot certificate. To partially address this issue, EGI is implementing an extension of the X509 proxy certificate that contains an ID that can identify the user if needed. This is particularly useful for accounting purposes and, at the same time, improves the overall security of the implementation.

 

EUDAT

The EUDAT infrastructure is implementing an AAI solution called B2ACCESS which bridges various AAI technologies used by the communities with the various technologies used by the service providers within the infrastructure. Users of the infrastructure must be able to use their home organisations’ IdPs to log in to the EUDAT infrastructure, as well as IdPs run by the user communities (e.g. CLARIN) and, when applicable, social media (e.g. Google). The user’s EUDAT identity contains attributes provided by the “home” (external) IdP, supplemented with attributes maintained by B2ACESS itself (the proxy scenario) - so every internal identity can present, for example, an email attribute. Finally, EUDAT itself can also provide a “homeless” IdP by having users authenticate using username/password.

As EUDAT runs a lot of different services internally, SPs are offered different technologies for integration with B2ACCESS. Based on work originally done in the Contrail project and carried forward by the first EUDAT project, services can choose to use SAML (using the WebSSO profile), OAuth2 (RFC 6749), or X.509 certificates. In a simple scenario, a service will use OAuth for simple access and authorisation; a more complex scenario would use SAML to authenticate and pass authorisation decisions to an XACML infrastructure. In the most elaborate scenario, users would authenticate to a (community or EUDAT) portal using SAML WebSSO (which in turn redirects to the “home” IdP); then the portal obtains an OAuth access token to grant further rights, including the right to obtain a certificate on behalf of the user from a web services certification authority (internal to B2ACCESS) - it then generates the keys and obtains the certificate which includes authorisation attributes. This scenario provides extra security compared to many of the traditional portals as the issuance of the certificate requires additional authorisation (the portal has to be registered as an OAuth client and needs to be authorised to obtain a particular user’s certificate); the management of such authorisations can be predefined administratively or by the user and can be audited subsequently. Power users can download the certificate and use it to drive non-web services from the command line, e.g. B2SAFE and data transfers.  Despite its complexity, this approach offers a high degree of flexibility of integration of the many different components that comprise an EUDAT infrastructure, and many services will choose to use only the least complicated AAI mechanisms depending on their security requirements.

D4Science

The Authentication Service supports username/password and X509 Certificates factors: the former is used mainly for human-machines interactions (Portal or SOAP Services) and the latter is mainly used for machine-machine interactions (SOAP Services called by other services). 

The user interface portal support SAML federation with the classic Web Browser SSO profile. An hybrid profile based on Web Browser SSO and SAML Token profile enables SAML federation for SOAP Web Services.

FMI

FMI is using Auth0 (https://auth0.com/), which is a commercial solution for AAI integration.

Education

The institutional IdPs are using SAML2 technology, and solutions like Grouper for the attribute management.

Penetration of federated identity management

BioVel

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.

DARIAH

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.

PSNC

In Poland there are not many institutions federated with eduGAIN or PIONIER.Id, therefore an important fraction of the users have no access to federated ids.

 

 

 

 

 

 

 

 

 

  • No labels