Requirements gathering

Communities contacted

...

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.

...

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.

EGI

EGI users are mostly using credentials released by the IGTF federation. the X509 technology is fulfilling the diverse use cases of the EGI community. Never the less EGI also has many use cases of users using federated identities, there is not direct integration with the EGI resources, but science gateways and other web user interfaces have been successfully integrated with eduGAIN federated IdPs or in general with other non-IGTF IdPs.

In summary at the moment of writing EGI users can use - if needed -  credentials from federation different from IGTF, but not being directly integrated in the resources, this feature must be implemented differently for every use case.

EGI strategy is to push forward the integration with federated identity providers directly in the services. The expectations are to have direct SSO support for the operational tools that enable federation and cloud services. HTC services will likely leverage on translation mechanisms to X509.

To implement this integration, a uniform policy of attribute release and automatic management of the Level of Assurance (LoA) would be beneficial.

EUDAT

EUDAT expects eduGAIN to cover most of the user base of the infrastructure. The  B2ACCESS service will enable connection with other IdPs or federations upon request of the users. EUDAT is developing training material for the infrastructure services, including B2ACCESS.

FMI

The FMI users are often not federated in national federations, for example hospitals or commercial companies, as a consequence the service provider needs to federate with the individual IdPs.

Education

At the moment of the assessment 42 universities out of 80 (Italy) had an institutional IdP in place and running. Currently there are approximately 4 millions of users, out of the 8-10 millions that can potentially join with a 100% coverage.

Perceived barriers

BioVel

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.

EISCAT

In general the EISCAT community lacks information about federated identity management.

EGI

Being EGI an highly distributed infrastructure, with hundreds of service providers, the lack of scalable policies for the release of the attributes from the IdPs is definitely a show-stopper. With hundreds of user communities (thousands of users) and service providers, integrating potentially hundreds of IdPs with all the service providers would require an excessive amount of effort, if possible at all.

The use cases of EGI have technical requirements that require command line access and delegation capabilities, which are not extensively supported by all the AAI federations.

From an internal point of view, the main barrier is that a good fraction of the legacy software used for resource provisioning will never be ported to technologies dfifferent from X509, therefore credential translation is the only way to access those services.

EUDAT

The main barriers for a wider coverage of IdP federations among communities and service providers from the EUDAT point of view are the lack of technical knowledge and sometimes of resources. Also the bureaucracy involved in joining a federation as an IdP or an SP is considered a barrier based on the EUDAT experience.

D4Science

The main barriers to expand the integration with federated identity management are in some cases the lack of resources/funds and the bureaucracy overhead involved in joining a federation. It is not always clear, for all the use cases, if the benefits of joining a federation compensate the overhead.

FMI

The main barrier perceived is the excess of bureaucracy both to use an IdPs as a service provider and to join and IdP federation. Another problem is the lack of flexibility in the academic IdPs, in terms of technologies supported or willingness  to support new use cases.

Based on the FMI experience, it is very difficult to join national AAI federations in some countries, where for example commercial providers cannot join due to NREN policies. On the other hand a cross-national common AAI provider would solve most of the integration issues currently experienced, similar to the providers of X509 host certificates.

Education

Based on the summary survey provided by GARR the main barrier in adopting federated identity management for the universities and education institutions are the following:

First barrier is the low priority that FIM has in the management agenda of many campuses and educational institutions. All the other barriers are a consequence of the fact that management does not consider AAI important: lack of funds and expertise, for example. Lack of strategy, for example should IdP be a campus service or an externally provided service?

Requirements: Authentication and authorization technologies

The stakeholders invovled in the survey in some cases have been already using AAI technologies, and may have requirements associated to this topic: type of IdPs, standards to be considered in the AARC architecture, need for delegation technologies or non-web access to services.

BioVel

BioVel community will move in the direction of using the institutional credentials, possibly federated in eduGAIN, to access the services specific for the community but also possibly to access the multi-disciplinary e-infrastructures. In other words, institutionally affiliated login Shibboleth/SAML federated plus a solution for homeless users.

Support for delegation is a complex matter  under investigation in BioVeL. Chains of delegation are needed, both for authentication information and authorization information, and ultimately for accounting purposes.

DARIAH

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.

PSNC

Users of the PSNC services need to use their institutional IdPs to access the services, depending on the service offered, also catch-all community IdP or social media can be relevant. User friendly technologies to access web based an non browser based services are important.

Photon and Neutron

The photon and neutron community is using the Umbrella infrastructure for authentication and authorization. The technologies relevant for the community are SAML2 and X509 certificates.

Umbrella users are using credentials from their institutional IdPs and the federation in eduGAIN is an added value, alternatively users who cannot access to a federated IdP can use the catch-all IdP provided by Umbrella itself.

For the photon and neutron use cases AAI must support: easy single sign on solution, web based and non-web applications, delegation.

EGI

EGI authentication is based on X509 certificates, released by the IGTF federation. From a technical point of view X509 credentials satisfy most of the requirements of the EGI infrastructure.

Authorization on EGI services is mostly regulated by the membership to a virtual organization (VO). Services support VOs, and give access to the resources to the members of the VO. Finer levels of granulaity are possible with user groupings or roles within the VO. All these information - which are in fact community attributes - are added as extensions to the proxy certificate by the VOMS service (Virtual Organization Management Service). VOMS allows the VO Managers, the community responsible, to manage autonomously user membership and the other attributes. In this way EGI service providers delegate authorization to the communities.

EUDAT

For a multidisciplinary infrastructure as EUDAT it is important to keep open the possibilities for the users to choose the IdP of their preference, this includes institutional IdPs, both federated in national federations and non federated, catch-all IdP provided bu the research communities, and social IdP. The LoA associated to them is also important.

Within the EUDAT infrastructure many services are offered and each service has it’s own needs with respect to authentication technologies. Currently EUDAT is supporting X.509, SAML and OAuth2. Some services are web based but others are not. In this case the infrastructure is currently using X.509 based solutions. Moreover, EUDAT aims for a single sign on experience but given the complexity of the infrastructure this is not always possible.

FMI

The best solution for FMI would be to get AAI as a service, as provided by the commercial provider currently used. FMI needs to integrate IdPs both federated and non federated in the national federations, as well as social IdPs for the homeless users.

Easy and user friendly SSO, friendly for the end users but also for the service providers, support for both web based applications, and command line applications.

D4Science

D4Science services are enabled for SAML2, X509 and (under evaluation) Open ID Connect, OAuth2, in terms of sources of identity information, the infrastructure will need to access institutional IdPs, catch-all IdPs managed by the communities and in the future social credentials.

The federation with the national federation is under evaluation, and in general D4Science would benefit of simpler procedures to join an IdP federation as service provider.

D4Science services would benefit from delegation and non-web access capabilities.

CLARIN

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.

Education

For the education community the institutional IdPs are the most likely credentials that the users will use. Governmental IdPs, e-ID, could be also potentially  interesting once they will reach full maturity.

Either solution will be predominant, user friendliness is the higher requirements for this community.

Currently the coverage and the features of the national and European IdP federation are not entirely fulfilling the needs of the education sector. Besides the campuses not yet federated there are other categories of users who would be left out anyway: for example the high school students not yet registered in a university but who need to access some tools, and the citizen users in the university library.

Requirements: Attribute release policies

When service providers and user communities have the need to get attributes (e.g. institution, email address, name,…) from the IdP of the user, the bureaucracy involved can be an unacceptable overhead. If the users use many different IdPs, coming from different institutions, the service providers supporting the community need to access these attributes, therefore there could be need for a set of policies that make scalable the negotiation between SPs and IdPs.

BioVel

BioVel will very likely make use of the attributes released from the IdP, if available, and the community would benefit from scalable processes and policies between IdPs and SPs.

DARIAH

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.

PSNC

The release of the attributes has not been an issue based on the PSNC experience.

Photon and Neutron

Not relevant for the use case.

EGI

EGI is a highly distributed infrastructure, whith hundreds of service providers, hundreds of communities, and tens of thousands users. In this scenario is critical that the policies and the procedures are scalable with the number of actors involved.

Attributes are important to reduce the effort for user management on the communities or the service providers. If trusted IDPs can release easily information to the service providers, the credentials can be used to access the most complex workflows in the infrastructure without the need of additional vetting of the user identity.

But even in a scenario where the IdP releases a minimal set of attributes, policies must scale. For example services must be able to store and to share with other services the unique identifier of the user provided by the IdP.

Service provider federations should be seen by the IdPs as trusted entities, once policies are agreed with the federation should be valid for all the service providers within the federation.

EUDAT

The more information that is provided by the user’s IdP, the more streamlined the process of creating the users identity in the EUDAT infrastructure will be. If the users IdP is not providing enough of the required attributes, we will prompt the user to provide these. Currently EUDAT aims to a minimum set of attributes a name and email address.

D4Science

Yes, the infrastructure would benefit from a simpler way to access attributes released from the IdPs.

CLARIN

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.

Education

Having scalable policies for attribute release is relevant for the community.

Requirements: LoA management

