[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes: HRAC Submitters conference call August 25, 1998
Minutes of the HRAC RFP response submitters team conference call
Date: Tuesday August 25, 1998
Time: 2:00PM -- 3:35 PM Eastern time
Compiled by John Barkley
Participants:
John Barkley -- NIST
Bob Blakley -- IBM
David Chizmadia -- NSA
Bret Hartman -- Concept Five
V. Juggy Jagannathan -- CareFlow|Net
Bapa Rao -- TIS Labs
The following are minutes of the conference call of August 25. Please send
any comments/corrections to the list (hrac-rfp@cs.fiu.edu) or to me
(jbarkley@nist.gov).
Bob Blakley's HRAC Proposal was the focus of discussion. This was the
second item on the agenda
(http://cadse.cs.fiu.edu/omg/hrac-rfp/msg00112.html) for this call. The
first and third items were not discussed. The first item, i.e., proposed
definitions of "resource name" and "resource reference" from Bob Burt, were
not available. The third item, i.e., "black box" text for use cases, was
not available since Bob Blakley's proposal was submitted during the call.
That proposal is attached at the end of these minutes. Throughout the rest
of these minutes, "Bob" refers to Bob Blakley.
Bob provided a description of his proposal. The following are highlights
from the discussion which followed.
1. John raised the question concerning the use of the term "dynamic"
privilege attributes. Could there not be other privilege attributes
which could be considered "dynamic"? The use of this term in this
context may be revisited.
2. The access_allowed() interface of Bob's proposal was compared to
Konstantin's. Several differences were noted including the inclusion
in Bob's proposal of interfaces to be used by the Access Decision
Object (ADO), e.g., get_policy(), and the absence in Bob's proposal of
a "batch" access_allowed() interface and exceptions. Bob will propose
such a batch interface.
3. Bob's interfaces were compared to the CORBA Security Interfaces and
the necessary differences noted. Such differences are in the text of
Bob's proposal.
4. Bret and Juggy suggested that there are examples of legacy access
control engines which would not fit well with the interfaces as is.
Bret will provide a specific example of this.
5. There was a lengthy discussion on how the ADO would locate security
metadata. This is a summary of that discussion which does not mean to
imply that the discussion points necessarily happened in this order.
While some security metadata is located by means of the resource
name/reference, it was suggested (by someone - I apologize for not
remembering who) that some security metadata/paramaters would have to
be provided to the ADO access_allowed() interface by the ADO client.
Bob suggested that this could be accomplished by the ADO client
providing a "request_metadata" callback to the ADO. David suggested a
more general approach. ADO and ADO client are peers that would call
each other in order to "negotiate" access decisions. Alternatively,
David suggested that the resource name/reference could be formed in
such a manner as to encode security metadata which would then pass to
the ADO through the access_allowed() interface as proposed by Bob.
While some felt there is a need for ADO clients to provide/manipulate
security metadata, others felt that this violates a goal of the ADO,
i.e., the isolation of access decision processing and data within the
ADO. To this end, John suggested that in an implementation, a right
could consist of an expression/conditional/predicate which would be
evaluated/interpreted by the ADO. Contained within the expression
would be location information for security metadata as well as
conditions, based on security metadata, required for access.
Alternatively, Bret suggested that an ADO could be implemented as a
factory which produces ADOs specifically tailored for the resource.
The ADO manufactured would contain security metadata location
information.
6. There was discussion that an HRAC resource could be a CORBA object.
Bret agreed to provide some text describing how HRAC could be used to
provide finer grained access control (i.e., beyond CORBA Security) for
a CORBA object.
7. There was a general feeling that, in the absence of a compelling
reason for a sensitivity interface, such an interface should not be
included. This results from the recognition that access policies based
on sensitivity labeling can be represented using the proposed
HRACAccessPolicy interface.
8. There was a general feeling that the access interfaces and in
particular, the management interfaces of the ADO should be left
relatively abstract. Bob will propose some management interfaces.
9. There was a brief discussion about changing the schedule for the
Submitters Meetings a the next OMG Meeting since Bob is unable to
attend the first. For the moment, the schedule was left the same.
Action Items:
1. Bret:
1. Use case example of a legacy access control engine which does not fit
well with Bob's proposal.
2. Text describing how HRAC can be used in conjunction with CORBA
Security to provide finer grained access control when the HRAC
resource is a CORBA object
1. Bob:
1. Propose a "batch" form of the access_allowed() interface.
2. Propose management interfaces.
3. Send email about the October 6,7 Submitters Meeting in Austin.
4. Set up numbers for the next conference call to be on September 8.
Action Items Remaining from Previous Conference Call:
1. Bob Burt: Propose definitions for "resource name" and "resource
reference".
2. John and Konstantin: Use cases for Bob proposed interfaces.
------------------ Bob's Proposal -----------------------------
All,
Here (better late than never) is the proposal I promised last time:
HRAC proposal -- Bob Blakley -- 25 August 1998
GENERAL OVERVIEW:
A healthcare application, or a "wrapper" around that application
(as in BOCA), calls an HRACAccessDecision object, passing it
information identifying the requester (subject, in access control
terminology), the resource (object, in access control terminology),
and the requested operation (operation, in access control terminology).
The HRACAccessDecision object may consult the following additional
sources of information in making its decision:
(1) An AccessPolicy object. The HRACAccessDecision object could
find the appropriate policy object one of the following ways:
(a) a reference to the policy object could be
imbedded in the data structure which identifies the
resource (this is how CORBASecurity works; there's
a reference to a DomainManager in the object reference)
(b) if the data structure which identifies the resource
is a resource_reference, the HRACAccessDecision object
could look up the policy object in a table (or via
a method call to some object which maintains such a table),
using the resource_reference as a lookup key (or
method parameter).
(c) if the data structure which identifies the resource
is a resource_name, the HRACAccessDecision object
could look up the policy object in a table or via
a method call (as in option (b) above) or it could
use a regular expression, trader service, property
service, etc..., to retrieve a reference to the
correct policy object using the resource_name as
a method parameter or pattern-match expression.
(d) ...
(2) Policy Metadata associated with the resource (for example,
sensitivity labels associated with the resource, or with a
particular field of the resource which would be accessed as a
result of executing the specified operation.)
There are at least two cases here:
(a) The metadata is located in the resource itself
This makes resources more portable across
different implementations (assuming metadata
syntax and semantics are standardized), but
it requires the HRACAccessDecision logic to
access the resource's data. This raises two
problems:
(i) We'd need to be careful to avoid problems
of re-entrancy and self-referentiality in the
access control and auditing logic, since the
HRACAccessDecision logic will be accessing the
resource during an attempt to determine whether
access to the same object is allowed.
(ii) This option creates a requirement for the
HRACAccessDecision logic to understand the
operation signature of the resource itself, or
of the resource's managing application, since
it needs to use that interface to retrieve
metadata. The simplest approach to this would
be to define a "mix-in" interface defining how
metadata is accessed, and require all protected
resources to implement this interface. However
this means that existing applications would have
to be modified in many cases in order to have
protection applied to their resources -- which
is a BAD THING.
(b) The metadata is associated with the resource via some
metadata service.
(3) Dynamic Privilege Attributes.
These are required to support policies based on relationships between
credentials of the requester and characteristics of the resource.
A simple example of such a policy is "a patient record may be
accessed by the primary care physician of the patient whose care
it describes, but not by other physicians".
Dynamic privilege attributes must be looked up, based on the
requester's privilege attributes and resource metadata, by the
HRACAccessDecision logic at access decision time.
As in (2) above, there are two options for this:
(a) The metadata is located in the resource itself.
(b) The metadata is associated with the resource via some
metadata service.
In order to avoid having to dictate resource formats and require
changes to existing application interfaces in order to deploy HRAC,
I propose that we handle both policy metadata and dynamic privilege
attributes, when required, by specifying a metadata service.
The interface of this service would be specified in our proposal,
but completely encapsulated behind the HRACAccessDecision
interface and so not visible to applications.
The logical flow of control through the proposed set of interfaces
is:
(1) application or wrapper calls HRACAccessDecision::access_allowed
(2) HRACAccessDecision calls HRACPolicyManager::get_policy
// this may not be required if HRACAccessDecision can
// determine policy directly from resource name or reference
(3) HRACAccessDecision calls HRACRelationshipPolicy
// this may not be required if no dynamic
// privilege attributes influence the policy decision
(4) HRACAccessDecision calls HRACAccessPolicy::get_effective_rights
(5) HRACAccessDecision calls HRACRequiredRights::get_required_rights
(6) HRACAccessDecision compares effective (granted) and required
rights and returns the boolean result.
PROPOSED INTERFACES
//====================================================================
interface HRACAccessDecision
{ // Locality Constrained
boolean access_allowed (
in SecurityLevel2::CredentialsList cred_list,
in Resource target,
in CORBA::Identifier operation_name
);
}
// Note the differences from the CORBAsecurity AccessDecision
// interface:
//
// (1) The target is of type "Resource" -- more on this below
// (2) The "target_interface_name" parameter is not required
// because (presumably) resource types are opaque and
// their interfaces are not derived from one another via
// inheritance; this parameter was included in CORBAsecurity
// to deal with cases where the access decision logic couldn't
// distinguish between instances of a type and instances
// of its subtypes using information available to it at runtime.
//====================================================================
// We have two choices for the type of "Resource". We can
// decide to use resource_names or resource_references as we
// discussed on the last call. Bob Burt has agreed to propose
// specific formats for these; in the meantime I've put in some
// placeholders
// Here's the "name" option placeholder:
typedef CORBA::Identifier Resource;
// Here's the "reference" option placeholder:
typedef opaque Resource;
//====================================================================
// Here's the interface to the policy object, which allows
// the HRACAccessDecision object to get the list of rights
// granted to a particular subject.
interface HRACAccessPolicy : SecurityAdmin::AccessPolicy
{
Security::RightsList get_effective_rights (
in Security::AttributeList attrib_list, // subject privs
in Security::ExtensibleFamily rights_family
);
}
//====================================================================
// Here's a RequiredRights interface which allows the
// HRACAccessDecision object to figure out which rights a subject
// must be granted in order to perform the requested operation on
// the requested resource
interface HRACRequiredRights
{
void get_required_rights(
in Resource resource,
in CORBA::Identifier operation_name,
out Security::RightsList rights,
out Security::RightsCombinator rights_combinator
);
}
// Note that this differs from the CORBASecurity RequiredRights
// interface in that it doesn't require the interface_name
// parameter; this is because CORBA objects may support multiple
// interfaces and it might be necessary to distinguish among them
// to uniquely identify operation names. I'm presuming that this
// problem doesn't arise with the applications which manipulate
// resources.
//
// Note that this interface decision assumes that the
// HRACRequiredRights object's logic is able to determine what
// the type of the resource is (and therefore what its operation
// signature is).
//
// Finally, I'm assuming that any rights required because of subject
// metadata, wherever it's stored, are discovered and returned by
// the logic of this object.
//====================================================================
// Here's an HRACPolicyManager interface, which allows the
// HRACAccessDecision object to retrieve the policy which governs
// access to the requested resource. This interface might not
// be necessary if the HRACAccessDecision object could determine
// policy either by looking inside a resource reference structure,
// or by applying a pattern match rule to the name of the resource,
// as described in (1)(a) or (1)(c) in the overview.
interface HRACPolicyManager
{
HRACAccessPolicy get_policy (
in Resource resource
);
}
//====================================================================
// Here's a relationship policy interface, which allows the
// HRACAccessDecision object to discover dynamic privilege
// attributes arising from the relationships between the subject's
// static privilege attributes and the resource's metadata.
interface HRACRelationshipPolicy
{
Security::AttributeList get_dynamic_privs (
in Security::AttributeList attrib_list, // static privs
in Resource resource);
}
--bob
Bob Blakley
IBM Lead Security Architect
Voice: +1 (512) 838-8133
Fax: +1 (512) 838-0156
Post: 11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA
Internet: blakley@us.ibm.com
----------------
Broadcast message to hrac-rfp from barkley@sdct-sunsrv1.ncsl.nist.gov (John Barkley).
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.