Page History

...

• 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  e­infrastructure.  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.

These use cases have been translated to requirements and have been described in the Deliverable "DJRA1.1:Analysis of user community and service provider requirements"  
Page xx of this document provides a dedicated description of the issues.....currently face with regard to federated identity management. Requirements R?, R?... are applicable to this context and have been guiding our work in this pilot.

...