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

[Steve Fisher]

2008/10/22 Andre Merzky <andre at 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_restricted_to_a_FQAN),
>> > 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 at gmail.com
>> > <mailto:Dr.S.M.Fisher at gmail.com>>
>> > ------------------------------------------------------------------------
>> >
>> > --
>> >   saga-rg mailing list
>> >   saga-rg at 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 at gmail.com>