[SAGA-RG] One final thing to agree upon for SD

[Burke, S (Stephen)]

saga-rg-bounces at ogf.org 
> [mailto:saga-rg-bounces at ogf.org] On Behalf Of Steve Fisher said:
> However I do think that in order to ensure
> that the API remains easy to use we should continue to allow the authz
> information to be taken from the security context - with the caveat
> that this may actually not make much sense with some authz schemes.

If you do that I think it should be possible to override it. Also as I
said before I think the behaviour must be clearly defined in the spec,
otherwise different implementations will not give the same result. (In
effect the security context becomes part of the API, just passed in a
non-standard way.)

> If this is accepted then the only problem is how to represent this
> information.

Something which isn't clear to me is the extent to which this is bound
to GLUE as the information model against which queries are made - and to
the extent that it is, whether it's 1.x or 2.x or both (to be useful I'd
suggest that 1.x support will be needed for some time). However, if GLUE
is a target then you clearly have to represent the information in the
same way as GLUE or the API will be useless!

  In glue 1.3 the authz information (AccessControlBaseRule attributes)
is just a set of strings, unordered, which are matched against some
template - if anything matches it's assumed that access is allowed, i.e.
the rules are ORed. However, the rule syntax itself is extensible, and
EGEE is currently in the process of introducing limited wildcards, hence
my suggestion to have an optional matching function so you can cope with
future extensions. (EGEE also introduced DENY rules as a hack, but it's
now been agreed that they shouldn't be used as a real solution.) As a
minimum, to be useful in EGEE/LCG as things are at the moment I think
you would need to support string-equality matching of VO names (e.g.
VO:atlas) and VOMS FQANs (e.g. VOMS:/atlas/uk/Role=Production), but we
already have more complex use cases, e.g. my example of the WMS-MyProxy
relation.

> To map it onto the GLUE tree structure

I think this is a bit misleading. The hierarchical structure of
UserDomains in Glue 2 is a way of representing information about the VOs
themselves, something which isn't present at all in Glue 1. That doesn't
directly have anything to do with how the authz rules are published.
Glue 2 in fact splits the rules into two types, AccessPolicy (real
authz) and MappingPolicy (which Share you will be mapped to if
authorised, relating to things like priorities and resource limits).
[This somewhat equates to the difference between LCAS and LCMAPS in the
VOMS world.]

  As things stand (subject to glue 2 not yet being finalised) those
Policy objects publish rules in much the same way as for Glue 1, except
that they are now in a separate object which has a Scheme attribute -
thus it becomes possible to explicitly name publishing schemes and to
publish independent sets of rules in different schemes for the same
service. (One question which I think is so far unanswered is whether
there's any requirement for rules in different schemes to be
consistent!)

  Of course, to be any use the schemes and their names will have to be
defined somewhere. At the moment the schema document defines what it
calls a "basic" scheme - however it currently contains a DENY rule which
I will (again) argue against when we discuss the final document, as IMO
DENYs are not at all basic and are hard to define consistently. At any
rate the SD API should presumably support whatever is defined for the
basic scheme once it gets finalised. Also it should probably cope with
at least the possibility of DENY or similar even if it doesn't end up in
the basic scheme.

  I would also assume that we will somewhere define an "EGEE" scheme
(although the name may be contentious :), which would be somewhat
similar to the current "basic" definition but would not have DENY rules,
would have a slightly different syntax to what is currently there, would
have limited wildcards according to the EGEE authz document, and may
also have some extensions, e.g. as we recently defined for MYPROXY
extended rules (authorised_retreiver et al). It should be possible to
encapsulate all of that in an EGEE-specific rule-matching function,
which I believe is anyway being developed within glite so the middleware
can match consistently.

  One other point is that the current GLUE 2 definition doesn't easily
support having ordered rules - I may raise that again as it can be
relevant, although it makes the model more complex. If you have ordered
rules and DENYs I think you potentially have four possible matching
cases: accept-and-stop, accept-and-continue, deny-and-stop and
dont-care.

Stephen
-- 
Scanned by iCritical.