HRAC submeeting team meeting July 30, 1998: minutes

[Konstantin Beznosov <beznosov@baptisthealth.net>]

Attached are the minutes of the meeting in Helsinki. 

Konstantin
-----------------------------------
Distributed Computing Architect
Baptist Health Systems of South Florida
voice: 305.596.1960 x6469
Minutes of the HRAC RFP response submitters and supporters team meeting

Location: Radisson Hotel, Helsinki, Finland
Date: Thursday, July 30, 1998
Time: 9 AM -- 12 PM

Compiled by Konstantin Beznosov

Participants:
Bob Burt -- 2AB,
Carol Burt -- 2AB, (partly)
David Chizmadia -- NSA, 
Bret Hartman -- Concept 5,  (partly)
Charles Carman -- Philips, 
Konstantin Beznosov -- BHSSF,
Angelique Krieger -- Boeing,
Jeff Mischkinsky -- Inprise, (partly)
David Curtis -- OMG (soon in Inprise)

The following items were in the meeting agenda

A. DESIGN GOALS

Participants converged on the following design goals (proposed by
Carol Burt in one of the earlier messages on the mail list):

  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 precise 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] but not simpler.  The
  definition of access rules should be generic enough to allow a
  variety of implementation approaches to storage and retrieval of
  rules and simple enough that users and target developers will take
  the time to define and use them.

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

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


ROUGH MODEL AND TERMINOLOGY IN IT

The following terminology was adopted for further use:

- Access Decision Object (ADO)
An object that provides an interface to obtain authorization decisions
about operations on resources by a particular principal.

- ADO Client
An application that acts as a client of ADO.

- Secured Resource
"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."

"Resource Identifier" was NOT defined yet.

RESOURCE SPACE STRUCTURE AND ORGANIZATION

Bob described 2 alternative models of resource space that they used in
their implementations crying similar functionalities:

  1. Flat space: each resource is uniquely identified by an identifier
  which does not have any internal structure, i.e. just a unique
  number that can be used for indexing resources and other
  manipulation operations. In this case, each authorization rule
  allows to make decision on one and only resource.
  
  2. Tree-like hierarchy (acyclic directed graph [ADG]): each
  resource is uniquely identified by an identifier which has internal
  structure. The identifier structure represents the path to the
  resource. This resource space is similar to Unix directory tree
  organization, where a name of any file is a global path to that
  file beginning from root. An authorization rule allows to make
  decision on any node or leaf. Access to the resource is granted if
  access is granted to every node in the path to the resource. For
  example, in order to have access to resource identified by
  /BHSSF/SMH/patients/JohnSmith/bloodtests/August-02/test-3 access
  should be given to /BHSSF, to /BHSSF/SMH, to /BHSSF/SMH/patients,
  ..., to /BHSSF/SMH/patients/JohnSmith/bloodtests/August-02/test-3.
  The described logic is the same as in access control model of Unix
  file system.
  
Bob proposed to use these two structures of the resource space. I.e.
each resource identifier would be either from the flat (#1) space of
from the hierarchical (#2) space. 

Participants tried to come up with scenarios where these two types of
resource space would not suffice. Nobody could come up with such a
scenario. It was decided that we all will test the proposed
organization of resource space and see if there is any reasonable
scenario of authorization rules that would require more sophisticated
or just different resource space organization.

It was suggested to have another meeting in Seattle during the OMG 
meeting.