glue-wg-bounces@ogf.org

[mailto:glue-wg-bounces@ogf.org] On Behalf Of Florido Paganelli said: Which of those have a single endpoint? all of them but Argus and VOMS?

Also org.glite.ce.Monitor org.glite.ce.ApplicationPublisher are normally part of CREAM, which I think publishes a ServiceType of org.glite.ce.CREAM (the Service publisher in that case is part of the CREAM distribution).

ok so during the last ServiceType_t review we decided that org.glite.voms was a ServiceType_t, is that an error?

VOMS is what's in the code at the moment. It can be changed if that's the decision; as usual that will mean we have some period where both forms will be in use, but since nothing is likely to be relying on it yet that shouldn't be a problem.

Any remark on this org.glite.standard?

It's the format we've been using in glite for GLUE 1 AccessControlBaseRules. I think the only formal description is here: https://twiki.cern.ch/twiki/pub/LCG/WLCGCommonComputingReadinessChallenges/W... page 33. For GLUE 2 we should not allow the deprecated form b), i.e. a bare VO name. The wildcard format has so far not been implemented. In addition to that, for myproxy we publish rules with a prefix MYPROXY:, e.g. GLUE2PolicyRule: MYPROXY:authorized_renewers=/C=DE/O=GermanGrid/OU=DESY/CN=host/grid-lb2.desy.de (actually I just spotted a bug, at the moment there's a trailing " which shouldn't be there). For GLUE 2 we also have the reserved word ALL meaning no authorsiation, and for Argus I added a new reserved word NONE meaning no access (for users, Argus is used only by other services). Stephen -- Scanned by iCritical.

Florido Paganelli [mailto:florido.paganelli@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.