My thoughts on EGI Federated Identity Platform

Last week I attended the AAI workshop organised as part of the EGI technical Forum.
The workshop was meant to discuss the proposed paper on EGI federated identity platform [1] and to identify components (some operated by EGI, some operated by other communities) that could be part of this platform.

I was asked to give a presentation on the AAI developments in the NRENs community. My presentation was slightly different from the others; I was mostly reporting on the NRENs perspective, whilst the rest of the presentations reported on approaches to integrate federated authentication with Grid X.509 credentials and VOMS.

All the proposed solutions aimed to solve two main issues:
1. make x.509 certs more user-friendly – this could be achieved by using short lived credentials and by using federated access to authenticate users and upon authentication provision X.509 certs for them.
2. accessing non-web-based services with federated identity credentials – some of the presentations presented how SAML ECP Profile was successfully used.

Clearly the Grid community is really interested in making x.509 certs more user friendly; there were different presentations on the topic with different solutions.
Some things struck me, though. Some of the proposed solutions try to solve the problems by developing ad-hoc federations or ad-hoc solutions. Whilst these solutions may solve the problems in the short term, maintaining ad-hoc solutions in the longer term will become a problem.

What seemed to be overlooked is that in many cases the technical set-up is rather straight forward, but the ‘problems’ start when an infrastructure has to run in production (users support, policies, accounting etc). Running a federation for instance is not a trivial job (and requires manpower), if that’s done in production. The policy aspects, the data protection issues, the support for higher LoA (required by the eScience) with the associated additional costs to implement it and the policies to release attributes issues seem to be often underestimated or not truly addressed.

An interesting example is the Grid Identity Pool (GrIdP) developed by the INFN. As stated on their website “GrIdP” is a federation, but is that really what it is?

GrIdP allows users to login to different portals (Science Gateways); the authentication is based on shibboleth and users from participating institutions/federations can log in. The various science gateways are also listed as eduGAIN SPs. Users who cannot use any of the IdPs registered with the GrIdP (or who are not served by any IdP) can register to the IDPCT (Identity Provider Catania), the guest IdP.
The authorization is not automated, users are requested to provide a registration form which has to be approved by the project or the community for which the gateway has been developed.

I give INFN the credit for getting people of different regions (Latin America, Middle East, Africa) interested in federations; their GrIdP (in combination with the virtual machines with pre-configured IdP [2]) tries to reduce the technical barrier for creating/joining/using a federation and if promoted in the right way could be helpful. However GrIdP is not a federations, but more a technical experiment and sadly all the policy issues will have to be addressed if GrIdP reaches a significant user-base.

EGI recently joined the GrIDP as an IdP. The EGI federated architecture paper proposes to extend the GrIdP “towards a platform that enables research communities to create community-specific identity federations”. The paper proposes to build the EGI identity platform using GrIdP. This particular point was very contentious during the open discussion that followed. Some of the issues of concern were:
– If GrIdP is used for EGI platform who is the data controller? Who takes responsibility for the data?
– How are data transferred among parties involved in the GrIdP?
– How does GrIdP relate to national federations/eduGAIN? And will the different procedures followed by GrIdP will reduce the user’ experience?
– Is the access to the portals compliant with the IGTF guidelines?

Eventually it was clarified that EGI main interest was not in establishing another platform that enables research communities to create community-specific identity federations, but in discussing the other components of the architecture: attribute provider, authorisation policy and a X.509 proxy factory.

It’s good to see these topics discussed in EGI; I think REFEDS/eduGAIN community should get involved in providing feedback to the paper and possibly get involved in any pilot EGI may start in the future.

I enjoyed the workshop and I look forward to seeing an updated version of the “EGI federated identity platform” paper.