RE: Access control use cases

["Patil, Sanjay" <SPatil@iona.com>]

I guess combining update and submit helps simplify the API.
However, on the Registry site, distinction between the two
operations can be made and respective Access Control policies
be refered. 
Also, by implicitly authorizing "submit" operations, we can
avoid Access Control for "submit" operation. However, this will
require
1> expanding the authentication of the SO into two steps now -
   identify the SO as a registry user and then identify the registry
   user as a SO. 
2> the registry access mechanism needs to support provision for
   an accessed to present his identity as well as credentials i.e.
   I am such an organization and I am a submitting organization. 
   The registry then verifies both ID and the credentials.
   Other alternative is the Registry to lookup for credentials
   given an ID, however this will make registry access expensive
   and at the same time limit an ID to take on different roles.

thanks,
Sanjay Patil
----------------------------------------------------------------------------
------------------------------
IONA
Total Business Integration (TM) 
Phone: 408 350 9619                                 http://www.iona.com


-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Tuesday, September 04, 2001 1:33 PM
To: 'Farrukh Najmi'
Cc: 'regrep-security@lists.oasis-open.org'
Subject: RE: Access control use cases


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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>