saga-rg-bounces@ogf.org
[mailto:saga-rg-bounces@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.