On 10 Aug 2011, at 14:52, Mike Jones wrote:
> Firstly, regarding non-24h lifetime VOMS credentials:
> I've been sifting through the policy documents here:
> http://proj-lcg-security.web.cern.ch/proj-lcg-security/documents.html
> I cannot find any suggestion that a VOMS credential should or
> must be a maximum of 24 hours long.
To agree with detail:
There are VO's that have a 4 day limit on voms atributes; and at least one that has it set to 10 days. We observed no operational problems at 10 days, not did anyone raise any procedural difficulties with that.
> I agree that a VOMS AC should be able to be renewed as this clearly
> provides useful functionality at low risk, but one should not be able to
> do the following.
> running the following commands:
> $ voms-proxy-init -voms ngs.ac.uk
> $ voms-proxy-init -cert /tmp/x509up_u503 -key /tmp/x509up_u503 \
> -voms manchester.ac.uk
> $ voms-proxy-info -all
> I am subsequently authenticated as a member of the manchester.ac.uk VO at
> a grid resource which uses LCAS-LCMAPS for Authz and accepts both VOs.
> This is clearly broken as it takes away the control of the user to specify
> under which VO their job is to be run and accounted against.
> As such I think we have a problem.
I disagree that there is a problem here.
The gLite WMS JDL Attributes (https://edms.cern.ch/file/590869/) lists a VirtualOrganisation attribute, used to specify the VO the user wishes to run the job as. CREAM uses the same JDL reference, hence also (should) support that. (I can't recall of the top of my head how GT or Arc handle that, and I have no direct experience with Unicore or OSG).
A users certificate describes _them_, therefore having multiple VO's is perfectly resonable - I'm a member of 5 IIRC. If a middleware is making assumptions in the case of multiple voms attributes, that is a bug in the software. If it uses the presence of a single voms block to infer, that's reasonable, of course.
gLite has always been explicit about this case.
|