Hi Paul,
[...]
Yes, absolutely right: one can mark-up the ACL entries. This gets around the "identifying the rules" problem, but creates another one. It would require the client to hold some database of known ACL schemata (AFS vs NTFS vs...), along with a mapping between user operations and corresponding required ACE entries for each of the supported ACL schema.
Not each, just the ones it cares about. Analogy: a product wrapper may have the same text in multiple languages - just pick the one(s) you understand. The texts need not even be equivalent, e.g. because of different laws or cultures in different countries.
Moreover, since a site might publish authz info with any (valid) ACL format, a client must be able to understand *all* potential ACL formats and how the
Here I do not agree. A client can simply ignore stuff it does not understand.
Perhaps, as a fall-back policy, a client can simply "try its luck" and see whether the operation succeeds.
Right. If the understandable information did not rule out success, the client might give it a try.
For example, we now publish both "VO:atlas" and "VOMS:/atlas" ACBRs, the latter being ignored by old clients.
Whilst you're quite correct in saying that publishing both "VO:atlas" and "VOMS:/atlas" allows for backward compatibility, I suspect that this is a special case.
In general, one cannot precisely map an ACE from one ACL schema to another; for example, what POSIX ACE should be published for the following AFS ACE? GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::lkd
There is no need to map it to another ACL schema. The service is saying: if you happen to understand AFS ACLs, I can tell you that the given DN has "lkd" permissions. (There should be a schema prefix like "afs:").
A service can support multiple interfaces.
Yes, but only if the service happens to support both interfaces, and this is only helpful if all clients understand at least one of the interfaces.
The equivalent would be if a filesystem happens to support multiple ACL schemata (e.g., both AFS and NTFS ACLs) so both could be published. This may be technically feasible (anything's possible!), but I doubt any filesystem supports more than one ACL schema.
I should have been clearer. In my GLUE example the "posix"/"afs"/"ntfs"/... schemas need not mean that the server actually runs such a file system or equivalent: I used the schema to define a policy _language_.
[...]
If we want to publish an authz mapping between users and a service, I feel it should be at a VO level. What are the use-cases for *publishing* finer-grain authorisation? ...and are they reasonable?
We already have finer-grain authorization today, viz. per VOMS FQAN, and that is certainly what e.g. ATLAS and LHCb are expecting.
Ah! But these aren't really ACLs as don't specify the permitted operations.
The operations are implicit: posix:rwx afs:rlidw(a) ntfs:rwxd(p) More interesting ACLs might look like this: srmv22:/someVO/admin:rw srmv22:/someVO:w They would be for a space that can be used as a write buffer by the whole VO, but as a read buffer only by privileged FQANs within the VO.
They're more like the mapping between user-community and some object within the Glue schema. This is more what I meant by at a "VO level": (sorry, I should have used the term user-community or "UserDomain").
Moreover, MyProxy servers even publish the individual DNs that they trust!
Ah, sorry, I don't know enough about MyProxy, but isn't this a trust issue rather than one of authorisation?
It is another illustration that the VO level is not fine-grained enough for GLUE.