[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HRAC Submission 99-03-02
Hi David,
It's nice to here from you again.
Let me put my $.02 about the points made in your message:
> IMHO, it seems to me that this submission has two weaknesses.
>
> First and most obvious (even to the submitters) is the performance
> implications of implementing the RAD service as a CORBA service.
Yes, the design allows one to implement the specification inefficiently.
However, it's not because RAD is a CORBA service (BTW CORBA security is
specified as a set of interfaces expressed in IDL too), but due to the
well-known fact that any generic framework could be implemented inefficiently
or abused at the deployment, and administration phases.
No body prevents you from co-locating either ADO or all parts of RAD on the
same subnet, host, process, or thread, as the ADO client.
Potential users of RAD need to understand that there is no free lunch, let me
repeat it: there is no free lunch. If they want high performance than they will
use only CORBA security. If they want fine-grain control of application
resources in such a way that authorization logic is decoupled from application
logic, then they want to consider CORBASEC + RAD. In former case they would
have to pay by higher complexity and lower performance, because RAD, besides
other things, is also an additional hop in access control. So, they want to
decide what currency (performance, expressiveness, granularity) they can pay
with.
> Consequently, the adoption of this proposal is unlikely to have any particle
> implementations. One possible solution would be to wait until the CORBA
> Component specification is adopted, and then to define the service as a
> "local" interface types.
"local interface" does not give you anything new. OMG folks have been using
PIDL or "locality constrained" forever. "local interface" is a better name for
"locality constrained". The submitters team decided explicitly NOT to constrain
the interfaces in spec to local. As I've mentioned already, depending on your
application domain, you can always co-locate your CORBA objects, and smart ORBS
(e.g. TAO) do bypass a lot of marshaling and other overhead when they recognize
that the client and the server are co-located.
> Since the policies are outside of the spec scope,
> replication and distribution issues are too.
Good point, and I think it is a very a good design decision. Please do not
forget the separation of concerns principle.
>
> The second weakness is that it does not seem to recognize the concept of
> access control domains.
It depends on how you define access control domains. You can deploy different
instances of ADO (access decision object -- the facade of RAD) in different
domains, so that target objects from different domains will consult different
instances of ADO or even RAD.
> Given that an application could be deployed in several different domains,
> there needs to be a way to define policies within the scope of a domain.
> For example, Joe might be able to create orders in Clinic A, but not in
> Clinic B,
> both under the control of Hospital System C. The resource name is the same
> (Orders), and the operation is the same (Create).
This example is not very good. I can show you how this example could be
resolved existing RAD model:
First, let's consider two different situations because the example is vague
about these details:
A. Joe authenticated to CORBA security environment in clinic A and he is trying
to create orders in clinic A as well as in clinic B. A reasonable
implementation of CORBA security services could do the following (CORBASEC
gurus, please correct me here if I'm wrong): initialize a principal which will
be acting on behalf of Joe with such privilege attributes that would indicate
that Joe logged into the system physically being in clinic A. It could be done
via a non-standard attribute type "location" or a standard attribute type
"group". The attribute would have value "clinic a". The value of this attribute
can be used by one of RAD's policy evaluators for making authorization
decisions. Thus, Joe will be permitted to create orders on systems located
clinic A and he will be denied to create orders on systems located in clinic B.
B. Another scenario is when, the enterprise security infrastructure is designed
so that systems from both clinics get their authorization decisions from the
same instance of RAD. In this case, there has to be an agreement between
application developers and the user organization (the hospital) that resource
names for such systems contain a component (let's say "location") that would
indicate in what clinic the order is about to be created. If it holds, then a
policy evaluator should be programmed in such a way that it denies operation
"create" on resource names that name orders and have one of the name-value
pairs "location"-"clinic B".
> This becomes even more
> important as re-usable application components are deployed.
Even though I showed above that the example and the describe problem domains
(at least in the form presented in your message) themselves do not uncover a
flaw in the spec, I would like to point out to the fact that even re-usable
components and other "panaceas" alike do not provide transparencies on all
levels. Somebody would still have to decide what, where and for whom any
re-usable component provides service. There is no miracles.
It's pity that I had to type this long answer, I wish David you would show up
at the presentations of our initial and revised responses to HRAC RFP, and I
(or anybody else) could just answer your questions.
I hope I addressed your concerns.
BTW, how's the other HRAC RFP submission team (that you were an active
participant of) consisting of HBOC and Data Access doing with their response? I
would love to see a submission which is free of all these problems.
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.