2008/10/22 Andre Merzky <andre@merzky.net>:

Quoting [Sylvain Reynaud] (Oct 22 2008):

...

Hi,

Why would a SAGA user want to discover services not available to his VO, if he can not use any of the SAGA-core object with these services? IMHO, enabling such use-case is fine, but a SAGA extension should first concentrate on enhancing the use of SAGA-core objects.

This is certainly a very valid question. It was included in my original design because I was following some of the notions of the current gLite service discovery API (though it is not much used except internally by data management).

+1

I also think that the results of the discover() call should, first of all, be usable within a specific saga session. As limited as a saga session object might be - discovering services which do not (easily) map to a session context will not be very useful to a SAGA programmer, IMHO.

This requirement is already satisfied because if you omit the "VO-filter" the information is taken from your context. The implementation of the API could select using any group or role information without it being visible in the interface

I understand that the SAGA notion of VOs and of authorization roles etc. does not map 1:1 to Glue's notion, but IMHO, a best effort should be made to align the SD package with SAGA semantics, as that is the context where it will be used.

...

Nevertheless, adding non-specified key-value pairs in ?vo_filter? is suitable for me, provided ?vo_filter' be renamed to 'authz_filter'. In doing so, we also keep the possibility to add them as full SD attributes in future versions of the specification as you suggest.

I think that this would make sense once we expand a saga session, or a saga security context, with similar attributes.

Cheers, Andre.

I think the main question is whether or not we should allow selection on authz info and whether or not we should even allow this information to be queried on a returned service. I can only think of 2 reasons to keep it. The first is to make the API useful to someone without a security context and the second is for an application wanting to collect information and make it available on a web page - i.e. republishing the information. Both of these are more relevant to other middleware components than to end users. I will ask a few gLite people to get their opinion. What do you think?

...

Sylvain

Steve Fisher a écrit :

...

Hi,

I have contacted those who made comments on the SD spec. They were happy with the proposals agreed upon in Singapore with the exception of the vo-filter. I thought it was worth bringing this point to the list for people to think about. Once this is fixed I will edit the document as agreed.

In the main spec the context has an attribute:

! // name: UserVO ! // desc: the VO the context belongs to ! // mode: ReadWrite ! // type: String ! // value: - ! // note: - a typical example for a globus type context ! // would be "O=dutchgrid".

Here it is quite reasonable to call it UserVO as it is in the session context, however for service discovery as the API allows you to find out about services not available to your VO then UserVO is not the most natural name and I prefer to leave it as VO (contrary to what I agreed in Singapore).

We also need to be mappable on to GLUE. The GLUE 2.0 document says:

In the GLUE Information Model, the Virtual Organization can be realized by using the concept of UserDomain. If the VO has an internal structure, this can be represented by using different domains related to each other. A Virtual Organization (VO) comprises a set of individuals and/or institutions having direct access to computers, software, data, and other resources for collaborative problem-solving or other purposes. Resources utilized by a VO are expected to be accessible via network endpoints and constrained by defining utilization targets called shares. The VO can exhibit the internal structure in terms of groups of individuals, each of them being a UserDomain. UserDomains can be hierarchically structured. This structure can be represented via the "participates in" association.

Sylvain Reynaud has said:

I agree for equivalence between VO and group, but I still think that filtering by group (or VO) is just an example of authorization filtering. Indeed, authorization does not always only depend on group (or VO) membership, even for grid deployments. For example, authorization may also depend on role (e.g. in LCG, access to tier 1 sites should be restricted to role "production" instead of the entire VO. See http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_queues_with_access_rest...), or it may depend only on UserID (e.g. Globus gridmap file). Then, how could we filter the services that are really accessible to the user? Moreover, I think that infrastructures that do not want to make efforts to match the SAGA Service Discovery specification should also be accessible through this API.

However I think that going this way leads to an API that can no longer be considered to be simple. One can of course use the key value pairs to show groups and roles and any other authz information if it is wished - so I propose to leave it as it is with just VO. If it turns out that groups and roles really turn out to be useful as key values then we can add them in later as full SD attributes - but it is more troublesome to remove them later.

Comments please.

Steve

-- Steve

Please note my new e-mail: <Dr.S.M.Fisher@gmail.com <mailto:Dr.S.M.Fisher@gmail.com>> ------------------------------------------------------------------------

-- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg -- Nothing is ever easy.

-- Steve Please note my new e-mail: <Dr.S.M.Fisher@gmail.com>

Hi, I have been discussing the need for authz filtering with people from EGEE. I will forward some of the e-mail shortly. They were of the opinion that user control of the authz filtering was essential if SAGA is to be used by other services (though I understand that this is not officially the role of SAGA). My feeling is that if it makes the API more attractive to a large body of users then it is worth doing. However it is still not clear to me just how to add the authz filtering. I have invited them to join the SAGA mailing list so that I don't have to act as a go-between. Steve

Steve Fisher a écrit :

Hi,

Hi,

I attach notes extracted from various emails between Akos Frohner, Stephen Burke and myself. Please read them before continuing ...

I trust you have now read them

I find that the set of use cases and other arguments in "thoughts on authz" convinces me that we do need to be able to specify the authz information explicitly. They convince me that the authorization filter is not only useful for middleware use-cases; it is also needed when information contained in session object is not enough to enable authorization filtering.

Nevertheless, most security contexts (including password and SSH security contexts) are used through a local SAGA object and have a UserID attribute, and I think the Service Discovery implementation should extract or deduce the authorization information understood by the discovery system from the session object when possible.

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.

Yes, I think we should. The authorization filter should be needed only when information contained in session object is not enough (and for middleware use-cases also).

If this is accepted then the only problem is how to represent this information. The draft spec says that you match against a "VO" however it says that the "VO" may in fact be any string and anticipates that a common use will be with the IN operator for eaxmple VO in 'CMS, 'ATLAS'). So I suggest simply changing the name of the field from VO to Authz and "VO Filter" to "Authz Filter".

Yes, and please also change the sentence about the default behaviour ("attributes of the context" instead of "VOs of the context" on page 11).

To map it onto the GLUE tree structure we could take all concatenations (perhaps separated by a "." of the name fields in the hierarchy of "User Domain" names. In practice I think it will be somewhat implementation dependent because different grids will use these fields in different ways. This set of concatenations would be the set of valid Authz values. It will not guarantee that you can use the service but can we do better and still keep it simple?

I think we don’t need to guarantee that we can use the service when the authorization filter is set. However, it would be fine to guarantee this when using the default behaviour. To enable this, the specification could tell that an exception MUST be thrown when the authorization filter is not set and the session object does not contain enough information to filter the services accessible to the user. The user will still be able to deactivate authorization filtering by providing an empty authorization filter, and then he will be aware that he may not be able to use the discovered services. Sylvain

Steve ------------------------------------------------------------------------

-- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg

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.

Steve Fisher a écrit :

Hi,

Hi Steve,

After discussing this we do not have a perfect solution. It has been pointed out that it is difficult to represent the authz information in a grid independent manner. However I would like to get the spec out. If after implementation and practical experience it proves to be be not suitable we will just have to come out with a new version.

So I propose to make the authz filter more like the other filters except that the attribute names will not be defined in the specification.

... and except the authz filter can be omitted. Do you keep the possibility to automatically create a default authz filter with the attributes of provided SAGA contexts, when the authz filter is omitted ?

I would suggest that we recommend some names such as 'VO', 'Group' and 'Role' while admitting that different implementations may choose different interpretations of these attributes. I would also remove the 'VO' as an attribute of a service. For example an explicit, but simple, authz filter might be:

VO='atlas' AND Role ='Production'

For EGEE/gLite it seems that the authz rules might be rather complex expressed this way so we may provide a function to convert gLite authz rules to this format. However this is gLite specific and will NOT be part of the spec.

If I hear no objections I will recirculate my list of changes to make to the current version of the spec - and then start work ...

It's OK for me. Sylvain

Steve -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg