[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Design Goals]
Carol and all,
I think it is a very good idea to make sure we are all on th esame page in
terms of terminology and design goals.
Yesterday conference call showed to me that:
1. We need to converge on main points like terminology, design and other goals,
and good understanding what the RFP is asking
2. We need to make better progress over e-mail so that our conference calls
become more efficient and we will have produce results by October 19.
Please see my comments inlined:
> =============================================================
> 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?
agree. Do you think we should limit use cases and sample scenarios to
functionality required in the mandatory requirements, too?
> ====
> 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. ===
I agree that we need to come up with a way to categories resources (provided
that we reach consensus to categories them at all, which I personally support).
However, we want to make sure that whatever scheme of categorization we choose,
it actually works well for most of the potential cases required by the
mandatory and optional requirements. Also, maybe we should provide application
and HRAC developers with a way to choose and support multiple schemes?
>
> [Konstantin - maybe we should start a [Terminology} thread... I'm sure
> there will be many many more]
OK. I'm putting my comments on terminology into the [Terminology} thread.
>
> So can we agree on design goals for a facility that will meet those
> requirements?
>
If we don't we will have to disband :)
>
> 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]
no controversy to me so far :)
>
> 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.
And no hidden syntaxes.
>
> 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.
I do not think that the main concern is to allow simple/efficient storage and
retrieval of rules. To me, the main concern that the rule language will be
general or extensible enough to express most of potential policies, and to be
computable. The marginal requirement is to be efficiently computable.
>
> 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]
I would not agree that we should have ability for an administration interface
to be "defined and administered ... by the target" I suggest to change this
goal to the following:
The design should have no assumptions on who and with what purposes will invoke
methods on ADO and Admin objects.
> 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.
Agree
Konstantin
-----------------------------------
Distributed Computing Architect
Baptist Health Systems of South Florida
voice: 305.596.1960 x6469
----------------
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.