An AAI infrastructure that manages different Level of Assurance (LoA), allow users to use credentials with from sources that provide different level of assurance, and communicate properly the information about the assurance to the service providers.

With this information service providers, but also the user communities themselves, can decide which tasks the user can perform and which services can be accessed by users with the credentials used.

Requiring that all the user credentials have the same LoA regardless of the actions that are performed adds unnecessary overhead, and can discourage new users.

One example of this is that to upload big amount of data, and to use resources, users should be strongly authenticated, while to read open data the lower LoA is enough.

BioVel

At the moment the community has no clear use cases for a differentiated level of assurance, but there are two potential uses for it:  enable limited access to citizen science services, with social accounts, and restrict access to other services only for very high assurance credentials.

These use cases have not been formalized yet within the community, but it is a key issue how institutionally affiliated users can be made able to authenticate using a non-institutional mechanism (i.e., FB, Google, etc.) in the same way that some users opt to use a non-institutional email address.

DARIAH

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.

PSNC

No need for LOA management is needed for the moment, but there are potential use cases for this that are foreseen for the future.

Photon and Neutron

LoA management is relevant for the Umbrella use case.

CLARIN

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

EGI

EGI supports a very diverse set of use cases. Open data is a typical use case where a very large community of users can access a data set, but there is need for a lightweight authentication to account – for example – the number of connections to a service. In this example EGI needs to enable users without the need for ‘expensive’ high assurance credentials.

Clearly service providers must be able to extract information about the LoA from the attributes associated to the user identity. LoA definitions should be standard and simple, not to over-complicate the service provider decision to allow, or not allow, the user task.

EUDAT

The level of assurance assigned to the user credential is a very important attribute for the EUDAT use cases. EUDAT plans to be as open as possible in terms of the types of credentials accepted, and good practices in the management of LoA would be beneficial for the future development of B2ACCESS.

FIM

Service provider will ultimately decide on supporting low level of assurance identities, what SPs need is to get the information about the LoA in a reliable and standard way.

Requirements: Attribute management and community managed authorization

Authorization is separated from authentication and in many cases it should be controlled by the community. To implement this community-driven authorization user communities must manage a set of attributes associated to the users, which need to be provided to the service providers together with the identity attributes provided by the IdP.

BioVel

Community level authorizations are surely needed but the main obstacle is to integrate the community specific attributes with the institutional IdPs attributes. The trend for many communities is now to set up community IdPs. BioVel community would prefer to have a generic infrastructure to handle community attributes, rather than deploying their own system.

DARIAH

The only user identifier used is ePPN, DARIAH connects user’s ePPNs and accounts together in the DARIAH portal.

The homeless IdP delivers via SAML attribute queries keyed by the ePPN the following attributes:

• any needed personal attributes the campus IdP did not provide, e.g. mail
• the accepted terms of use for the service in question
• authorization attributes, i.e. the names of the authorization groups the user is member of

Authorization group membership is managed manually via the administration portal in a distributed way, i.e. by the administrators of DARIAH countries, organizations, and projects.

DARIAH is therefore using community attributes to authorize access to internal services and potentially to all the services supporting the community.

PSNC

Persistent identifiers are not needed for the moment, while community based authorization is foreseen to become more important in the future, and therefore PSNC is interested in supporting it.

Photon and Neutron

The community has already an unique identifier for the users. This is provided by the Umbrella infrastructure, since this has been a very important requirement for the community use case from the beginning.

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.

EGI

EGI infrastructure is already consuming community-provided information for the authorization of users on the services. Currently the services that allow research communities to manage their attributes are based on X509 certificates. It is critical that integrating with multiple authentication technologies, EGI services are able to both consume attributes from the attributes management services already in use by the communities and offer to the users tools that can be used with their institutional credentials.

Community attributes are also important to integrate the missing information not provided by the IdPs.

The attributes associated with the user identity are not only used to authorize access to the resources (cloud, storage or HTC), but also to identify the user’s role in the community, and authorize privileged access to the Operational Tools.

EGI foresees the need for a user unique and persistent identifier. One use case is to map multiple credentials to a single user. A second use case, and in particular for an EGI-specific unique identifier is to share between EGI services authorization assertions which may not be possible when using an IDP-provided user UID.

EUDAT

B2ACCESS will consume the attributes provided by the IdPs, and integrate with additional attributes where needed during the user registration process. B2ACCESS will in fact act as an attribute provider as well.

