...
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.
EGI
Trust models and workflows
EGI is a resource infrastructure. The main goal is to enable users to access the distributed infrastructures.
The user 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.
Adopted Authentication & Authorisation Technologies
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.
Penetration of federated identity management
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.
Authentication and authorization technologies
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.
Attribute release policies
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.
LoA management
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.
Attribute management and community managed authorization
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.