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

[Steve Fisher]

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/saga-rg/attachments/20081017/e49cdc6d/attachment.html