Given the distributed and heterogeneous nature of the EUDAT infrastructure, a persistent identifier for the user is really important. This is exactly the reason why EUDAT is mapping the users community identity to an (internal) EUDAT identity, since at the moment the infrastructure cannot rely on proper persistent identifiers in available from third parties. Even with this approach it is possible that the same user might get multiple EUDAT identities based on the used combination of IDP and SP and the attributes which are provided.

The use of community attributes for distribute authorization is a topic that has not been yet fully addressed by EUDAT but it is high in the agenda.  For the EUDAT services the authorization management should remain on the communities.

D4Science

The Authorization Service is based on Attribute Based Access Control paradigm, where valid attributes depend on the caller:

• Roles are currently the only attribute associated to humans
• Several attributes are associated to services (that can act as clients in m2m communication) such as Service Class and Service Instance identifier.

These attributes are internally managed within D4Science and currently are not using community attributes, therefore the integration with external attribute authorities has a lower priority.

FMI

Persistent identifiers for the users is a feature needed in the FIM use cases, ORCID is a possibility, for example.

FIM uses an entitiy-attribute-value model to regulate authorization, customizable per user, community, group, organization, department etc. The community or the users decide on the attributes release policies, which are then used by the FMI service provder to authorize users.

FIM would benefit from better and scalable policies for attribute release from the IdPs.

CLARIN

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.

Education

Community based attributes can also be relevant for the education community, for example to implement a more flexible authorization than the ip-based access to services. A unique persistent identifier associated to the user credential information is also considered important.

User stories

DARIAH

The following are the different possible workflows/user stories that are relevant to the DARIAH use case:

• DARIAH homeless user accessing DARIAH services.

This is likely the most common use case identified for the DARIAH community. DARIAH SP get the authentication information from the DARIAH IdP where the homeless users must register to use DARIAH. The DARIAH-IDP releases the user attributes and the authorization (community) attributes directly to the SP. From a user perspective the service provider and the IdP components are seen as homogeneous without separation.

• DARIAH homeless user accessing Federation and interfederation resources

This use case extends the previous one, DARIAH users should be able to access services provided to the DARIAH communities by external providers, by using the DARIAH-IDP. The DARIAH users will be able to browse and find the DARIAH-IDP in the service discovery service offered by national federation. In a similar way homeless users should be able to access inter-federation services supporting the DARIAH community as well.

• Federation users accessing DARIAH resources

Users wishing to access DARIAH resources using their institutional IdP, which should release at least one identifying attribute. DARIAH SP retrieves the missing attributes, not released from the IdP of the user, and the community attributes from the DARIAH IDP, which is filled by the users during their first connection. Community attributes are assigned to the user beforehand.

EGI

The currently most common use case for EGI is users accessing resources. Resources can be computational, storage, or virtualized resources, and the user can access directly through the APIs of the services exposing the resources, or through science gateways and portals.

Use case: user wants to access EGI resources through a science gateway using their federated credentials.

1. The user access a portal with their institutional credentials.
2. The portal gets the attributes released from the identity provider of the user.
3. EGI or community attribute authorities provide the other attributes to complete the identity attributes, the community attributes must confirm that the user is a member of a VO supported by the resources exposed through the portal. User must also be associated to an UID which can be shared across services to track user activities.
4. The user selects the resources they want to use and the actions that they want to perform.
5. The portal assess if the LoA provided by the IdP suffices to the security level requested by the actions and the resources requested.
6. The user tasks can act on behalf of the user, for example output data can be stored on resources of another service provider, and be associated to the user UID.
7. The user tasks generate accounting data that is associated to the user persistent identifier.
8. User can access EGI accounting infrastructure and retrieve their accounting data, or the accounting data of the community they manage.

Use case: user wants to access resources through command-line interfaces.

1. User is registered in a virtual organization, that means the user is registered in the attribute management service that manages the VO membership, possibly with their institutional credentials.
2. To perform the planned tasks the user connects to a credential translation service, where the attribute identity, the LoA and attributes are translated in an authorization token using a technology compatible with command line use.
3. User connects to the service resources using the authorization token received in the previous step
4. The service assess if the user attributes are fulfilling the requirements for the use of the resources requested, and if the LoA of the original credential is fulfilling the security requirements of the service
5. Continues as in point 6 Of the previous use case.

EPOS

EPOS users, the researchers, need to access earth observation data that is stored in a distributed network of repositories.

1. The researcher connects to the EPOS central services to discover relevant data for their research
2. The use of institutional credentials is preferred but not mandatory
3. The central services find the data requested by the user and contact on behalf of the user the data repository to retrieve the data
4. The user analyses the data on the tools provided by the EPOS central services, and downloads the outputs

The access to the original dataset must be accountable to the user.