I try to summarize here e-mail discussion in June 2007. Feel free to fix this

• focus on short term: what ATLAS/CMS needs until end of 2007, based on existing tools
• starting facts (not necessarely full picture, but we assume these in defining what to do)
  • for WMS scheduling only primary group matters
  • for storage: secondary groups are understood by DPM, but not other tools yet
  • one is always member of the "base group" i.e. that of the VO, having no group membership is not possible
  • user specify one role within one group
  • roles granted in a group are not automatically transfered to it's subgroups , it has to be explicitly granted in the subgroup, as well.
• note on semantic
  • in the end groups and roles are sort of misleading names, what it matters is the "purpose"
    • one user can belong to many groups at same time
    • one user may only wear one particular role at a given time

Summary from Sciaba' and Lithmaath

On 06/25/2007 04:03 PM, Andrea Sciaba' wrote:

talking with Maarten it has become evident that the current usage of VOMS for job priorities and data management leads to some problems (which I hope may be solved without too many changes to the middleware, if any).

For job priorities, as we all know, what matters is the primary FQAN, specified at proxy generation. In this context, it is a pure matter of taste to map priorities to groups rather than roles or combinations of those.

For data management, different behaviours are conceivable:

• 1) the user rights are obtained by joining the rights granted by each FQAN in the proxy; this is now the case for DPM;
• 2) the user rights are obtained by joining the rights granted by a specific subset of the FQANs in the proxy;
• 3) the user rights are those granted by the primary FQAN in the proxy.

The solution 1) was motivated by the fact that it is reasonable to have also the rights associated to /atlas, even when one uses an /atlas/Role=production proxy. On the other hand, as Maarten pointed out, it does not allow to switch off privileges associated to a certain group, thus forcing people to use roles (which can be switched off). The solution 3) has the problem that the same FQAN (the primary) is used to determine the job priority and the data access rights, which are inherently different things. The solution 2) needs a mechanism for the user to specify which particular FQANs in his proxy he wants to be considered to determine his access rights.

In my opinion, there should be a way to separately define the FQAN used for the job priority and the FQAN(s) used for the data access. The best thing would be to embed this information in the VOMS proxy alone, but I don't know how to do it.

Just to clarify, this problem does not to be solved in a short time, and has little to do with the job priorities themselves, but it has to be solved eventually.

Comments

Jeff: I agree ... the version of #2 that i favor involves adding an optional argument to commands / interfaces:

edg-job-submit --fqan /atlas/Higgs/Role=busboy clean_the_floor.jdl

Stephen: IMO the middleware should provide independent ways to say what action you want, then there would be no conflict, you would ask separately for some job priority and some data management action (and some R-GMA access, and ...). Each piece of middleware would then check the proxy for whatever it needs to grant permission, which might be different in each case or might be the same.

Vincenzo: Remember this: No one said that you have to use the same attributes for different purposes. You may have some that are used for priority, and some that are used for data management. No one ever said that there must be intersection among the two sets.

-- StefanoBelforte - 26 Jun 2007