[glue-wg] Open enumeration values for the generic service provider

[stephen.burke at stfc.ac.uk]

Florido Paganelli [mailto:florido.paganelli at hep.lu.se] said:
> GOCDB people will not be happy, but I would like it to be changed the 
> same as the InterfaceName.

I've submitted a bug, so I'll change it unless there is disagreement. The list of types should still record VOMS as a deprecated value.

> I think we should decide a way to define these policies, I mean 
> instances of them, or a canonical way of representing them...
> 
> I think the description in GFD147 is vague, and on the other hand it 
> would be nice to have some kind of "library" for these policies to be 
> reused by coders.

GFD 147 is deliberately vague because the policy Schemes are supposed to be extensible - in effect they are a more elaborate version of an enumerated type, and should be documented in the same kind of way. The same logical policy could be expressed differently in different Schemes, and it's open to implementations to support more than one Scheme if they choose.

  It may be worth saying at this point that I've been commissioned by EGI to write a profile document to specify the usage of GLUE 2 objects and attributes in EGI - I hope to have a first draft by the end of the month.

> Can you sketch a definition that is consistent with GFD147 for GLUE2? 
> maybe we can use that as an example for future policy definitions.

One aspect is forced by the structure of the schema, that the Rules are an unordered list - I think we considered what we would need to specify an ordering and decided it would be too complicated. This is a non-trivial point since the security rules on the services (LCMAPS etc) are in general evaluated as an ordered list, so the real mapping may not be representable in GLUE (also the rule sets may be too long to publish in a practical way).

  The general principle is that you apply a matching algorithm between each Rule and the credentials of the user. If any of the Rules match then the overall result is success, otherwise failure. Success means the user is likely to be authorised (AccessPolicy) or mapped to the associated Share (MappingPolicy) - "likely" because this is not a decision point for security puposes, so the actual security rules on the service will always take precedence. 

  The format of the Rules is:

o A DN (in the usual string representation) which matches against the user DN.

o ALL which always matches.

o NONE which never matches.

or has the form <type>:<string>, where the interpretation of <string> depends on <type>:

o VO:<vo-name> matches if the user is a member of VO <vo-name>.

o VOMS:<fqan> matches if the primary FQAN of the user (if any) is <fqan>. This might get extended to allow wildcards if it ever gets implemented.

o MYPROXY:<myproxy-rule> matches according to the rules defined for myproxy configuration.

Any format unknown to the client must fail to match but not be faulted, hence new <type>s can be added without breaking backward compatibility.

All matching is case-sensitive as implied by the schema.

Stephen
-- 
Scanned by iCritical.