[glue-wg] Comparison with CIM

[Maarten.Litmaath at cern.ch]

Hi Owen,

> > > I would suggest you all consider that wLCG should first agree on a
> > > format before we try and put it in GLUE, I hope you agree?
> > 
> > No.  GLUE should allow the _notion_ of ACLs to be expressed where they
> > might reasonably be needed.  And we already have ACLs, namely ACBRs.
> > They do not impose particular semantics. 
> 
> I would suggest ACBRs are incomplete and not rich enough to be of much
> use, mainly because they do not impose particular semantics, and map
> poorly to a ACL, so as to be misleading.

I think we agree after all: I was not suggesting we support anything new
beyond allowing for another ACBR schema, which we already do by design.

We probably would need significant discussion and/or practical experience
with ACLs before we could represent ACLs with their own set of attributes.

An example mixing grid authorization notions with POSIX ACL syntax:

    GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx
    GlueAccessControlEntry: /someVO/Role=admin::rwx
    GlueAccessControlEntry: other::r-x
    GlueAccessControlEntry: default:user::rwx
    GlueAccessControlEntry: default:group::rwx
    GlueAccessControlEntry: default:other::r-x
    GlueAccessControlEntry: mask::rwx

Or with AFS ACL syntax:

    GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rlidwa
    GlueAccessControlEntry: /someVO/Role=admin::rlidwa
    GlueAccessControlEntry: other::rl

Or with NTFS ACL syntax:

    GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwxdpo
    GlueAccessControlEntry: /someVO/Role=admin::rwxdpo
    GlueAccessControlEntry: other::rx

Or yet some other schema, or a combination of schemas...

> [...]
> 
> Do you agree that white listing is an alternative justification for LHC
> experiments enhancing GLUE to their own needs? 

Yes, I agree that VO annotations would be cleaner than the FCR hack that
is in use today.  Something for GLUE > 2.0.

> [...]
> 
> Please don't confuse GLUE as a mechanism to declare that services exist
> with the concept of services will be used. White listing of sites is
> even performed by the VO EGEE. (we call it SFT's) 

Yes, but it is not very nice to design the information system as having
incomplete information as a principle!  The idea is that a client should
not have to bother a service too quickly, to find out if its request has
a chance of succeeding.  If some VO is not advertized as being supported
by a particular service, a client representing that VO knows that it need
not bother with that service.  In the case of ACLs the issue is how fine-
grained the information needs to be.  Maybe it is sufficient to know that
the VO or VOMS FQAN in principle has the desired access, and that further
details can be obtained by querying the service directly.  Or maybe that
service would then find itself being queried all the time, because the VO
does not remember the information, because it does not want to create its
own information system!

> [...]
> 
> I am yet to see a use case for ACL's within GLUE, not covered by
> experiments own whitelists, maybe people advocating them are not
> justifying the case for them in GLUE adequately for me to understand or
> their is no reason to include them in GLUE. 

Whitelists normally are not sufficiently fine-grained.  They typically
amount to usable-unusable distinctions, viewed from the VO as a whole.
An SE may be declared OK, but then you still may need to find out which
path to use for a particular space if you have a particular VOMS FQAN.
That information happens to be published already in 1.3, but maybe we
will find it is not enough.  Anyway, if I had to choose today, I would
not invent namespace objects for 2.0, as they would complicate queries
and I find the use case presented not sufficiently well-established,
but rather a (hopefully) temporary weakness in the current state of
affairs in SRM v2.2 land...