Re: Terminology Section

[Carol Burt <cburt@2ab.com>]

Thanks David... these look great to me.  I'll have a new draft out this am.

Carol

At 05:58 PM 10/15/98 -0400, David M. Chizmadia wrote:
>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.
> 
_________________________________________________________
Carol Burt                                             2AB, Inc.
cburt@2ab.com                                     Integration Architects
205-621-7455                                        www.2ab.com
Member, OMG Architecture Board          OMG Domain Member

   --  integrating yesterday's systems with today's technology --
----------------
Broadcast message to hrac-rfp from Carol Burt <cburt@2ab.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.