Minutes of JRA1/JRA5 joint meeting, Cambridge 12th of Jan 2006

From GEANT2-JRA1 Wiki

Location: Thu 12th Jan Cambridge. Participants: more than 20 people, from both JRAs. (Maurizio to be blamed for not having circulated an attendance list form...). Goal: discuss perfSONAR use of eduGAIN infrastructure (JRA3 and SA3 are in CC for potential similarities of their AA needs). These minutes are a summary of the relevant meeting's outcomes. Written by Maurizio Molina, reviewed by Stefan Winter, Simon Muyal, Loukik Kuridamoti. Any comment is welcome.

Terminology: AuthN: AutheNtication AuthZ: AuthoriZation HLS: Home Location Service MA: Measurement Archive (Service) MP: Measurement Point (Service) AS: AuthN Service IdP: Identity Provider

Three main points were discussed during the meeting: - Role of the Lookup Service (LS) within the perfSONAR AuthN flow - How perfSONAR can use eduGAIN infrastructure and primitives ("Orphans" problem) - Need of an additional profile to handle AuthN of "automatic clients" (i.e. not web browser clients). In addition, this report contains: - Other issues - Action Points list

Role of the Lookup Service (LS) within the perfSONAR AuthN flow

LS service is the first (web) service that is contacted by a client in perfSONAR. Each Resource (e.g. MA, MP) that wants to be part of perfSONAR must be registerd in a LS. Within the resource related info in the LS there must be: a) the indication about how to authenticate to get access to the resource (or better, to be able to submit to the resource an access request, as it will be clarified later) b) how to contact the resource (e.g. its IP address). Both informations are considered "sensitive", therefore are not freely released to the client, but require that the client authenticates itself before. The LS becomes therefore the first resource for which a client performs AuthN within perfSONAR. The LS will find out the AS where the user must authenticate (possibly using the eduGAIN HLS) and let the client authenticate there, returning to it a "token" (or "SubjectHandle" in JRA5 jargon).

In the simplest case, the LS and all the resources the user must access belong to the same federation (or to confederated federations, e.g.. eduGAIN). In this case, the information a) will be simply: "you don't need to authenticate any more to access the resources b) (list....) , just access them with this token. The client will then perform as many resource access as needed, and each resource may use the SubjectHandle provided by the user to ask back to the AS who granted the handle additional user's attributes. After that, each resource will take an authZ decision (need of validating the token was mentioned).

In a more complicate case, some of the resources will not belong to the same federation of the LS, i.e. they will not be able to trust the SubjectHandle provided by the AS where the user authenticated to for accessing the LS. The information returned by the LS becomes more elaborate: "you can use the token you already got from AS_X to access resources 1, 2, 3, ... but for resource 4 you need to authenticate to AS_Y, for resource 5 and 6 to AS_Z, and so on..". In this case, prior to accessing the resources for which it hasn't got a token, the client must perform authN with the specified AS(s), get tokens(s). Then, it can proceed accessing all the resources as described before. Providing MULTIPLE AS choices to the user for the same resource was discused (but it seems a complication...). The more complicated case is needed in the short term. The long-term target should be to converge to teh simplest case.

However, in both cases WHERE to authenticate is always decided by the LS. The resources need not to worry about that.

How perfSONAR can use eduGAIN infrastructure and primitives

JRA5 already specified a set of primitives for performing the AA related operations described above (AuthNRequest, AttrRequest, HLRequest, AuthZRequest and the corresponding responses). A first specification of them in a Java API interface them was presented by Jose' Manuel. The implementation of this API will be done by JRA5 (first library in two months from now, with later refinements but keeping the API fixed). However, since this library must rely on "lower level" operations performed by AA Infrastructures, it is assumed that both the resources and the IdPs are within a federation of the following types: Shibboleth, Moria, PAPI, A-Select. JRA5 will only write the adaptors to these types of federations. Since not all the resources and IdPs inserted in perfSONAR will belong to an existing federation, there is a problem. Three possible solutions were discussed: - JRA1 write from scratch "adaptors" for resources and IdPs not belonging to any federation, - ask existing federation to "adopt" homeless resources and IdPs - perform a Shibboleth deployment to give a "virtual home" to homeless resources and IdPs The last one seems the only feasible one (and also in line with what has been discussed in another meeting, namely the Y3 planning meeting, where it was proposed to give this "deployment" the status of a SA in Y3).

New profile needed for web clients

It was clarified that for perfSONAR it cannot be assumed that the client is a web browser. If it were, it would be possible to use the profile already defined by JRA5: the communication between the client and IdP would be TLS encrypted and the privacy of credentials would therefore be guaranteed. But since it is not, there's the need of JRA5 writing (in coop with JRA1) an additional profile. Particular care must be put in the definition of a credentials collection mechanism that ensures privacy of credentials from client to AS.

Other issues:

- It was agreed to progress on the eduGAIN to perfSONAR (primitives) mapping document initiated by Maurizio, taking into account the clarifications of the meeting. - JRA5 to provide JRA1 access to the SVN repository - JRA1 would like to put authentication handles in a SOAP envelope, not in the body. But this incopatible with SAML - Suggestion to JRA1 to have a look at SWITCH's documentation for Shibboleth installation : http://www.switch.ch/aai/ - JRA1 question about status of Attributes, Roles definition. JRA5: look at Schac effort within TF-EMC2 (http://www.terena.nl/tech/task-forces/tf-emc2/dir.html), and eduPerson (USA-oriented)

Action Points:

-Summarise meeting’ outcome Who: Stefan, Maurizio, Simon. When: 20 Jan

-Rework the perfSONAR/eduGAIN mapping document initiated by Maurizio (incl. steps diagram & API description) Who: Maurizio, Loukik, Jeff, Jose’Manuel, Diego Target: 28 Feb

-Start thinking of a “Shib” installation for eduGAIN (provide an effort estimate, list of what’s needed) Who: JRA1 people to look at Switch documentation (http://www.switch.ch/aai/). (Thomas Leggenhager may be contacted for help). Target: 15 Mar – Note: this was also discussed in the Y3 planning meeting in the afternoon)

-Write the profile for the automatic clients (credentials collecting problem) Who: Andreas Solberg, Jeff, Maurizio, Torbjorn Target: 28 Feb