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

["Takashi Kojo" <tkojo@mvi.biglobe.ne.jp>]

Phil,

> 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,

Thank you for your comments.

> 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.

So VO is a virtual domain you can create as you need.
VOs are independent and don't have any direct relation among
them regarding with security.

I agree it is a reasonable assumption for the initial discussion.


> 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 ... ;-)

I wouldn't think of myself that harmful.
Perhaps, I should sit down and be good for a while. :-)


>> - 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.

I agree with the Extra-grid assumption.


>> - 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

This gives me some idea about VO attributes. Thanks.

>> - 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.

The smallest granularity I could think of at this moment is a grid service.
So a VO would be along with a service or service collection.
That would be interesting idea.

>> - 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...

My initial thought was that VO just represents a set of entities
of multiple real organizations as its attribute. Which users or
resources belong to the VO, etc. But if you extend and generalize
"etc" part to all security attributes, you are right. It would be
synonymous.


>> - 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

Thank you, Phil. I think my understanding is elaborated a bit.
For over all, the VO is more dynamic and generalized than I thought,
but I prefer the idea.


Kojo
--------
p.s. Kojo is my last name, but somehow everyone call me simply
Kojo, and I like it.