New ideas on Authorization

Idea #1

Have a standard library, which developers must use when matching FAQN patterns OR existing code is reviewed and tested against a set of patterns (where replacement with library functions is not feasible)

We do agree.

Idea #2

Change rules for wildchar

• Wildchar are no longer supported OR
• Wildchar are only allowed after the trailing “/”. (e.g. /atlas/analysis/* and not /atlas/*/higgs or /atlas/ana* )

Among those choices, the best one is not to use wildcards at all, but to do just exact string match. Having a greedy wildcard is dangerous since it can then also eat roles, with confusing results.

Idea #3 and #4

• Support only groups (no more roles)
• Give the user more control over FQANs

In a sense, this is a return to the origins of VOMS. Early versions allowed a user to choose exactly which FQANs were present in the AC, but this ability was removed when the three following requirements came out:

1. DM wanted the ability to create ACL with a DENY component (even though this is clearly against best practices), and having attibutes that the user may deny clearly is a way to sidestep these ACLS.
2. Having users choose what must be included implies that the user must know exactly how the services that he intends to use are configured, something which clearly cannot be assumed.
3. Somehow, services could not be bothered to look at the whole list of FQANs granted by VOMS but would only look at the first, hence creating the hack known as "primary FQAN."

Any change in the way VOMS credential are created would require a removal/weakening of at least some of these requirements. Likely candidates are 1 (it goes against best pracatices) and 3 (It is an hack anyway, and some services at least are moving away from it). 2 could be handled by having a reasonable default be the current one, but giving full power to the user to alter that default.

-- AndreaCeccanti - 15 Nov 2007