[Draft] expected FAQ on my draft

[Carol Burt <cburt@2ab.com>]

Hi,

Ok... nothing like being critical of your own work... or having co-workers
do it for you!  a few questions that came up in review of this here at 2AB...

1) where are the exceptions?  

Obviously missing... my personal preference is to agree on the model,
interfaces and operations before trying to sort out what the appropriate
exceptions are... this is after numerous experiences discovering leftover
unused exceptions at the end of an exercise... yes... they must be added.

2)  You don't seem to address Bob Blakley's question of where the
AccessDecision object obtains a reference to the AccessPolicy object.

An oversight.... I'd propose that a ResourceDef contain a reference to the
policy object.  Now all we need is to decide where it gets a ref to a
ResourceRepository.  I'll add that to the idl.

3) Why is ResourceType a string instead of a more strongly typed enum?  

It was to make the ResourceNameComponent structurally identical to a
CosNaming::NameComponent, but I don't feel strongly about that.

4) The ResourceType const's BASECLASS and SUBCLASS are misleading
terminology... more often than not the relationship will not be as this
implies.  You should also state that the rules down the tree should be
subsets not subclasses.

Ah yes... I struggled with these terms... CLASS was short for
CLASSIFICATION, but I tend to agree the terms are misleading.... so what
has been suggested is ROOTNODE and NODE.  Anyone have a strong opinion?  I
could go either way.  Yes, the rules should be subsets, not subclasses...
I'll change it

5) The model follows the CORBAsec model, but do you really want to expose
these interfaces, or do you want to factor it into a read-only interface
for getting rights (both required and granted/denied) and an Admin
interface for managing/configuring rights.


This is actually how our (2AB) original model was drawn.  The work I did
here was to understand the relationship to the access model in CORBASec and
be sure the architecture of the proposal was complementary. (AB hat on).  I
actually think we should consider factoring the interfaces into
RightsAccess and a RightsAdmin interface...  if we did this, they would be
the IDL interfaces in the spec and the model we've shown would be
encapsulated as part of an implementation.  What are the advantages of
doing this?  
a) It is less costly in administration and in runtime to apply CORBASec at
the Interface level rather than the operation level.  For this reason, I
typically prefer to factor interfaces such that read operations are
separate from administrative operations. 
b) when we talk about conformance levels, it would be possible to define a
conformance level that supported the RightsAccess interface, but not the
RightsAdmin interface.  This would allow a vendor who has an existing
access control product to do a minimal wrapping that would allow rules to
be exported for other use without requiring that they wrap their
administrative tool.  I think this might be useful for some vendors and
would encourage a phased approach to full compliance.
I don't feel really strongly about this, but would like to hear from others.  

6) How do you federate ResourceRepositories?  Suggest you look at creating
federation in a similar manner to the NamingService  (having a
ResourceContext that is equivalent to a NamingContext and binding them into
arbitrary graphs)


Hmmm.... I haven't followed my IDL to see if Federation actually works, but
at one point I actually had an interface called ResourceContext for
creating the graphs when there is structure.  I will take this as homework
to see if the ResourceRepository federates naturally as currently
proposed.... I haven't thought about this enough.

7) Suggest changing the operations create_resource_def to add_resource_def
and delete_resource_def to remove_resource_def.

Whatever... sounds ok to me.

8) Why did you decide to avoid the opaque for the ResourceName?

Because although we all know that inodes exist in file systems, it isn't
how users are allowed to interact with them.... basically the internal keys
used by applications and/or HRAC to identify a resource would have to be
mapped to a name for administrative purposes anyway... exposing both the
name and the key in public interfaces would make them brittle in my opinion.  

9) What happens if a ResourceName is changed in a hierarchy?

I propose that the hierarchy holds.  this is identical to what happens if
we rename a directory in a file system.  Although the name is how we deal
with the resource in public interfaces,  it is not the resource itself and
changing it doesn't change the resource... only the name.  Strings will
allow us to use NamingAuthority::QualifiedNameStr for the root of any
hierarchy (and for atomic resource names if we wish although I didn't go
that far) which are used by other CORBAmed facilities (PIDS, Lexicon,
COAS?) and this should be a familiar naming scheme to CORBAMedical
implementations.  I have no problem with exposing operations to rename an
existing resource in ResourceDef (if we do this, we should discuss whether
to create an ALIAS resourcename type that can be inserted in a hierarchy).


10) What about sensitivity levels associated with a resource -- do they
exist and what role do they play in access decision? 

I am not at all sure that I follow this thread... so at this point, I'd
like to see a use case of how "sensitivity" labels are currently used in
access control.  If I understand IBM-Bob's comments, then I think that it
might be handled in a similar manner to the way I proposed an evaluator for
dynamic properties...which I think is consistent (but not identical) to
what he calls a metadata service).  One comment: IBM-Bob seems to imply in
this thread that the resource is always an object (see comments on
re-entrancy and self-referentiality)... I suggest that although it could
be, our experience with a similar service in telecom is that the "resource"
is quite often not represented as an object in any sense (CORBA or language). 

11) Your approach to supporting Dynamic Priviledge attributes is different
from IBM-Bob's in that he states the meta data service is encapsulated
behind the HRAC and not exposed -- you expose a DynamicAttrEval object.

If I understand his proposal, this is Correct.  If I do not think that it
is practical to hide this metadata service.  It must be configured with
information only known to the application which means keeping copies of
relationship information external to the application and hidden proprietary
interfaces for getting this into the HRAC.  I think who developes this
logic  is best decided on a case by case basis.  By exposing the interface
a Dynamic Attribute Evaluator could be written by the application vendor,
the enterprise, or the HRAC vendor based on the needs of a particular
enterprise.   It could be external to an existing application offering, it
doesn't have to be a  "mix in".  

====================
In Bob's IDL, he again makes comments that imply that a "resource" has an
operational signature.   I think this deserves some attention as I'm not
sure I agree and I think that this is critical to making sure that we
provide an access control system that is easy to use.  Notice that i
replaced the term "operation" with "intent".  That is because I think that
intent is what people want to assign rights based on.  For example, take
the case where the resource just happens to be a CORBA Interface.  If I
want to provide security at the interface level, then in my view "intent"
might be "all", or some application could define "intent" of
"emergencycare"... (obviously these have to be assigned with the
required_rights).  This would imply that there is *not* a one-to-one
mapping from the "operational signatures" of an interface to the intent
that is specified in the interfaces (although there is nothing in the
interfaces to stop you)... My preference for configuration would be that a
CORBA operation is actually a resource (probably defined in a hierarchy
under the interface) that also has "intent" associated with it.   If you
equate intent to operational signature then you are (I think) forced to
configure the rights for every operation of an interface as part of the
interface resource definition.  I'm not convinced this is how people want
to be forced to configure interface access...  If you look at how Operation
is used in the RFP and the fact that a starter set is requested for
healthcare, I think this is really an "intent", not an "operation" although
I know I'm splitting hairs in order to avoid a later set of isses about the
relationship between this parameter and a CORBA operation.

Comments?

Carol

 I do think that if you mean "operational signature" is equivalent to
"intent" in my model we should talk as I think this would imply that you
view a CORBA operation as "intent" and that required rights would never be
assigned at the CORBA operation level if we were talking about a corba
object operation.  We should think thru what this means for
administrators... either way will work with the model.

   
_________________________________________________________
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.