[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Design Goals]
Hi,
I'd like to suggest that we put some sort of "topic" in our subject so we can
easily loop thru threads on the same topic... I'll start a couple of
"threads".
I think it would be useful to capture some "design goals" we can all agree
to.... I got the distinct impression that while we all have an idea of what an
HRAC is, those ideas are not consistent among the group at the moment. We are
likely to go round in circles until we have consistent design goals.... maybe
I'll start... this is "off the top of my head" at the moment, so forgive me if
I ramble.
First, a reminder of requirements (from the RFP):
===============================================================
6.5 Mandatory Requirements
1. Proposals shall use the CORBA Security service credentials as the source
for
identifying caregivers' privileges. The CORBA Security service provides a
foundation for the intended facility.
2. Proposals shall provide the ability to define secured resource
categories --
including CORBA objects and other resources as it discussed in section 6.2 --
and the ability for an application to discover to which secured resource
category a CORBA object or other resource belongs. Proposals shall provide the
ability to state and evaluate policies governing the following minimal set of
operations on secured resources: create, read, write, use and delete.
3. Proposals shall provide an interface for defining access control rules for
secured resources based on credentials as defined in the CORBA Security
Specification. Examples of access control rules are given in section 6.1.
4. Proposals shall define a specific set of Healthcare secured resources.
Examples of such resources might include demographic information, laboratory
results, HIV status etc.
5. Proposals shall provide an interface to an access control decision facility
that may be used to request access control decisions
6.6 Optional Requirements
1. Proposals may provide the ability for secured resources -- including
resources that are not CORBA objects -- to be grouped for the purpose of
defining access control rules.
2. Proposals may provide an interface for defining access control rules based
on attributes of the Principal in addition to those defined in CORBA Security
service.
3. Proposals may provide an interface that extends the definition of access
control rules to include context sensitive access control based on
· the day and time when the resource is accessed
· the location of an invoking principal
· the values of request parameters
4. Proposals may provide an interface that extends the definition of access
control rules to include notion of relationship between a patient and a
caregiver.
5. Proposals may include a reference object model for the healthcare domain
that provides a sufficient foundation for access control decision logic.
6. Proposals may provide an interface that permits management of the policy,
which controls how multiple access control policy decisions governing
access to
the same resource are reconciled.
=============================================================
I included optional requirements here for completeness, but my first
suggestion
is that we agree to work on the mandatory requirements first... until we think
we have a good handle on how to meet those requirements, I'd prefer to only
look at option in the light of not making any decisions that would preclude
adding that functionality as the submission matures.... this keeps us focused
on a smaller problem that hopefully we can make progress on?
Comments?
==============================================
First - can we define some consistent Terminology? When I talk about "client"
of the HRAC, I was talking about the application or the infrastructure that
called the HRAC. It was clear that some people on the call were thinking the
client of the service that called the HRAC... so...
===
Target:
Let's borrow a term from Bob Blakley's picture and use the term "target" as
the
client of the HRAC. Agreed?
====
Access Decision Object (ADO):
And Konstantin has been using ADO as shorthand for the "Access Decision
Object"
. Agreed?
====
Secured Resource:
Next we have this "thing" called a "Resource". What is it? Well the RFP
defined it as follows:
"In the scope of this RFP, a “secured resource” can be any valuable asset
of an
application owner, which is accessed by an application on behalf of a
principal
using it, and access to which is to be controlled according to the owner’s
interests."
The first thing to notice is that a "secured resource" may or may not be a
thing in the CORBA space... that is, it may be a CORBA object, or a CORBA
interface, or CORBA operation... but in many/most cases, it is not something
that is visible in the CORBA space.... but we *must* identify it in the corba
space to provide access control. How? With an identifier of some sort.
====
Resource Identifier:
So the next term I think we need is a Resource Identifier (or name?).
The challenge is to make this concise enough that we can allow any "secured
resource" to be identified uniquely and yet general enough that we can
identify
many different kinds of secured resources. In fact, one of the requirements
of the RFP is that we allow resources to be categorized. I think we need to
look at the CORBAMed adopted module NamingAuthority to provide the base for
defining unique Resource Identifiers. Both PIDS and Lexicon use this[and
it's not specific to healthcare so it should be applicable elsewhere in the
future], this would be a natural fit... I'll draft suggested idl later.
===
[Konstantin - maybe we should start a [Terminology} thread... I'm sure there
will be many many more]
So can we agree on design goals for a facility that will meet those
requirements?
Here are some of my "design goals" --- I expect some controversy ;-)
1) There should be nothing in the interfaces that restricts the scope of
access
control managed by an HRAC facility. That is, it should be possible to have a
single HRAC which controls access rules and decisions for all targets in an
enterprise or an HRACs for each target in an enterprise. [This does not
imply
that there would not be multiple instances of ADO's accessing an enterprise
rules repository... it does imply that there must be a way to uniquely
identify
secured resources, however]
2) It should be possible for targets to be developed without concern for the
vendor of the HRAC... that is, the rules for defining "secured resource
identifiers" are concise and there are no hidden interfaces between the target
and the HRAC.
3) Definition of access rules should be as simple as possible [and still meet
the requirements of the RFP]. The definition of access rules should be
generic
enough to allow a variety of implementation approaches to storage and
retreival
of rules... and simple enough that users and target developers will take the
time to define and use them.
3) Interfaces should exist such that Secured Resources and associated Access
control rules might be defined and administered by a security administrator
using a tool or by the target (that is, secured resources may exist for which
static rules are defined, or targets may, in the course of the application,
create secured resources for which access control should now be enforced. [
this might be the case if an application wanted instance level control and
"created" a new secured resource that only the "owner" could have access to in
the future -- this is why I think the argument that you don't need admin
interfaces exposed falls apart... it isn't just a "tool" that might want to
administer the rules -- this could be very dynamic]
4) [AB HAT OFF --- IMPLEMENTOR HAT ON] Interfaces and/or types that are
specific to healthcare (the required set of secured resources for healthcare)
should be provided in a separate module so that the specification can be
easily
extended/adopted for other domains with similar requirements.
There are more, but that's all the time I have now. At least when I comment
you'll know where I'm coming from :-) I'll try and put some IDL on the table
in the next day or two.
Thanks,
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.