...
By delivering an integrated AAI framework, AARC will improve ....the federated management and access to the services. We started several pilots to address the needs and problems faced by ......the EGI user communities.
The use cases
- Authentication technologies. New user communities prefer using technologies for authentication different from X509 digital certificates, for example username/password based authentication.
Single sign on. Users should be enabled to use their institutional credentials to access EGI services. One barrier for new users is that they have to obtain a new credential to access the einfrastructure. In some cases, this is just an inconvenience, yet another credential to manage, but for some users (those outside institutions or the major IdP federations) it may be not possible to obtain such a credential. User friendliness is of course a major feature for any Single Sign On capability.
- Community attributes-based authorization. Community-based authorization has been implemented in EGI from the beginning, and is at the basis of the collaborative nature of EGI. It is fundamental for EGI that every AAI technology and architecture enables the communities to manage the capabilities and the roles of their users, and to let these attributes be used by the services to regulate the authorization. Given the scale of the EGI service, providers cannot implement per-user authorization, but must authorize a user based on the attributes associated to that user.
- Non-web access. EGI services are accessible natively by command line clients, implementing the services’ standard APIs. While there are several options for users to use web-tools to access the resources, authentication must consider both web and non-web access scenarios.
- Delegation. EGI services allow complex workflows, and users often submit thousands of computational tasks that need to access other resources (e.g. storage) on their behalf. The authentication technology must support delegation, either natively or through credential translation to another technology. Without delegation EGI users cannot get the full potential of the services.
- Scalable policies for attribute release. EGI is a highly distributed infrastructure, with hundreds of service providers, hundreds of communities, and tens of thousands of users. In this scenario, it is critical that the policies and the procedures are scalable with the number of actors involved.
- PID for users. 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 authorization assertions between EGI services, which may not be possible when using an IdP-provided user UID.
- 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, for example to account for the number of actual users using 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, so as not to over-complicate the service provider’s decision as to whether or not to allow the user task.
- Credential translation services. While the plan is to push forward with the direct support of federated identity technologies for the central tools and the new service types, some services, for example those offering HTC resource, will likely continue to use X509 technologies, therefore credentials translation capabilities are necessary to allow users with federated identity credentials to access the full set of EGI services.
...