OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-security message

[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