Re: [ggf-ogsa-sec-wg] VO consideration

[Philippe Janson <pj@zurich.ibm.com>]

Kojo-san,

These are all very good questions to
which I am afraid we do not yet have complete answers - in fact getting
those answers is part of what we need to do to finalize the roadmap and
archietcture docs.
I offer some more comments below.  Rgds,

Phil Janson, Ph.D.
------------------------------------------------------------
IBM Academy of Technology            smtp:
pj@zurich.ibm.com
IBM Zurich Research Lab        http://www.zurich.ibm.com/~pj
CH - 8803 Ruschlikon                
    Fax: 41 1 724 89 53
Switzerland                  
           Tel: 41 1 724 83 42    
------------------------------------------------------------

owner-ogsa-sec-wg@gridforum.org wrote on 2002/10/25
04:08:51:

> Greetings,
> 
> While reviewing "The Security Architecture for OGS",
> I got several questions. One of them seems somewhat fundamental.
> The discussion might ave been done somewhere before. I would 
> appreciate pointers to refer to.
> 
> The question is
> What is the definition of VO with regard to OGSA Security, 
> which was described in the introduction.
Wherever you look in grid literature you find no single
unified and formal answer to this question.
IMHO a VO can be regarded as a virtual security domain
that straddles several real security domains.
Virtual precisely in the sense that it gathers users
and resources from several real organizations.
And security domain in the sense that users in that
domain have privileged access to resources in that same domain because
they both belong in the same VO domain of which the purpose it precisely
to share the included VO resources among the cleared VO users.

> 
> My motive is to find out if/how the VO model is sufficient enough
> to deal with real use cases of the grid regarding with grid security.
Brian Carpenter and I did some more work along thoe
lines last month, which Brian is currently documenting in a write-up he
will likely share over the coming weeks.  We have come to a certain
amount of confidence that this VO model is sufficient at least for extra-grids,
though we have to put it to the test of the distribution list to get confirmation
and buy-in on this.  I would not yet put my head to cut on this ...
;-)

> 
> - Would a single layer of VO be sufficient enough?
>     to deal with levels of trusted users or VOs...
For extra-grids, that is the idea.  Inter-grids
may require more - we have not done the homework there and need more requirements
and scenarios to understand.

> - How do you set up/modify the VOs with which authority?
>          or maybe can you partially define
them statically, too?
>       What would be a set of services of VO manipulations?
According to the view that Brian and I sketched, this
would require some minimal static definition to get started.  Then
users and resources could be added dynamically.  Typical services
would be add/delete user, add/delete resource, add/delete real group, add/delete
resource group, etc.  Much detailed work t.b.d along these lines

> - What would be a granularity of VO configuration regarding with timing?
>             By command lines, sessions
or more overall agreement between
>             VOs?
Overall agreement is more what we had in mind, with
possible dynamic extensions downward in time, but this remains to be tested
on the distr. list.

> - If the VO manipulation represents dynamic aspect of policy/trust
> definition, how much should be handled by policy/trust and by
> VO manipulation?
The two are pretty much synonymous in my mind: creating,
deleting, extending, shrinking or otherwise manipulating a VO are indeed
all policy/trust setting operations - maybe I am missing the gist of your
question...

> - What would be real organization(RO) policy/trust and VO policy/trust?
Quite similar in abstract syntax and semantics but
bearing on different objects with different scope in practice.
Just as a security officer in some RO could set policies
like users in (previously defined) group G or with (previously defined)
attribute A have access to resources in (previously defined) pool P,  so
could a security officer in the same RO involved in a VO V set policies
that (external) users with membership in V are authorized to access local
resources in the (previously defined) pool Pv.  Each RO security officer
can define which of his real local users and resources are cleared to be
in V.

Hope this helped clarify our thinking.  I am
about to go on leave for a while but would otherwise be very interested
in feedback on this sort of thinking.  Brian will be glad to collect
that for us all in the meantime.  Rgds.  pj

> 
> Kojo
> 
> ----------
> Takashi Kojo, NEC, kojo@bk.jp.nec.com
>