[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PolicyEvaluatorAdmin



Hi,

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 Carol Burt <cburt@2ab.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.