RE: Access control use cases

["Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>]

I have explained this in my first email.
Again in some more detail:
When you do submit for a RegistryObject that is already in the registry,
you can specify access rights to the item using UUID of the RO (including
"submit" rights, meaning update rights)
When you are creating a new RegistryObject, then the submit operation
has to be "permitted" looking at the access control policy
of some other RegistryObject (alternately, we simply state any SO can
submit a RO and define away the problem)
Hope this makes sense - Suresh

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
Sent: Tuesday, September 04, 2001 3:21 PM
To: Damodaran, Suresh
Cc: 'Farrukh Najmi'; 'regrep-security@lists.oasis-open.org';
'sekhar.vajjhala@Sun.COM'
Subject: Re: Access control use cases



Can you explain how Submit being used in both cases causes a problem. I may
not respond right away as I have to
leave shortly.

"Damodaran, Suresh" wrote:

> The problem is not with save and update being done in the same operation -
> rather "submit" being used for both update and to create a new entry
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@sun.com]
> Sent: Tuesday, September 04, 2001 3:12 PM
> To: Damodaran, Suresh
> Cc: 'regrep-security@lists.oasis-open.org'; 'sekhar.vajjhala@Sun.COM'
> Subject: Re: Access control use cases
>
> Save and Update being done using the same operation is not unusual. UDDI
> does the same thing.
> Does this present a problem from an access control perspective?
>
> "Damodaran, Suresh" wrote:
>
> >  Here is the use case that I am planning to submit to XACML COB
> > today.Please comment.Some  issues:1. How do we attach an access
> > control policy for submitting a new RegistryObject?Should we allow all
> > Submitting Organizations to submit RegistryObjects? In the use case,I
> > have not mentioned "submit" operation in teh use case attached.2. If
> > "submit" is used to "save/update" a RegistryObject, then the access
> > control requirementswill de different while creating a new
> > RegistryObject vs. updating an already existing one. For a new RO, we
> > use whatever we comeup with (1) above, and for the existing, we create
> > a "update"operation. Creating a new operation is a problem for Object
> > Management Service? There must besome reason why update was not
> > considered an operation?Thanks,-Suresh3. I have not created Roles in
> > the use case, though we need to have it for ourselves.
> >
> >      -----Original Message-----
> >      From: Damodaran, Suresh
> >      Sent: Tuesday, August 28, 2001 10:05 AM
> >      To: 'regrep-security@lists.oasis-open.org';
> >      'sekhar.vajjhala@Sun.COM'
> >      Subject: Access control use cases
> >
> >      Farrukh, Sanjay, thanks for your comments on the access
> >      control ops.Let me take it further. Please comment.The
> >      things that need to be done to complete the access control
> >      usecaseare:1. Enumerate the resources (in our case object
> >      types) that we want access control on    Farrukh, you may be
> >      able to talk about how RIM changes will impact this.2.
> >      Identify the actions on these resources :    There is
> >      consensus that we tackle         -life cycle
> >      operations        - read operation        - update
> >      operation    for V2. 3. Map to "Roles" or "Groups" the
> >      security actors (btw, mapping the security actorsto
> >      mainstream registry actors is an issue). As an example,
> >      Registry Publisher is anunambiguous actor from the security
> >      point of view (i.e., we cannot confusea Registry Guest from
> >      a Registry Publisher) [Farrukh had mentioned that Registry
> >      Guestcan also publish in the registry - in that case we
> >      can't make any distinction! - my thinkingis that we we
> >      separate roles as we fit now, and later combine the roles -
> >      comments?]4. Think of any preconditions for access as well
> >      as any post conditions that need to besatisfied after the
> >      access.Sanjay, I am hoping that the usecases for access that
> >      you are working can be expandedalong these lines. If you
> >      take some preliminary steps along these lines, it should
> >      help us.Cheers,-Suresh
> >
> --
> Regards,
> Farrukh

--
Regards,
Farrukh