Terminology Section

["David M. Chizmadia" <dmc@tycho.ncsc.mil>]

Based on a pass through the current proposal and a review
of the CORBAsec definitions, here is my proposal for the
Terminology section.

On my pass I also considered including Policy Evaluator and
Policy Combinator, but decided that they were not required.
If anyone feels that I misjudged, let me know and I'll put
something together.

-DMC

================================================================

Access Decision Object (ADO) - The HRAC object that implements
access decision functions.  From the perspective of a client
requesting an access decision of HRAC, this is the only
interface that they are required to use.  Although similar
in function to the CORBAsec object of the same name, the HRAC
ADO has a different signature and semantics.

ADO Client - the immediate invoker of the HRAC Access Decision
Object.  This could be an integral part of the application that
controls the secured resources or it could be an interceptor
that decides whether to allow the CORBA Request to reach the
application.

Access Policy – the policy or rules that govern access to a
secured resource.

AttributeList – a list of security attributes that are used to
determine whether access should be allowed. An AttributeList
may contain both static and dynamic attributes.

Authorization - The granting of authority, which includes the
granting of access based on access rights. (CORBAsec)

Component - A cohesive set of software services

Credentials: Information describing the security attributes
(identity and/or privileges) of a user or other principal.
Credentials are claimed through authentication or delegation
and used by access control.  (CORBAsec) The attributes contained
in an HRAC AttributeList are derived from CORBAsec credentials,
if possible.

Dynamic attribute – a security attribute that can only be
determined at the time an access decision is requested. Dynamic
attributes are often based on the relationship between a principal
and the secured resource (such as attending physician) and cannot
be statically configured. This submission allows dynamic attributes
to be resolved and used during the access decision computation.

Identity (attribute): A security attribute with the property of
uniqueness; no two principals’ identities may be identical.
Principals may have several different kinds of identities, each
unique (for example, a principal may have both a unique audit
identity and a unique access identity). Other security attributes
(e.g. groups, roles, etc...) need not be unique. (CORBAsec)

Naming Authority - Any organization that assigns names determines
the scope of uniqueness of the names and takes the responsibility
for making sure the names are unique within its name space. In the
same way that ID values are meaningful only within the context of
their ID Domains, names are unique only within the context of their
naming authority. (PIDS)

Operation - an action which may be performed on a secured resource
(such as create, get, set, use..). Operations are represented within
the HRAC as strings.

Principal: A user or programmatic entity with the ability to use the
resources of a system. (CORBAsec)

Privilege (Attributes) – security attributes which need not have the
property of uniqueness, and which thus may be shared by many users
and other principals. Examples of privileges include groups, roles,
and clearances. (CORBAsec)

Secured Resource – a “secured resource” is 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.

Security attributes: Characteristics of a principal which form the
basis of the system’s policies governing that subject. (CORBAsec)

Static Attribute – a security attribute that is (typically)
statically configured by an administrator. Examples would be
access_id:john_doe or role:physician.

System - An application or set of applications that interact with
each other, interact with the HRAC or implement HRAC. System in
this context is synonymous with application. Examples of systems
might include a hospital or clinical information system, an
ancillary system such as a lab or radiology system, or a financial/
administrative system such as an ADT.

----------------
Broadcast message to hrac-rfp from "David M. Chizmadia" <dmc@tycho.ncsc.mil>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.