[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Access control use cases
"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: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 > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- Sekhar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC