The EGI AAI CheckIn Service
Wednesday, September 28, 2016 - 11:30
The EGI AAI CheckIn Service enables research communities to access the EGI services in a user-friendly way, while preserving security and user privacy. Researchers from home organizations that participate in one of the eduGAIN federations are able to access the EGI services using the same credentials they are using at their home organization. Furthermore, the EGI AAI CheckIn Service supports user authentication with social media identities, enabling even those users who do not have a federated account at a home organization (such as many users that belong to the “Long Tail of Science”), to be able to access the EGI services in a seamless way without compromising the security of the EGI platform. The EGI AAI CheckIn service can connect to existing community based AAIs and it can be offered as an “Identity Access Management as a Service” to those communities, which do not have or do not want to operate their own AAIs.
The guiding principles for the EGI AAI CheckIn Service are the following:
- Users should be able to access the EGI Services using the credentials they have from their Home Organizations using eduGAIN when possible, but alternate methods should be available
- EGI should expect to receive at least an identifier that uniquely identifies the user coming from within the scope of the authentication source.
- Within the EGI environment, a user should have one persistent non-reassignable non-targeted unique identifier. This unique identifier is used to “link” different accounts belonging to the same users.
- EGI should define a set of minimum mandatory attributes, without which a user cannot exist within the EGI environment.
- EGI should attempt to retrieve these attributes from the user’s Home Organization. If this is not possible, then an alternate process should exist in order to acquire and verify the missing user attributes.
There should be a distinction (LoA) between self-asserted attributes and the attributes provided by the Home Organization/VO
- Access to the various services should be granted based on the VO/EGI roles the user has.
- EGI Services should not have to deal with the complexity of multiple IdPs/Federations/Attribute Authorities/technologies. This complexity should be handled centrally and should be hidden from the EGI Services.
Based on these principles and following the guidelines from the AARC project, we designed an architecture for the EGI AAI and a roadmap in order to incrementally introduce the new service elements on the EGI platform.
The core component of the EGI Checkin is an IdP/SP Proxy, which acts as a Service Provider (SP) for the supported identity federations, while at the same time, acts as an Identity Provider (IdP) for the services deployed in the EGI infrastructure. When EGI wants to enable the access to an Identity Federation, it will be enough register the IdP/SP proxy as service provider of the federation. The architecture of the AAI infrastructure is modular and allows the integration of several attribute authorities, to grant users with access to the EGI services, and credential/token translator services (TTSs), to generate user credentials that can be recognised by the EGI services (e.g. from a SAML token to a X.509 proxy certificate).
In this session the participants will learn about new ways to access and exploit the EGI infrastructure. Research communities and infrastructures could learn how to deal with challenges problems related to the authentication and authorisation processes in a distributed environment and how the EGI AAI CheckIn service can help the to overcome them.
The target audience for this presentation are Research Communities, Research Infrastructures and Services providers who want to enable scalable, secure and easy to use federated access for their service offerings.
Benefits for Audience:
Participants will learn about new ways to access and exploit the EGI infrastructure. Research communities and infrastructures could learn how to deal with common problems related to the authentication and authorisation processes in a distributed environment
Topic 2: Services enabling research
|Peter Solagna||EGI Foundation|