"Damodaran, Suresh" wrote:
>
> 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
These are my initial thoughts.
The access control for creation of RegistryObjects should be determined
by
the access control policy of some other RegistryObjects ( particularly
if
there is parent-child relationship) between the RegistryObjects. This is
similar to the UNIX security. Where you need a write (w) permission on
the
directory to create a new file in the directory but you need a write
permission
on the file itself to modify the file. Likewise you need the w
permission
to delete a file.
So if you are going to require "submit" permission on a parent
RegistryObject
to create a new RegistryObject, then "remove" permission on a parent
RegistryObject
should also be required to remove an existing RegistryObject.
I am going to be leaving right now. So I won't be checking my email only
later
on tonight.
Sekhar
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:]
> Sent: Tuesday, September 04, 2001 3:21 PM
> To: Damodaran, Suresh
> Cc: 'Farrukh Najmi'; '';
> ''
> 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:]
> > Sent: Tuesday, September 04, 2001 3:12 PM
> > To: Damodaran, Suresh
> > Cc: ''; ''
> > 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: '';
> > > ''
> > > 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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
--
Sekhar
