Re: PolicyEvaluatorAdmin

[Konstantin Beznosov <beznosov@baptisthealth.net>]

Hi,

Let's discuss this topic during the conference call.

I think, Carol and I (and probably others) have different models of use in our
heads and this is where our disagreement is coming from. We need to accommodate
all of them instead of trying to argue whose model is THE RIGHT ONE. I'm sure
several years from now we will be surprised to learn how and in what scenarios
people actually will use this service.

Konstantin

> At 07:51 PM 10/13/98 -0400, Konstantin Beznosov wrote:
> >
> >I would suggest that those systems that do not identify/use separate
> policies,
> >they just ignore the policy name.
> >
> Access control systems might "use" separate policies without naming them,
> but your suggestion -  that you "ignore" the policyname in the
> PolicyEvaluatorAdmin
> methods highlights my point - the interface is useless for the purpose that
> it is intended when the underlying system does not provide public
> names/identity for policies... 
> 
> I prefer to address this when we deal with the mandatory requirement -
> Proposals shall provide an interface for defining access control rules for
> secured resources based on credentials as defined in the CORBA Security
> Specification.  
>  
> >> In addition, it begs the question of how a healthcare software vendors
> >> product would understand how to select an appropropriate policy from a
> >> list of named policies provided by HRAC.  
> >
> >What product? An ADO client?
> >
> Any software that creates secured resources dynamically and wishes the HRAC
> to provide subsequent access decisions for that secured resource.  The
> "application" to which this software belongs is likely to be a client (at
> some time) to the ADO.  This is the context of the discussion we were
> having during the definition of the PolicyEvaluatorAdmin interface in
> Austin.   For example, at the time of creation of a sensitive resource the
> software that creates this resource might wish to tell the HRAC to only
> allow access by the access_id that
> created the resource.  As currently specified,  this PolicyEvalutatorAdmin
> client would have to know the name of the policy that allowed access only
> by the creating access_id.    I'm not comfortable with the burden that
> this places
> on the application who is trying to use the HRAC for access decisions.  I
> know you don't think that Healthcare will have this requirement for
> dynamic definition of access policies, but I'm equally convinced that you're
> wrong.  :-)
> >> 
> >> My proposal: I would like to remove this interface from the initial
> >> submission and revisit the entire subject of how to allow an application
> >> to define the access policy for a dynamically created resource for the
> >> final submission.
> >
> >I suggest to leave it the way it is now and see what other people (i.e.
> outside
> >of the submission team) comment on it.
> >
> We disagree.  Obviously you have a different usage in mind from what I'm
> thinking... enlighten me.  At the moment I think the interface (as
> specified) is at best underspecified for the problem it tries to address
> and at worse broken and not useful in practice.   I'm not looking forward to
> trying to explain it as part of the initial submission.  So if we leave it
> in, someone else will have to defend it  ;-)
> 
> Carol
> _________________________________________________________
> Carol Burt                                             2AB, Inc.
> cburt@2ab.com                                     Integration Architects
> 205-621-7455                                        www.2ab.com
> Member, OMG Architecture Board          OMG Domain Member
> 
>    --  integrating yesterday's systems with today's technology --


----------------
Broadcast message to hrac-rfp from Konstantin Beznosov <beznosov@baptisthealth.net>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.