[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Access control use cases
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC