Paul: my usual disclaimer applies: it's just what I remembered.

Goals of work

1. We decided that we should take, as a "long term" goal, using only UIDs and GIDs for authorisation decisions.

For me (Paul), I took "long term" to mean "by release of 1.9.9", which is scheduled for 1st July (2010). (Timur: July 2010 sounds more like a target date for short term goal)

As part of this, the communication between components will only include UID/GIDs (as Principles in a Subject object). The only exceptions are:

1. communication between a door and gPlazma to establish the UID/GIDs for the user.
2. communication between a door and gPlazma to do the reverse lookup.
3. Other components (interfacing to end-users) that need to do the reverse lookup to present meaningful (to end-user) representations of UIDs and GIDs.
4. (did I miss anything?)

Step-wise progression

1. introduce the new Subject --> Subject interface in gPlazma, with the returned Subject containing all current information, including the mapped UID and GID(s) for the user.
2. we update all components to accept Subject as their authorisation context.
3. component by component we move to using only UIDs and GIDs: (Timur: the SRM migration needs to include SrmWatch migration.)
4. one of the requirements for Copenhagen to be considered a success is that pin-manager's persistence uses only UID and GIDs. (what about other components: how much can we get done?)
5. once all components are using only UID/GIDs for authorisation, we stop passing additional Principles (X500 DN, FQANs, Kerberos).

General observations

3. We identified that a session-ID is useful for logging. The credential mapping step (in gPlazma) can be logged against this session-ID.

4. It is desirable for the reverse lookup from gPlazma to allow the querying component (e.g., a door) to specify what kind of Principles it is after: a Kerberos-dcap door is only after Kerberos Principles. Alternatively, we can keep gPlazma interface simple and return all Pinciples: this is one of the open questions below.

Open questions

1. do we have the concept of a user NOBODY? If so, what should the Subject record for user NOBODY look like?
2. do we need to have a separate method in gPlazma for reverse-lookup: Tigran & Timur thought we did, Paul thought we didn't.
3. do we want the reverse lookup to include all reverse mappings (with the door being selective) or to allow the client to tell gPlazma which Principle types are desired?
4. (others?)

We'll dedicate most of the regular dCache team meeting to continue the discussion and try to organise another meeting for Thursday.