Internet DRAFT - draft-bartz-hyperdrive-ldap-rbac-schema
draft-bartz-hyperdrive-ldap-rbac-schema
Network Working Group L. Bartz
Internet Draft Internal Revenue Service
Expires six months from October 21, 1997
LDAP Schema for Role Based Access Control
< draft-bartz-hyperdrive-ldap-rbac-schema-00.txt >
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Role Based Access Control (RBAC) is an authorization strategy in
which an entity's permission to access and manipulate targeted
resources is determined by the entity's role or function within a
certain organizational context. RBAC's principal motivation is to
streamline security policy administration. Many discrete authoriza-
tions can be aggregated within a defined role. One or many roles may
be assigned or attributed to individuals. This draft describes LDAP
object classes and attributes which support RBAC. Adoption of this
schema across multiple LDAP implementations will enable RBAC intero-
perability among heterogeneous underlying directory services.
Bartz [Page 1]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
Table of Contents
1. Introduction
2. Object Class model
3. Object Relationships
4. Object Class Specifications
5. Behavioral Overview
6. Security Considerations
7. References
8. Author's Address
1. Introduction
The Lightweight Directory Access Protocol (LDAP) [6,7] is rapidly
becoming the ubiquitous mechanism for accessing and manipulating
directory data. Many diverse directory implementations, data stores,
client applications, and API suites are acquiring LDAP interfaces and
functionality.
This widespread LDAP protocol compliance enables interoperability.
But protocol compliance in the absence of architecture still leaves
us a long way from integration. Unless LDAP-compliant implementations
can rely upon each other to provide and interpret meaningful content,
little is achieved.
Common schema implementations provide architectural elements in the
form of LDAP object classes and attributes. Widespread adoption and
support of these architectural elements will add value to interoper-
able implementations, yielding potential for integration of hetero-
geneous underlying strategies. This integration is realizable on
enterprise and Internet scales.
The scope of functionality addressed by this draft is authorization
and access control.
Role Based Access Control (RBAC) [1,2,3] is an authorization strategy
in which an entity's permission to access and manipulate targeted
resources is determined by the entity's role or function within a
Bartz [Page 2]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
certain organizational context. RBAC's principal motivation is to
streamline security policy administration.
Under RBAC, many discrete authorizations can be aggregated within a
defined role. One or many roles may be assigned or attributed to
individuals. Roles may be constructed or attributed hierarchically,
so that one role may be constructed of several other roles, even
further streamlining administrative overhead. Some roles are also
mutually exclusive or conflicting, implying a requirement for defin-
ing such relationships within the architecture.
This draft describes LDAP object classes and attributes which support
RBAC. Adoption of this schema across multiple LDAP implementations
will enable RBAC interoperability among heterogeneous underlying
directory services.
This LDAP RBAC strategy is called "hyperDRIVE" [13], as a working
name and convenient discussion handle. The working name will be used
throughout this document.
2. Object Class Model
The discovery and definition of the hyperDRIVE objects focuses upon
three principal responsibilities of an integrated security function,
namely authentication, authorization, and access.
We define each responsibility:
2.1 Access
Access, in the hyperDRIVE context, encompasses the location of target
objects, and the methods and modes of access to, and of, network com-
puting resources. Access answers the questions, "What is the target?
To which asset(s) are we selectively allowing access? What is the
nature of the the access?" For some, the familiar acronym CRUD
(create, read, update, delete) is included in this concept, as
describing particular modes of access. In RBAC terminology, this
object points to an operation or privilege.
The hyperDRIVE object "operationAccessor" (see 4.2) fulfills this
responsibility. The operationAccessor's premier attribute is a URL
type. The URL represents a globally unique access reference to the
precise target data and functionality intended by the implementor.
Bartz [Page 3]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
2.2 Authorization
Authorization, in the RBAC context, is the mapping or aggregation of
one or more operations or privileges to a defined role. Also included
are the related constructs of role hierarchies, mutually exclusive
roles, and statically defined separation of duties.
The hyperDRIVE object "role" (see 4.3) fulfills this responsibility.
In hyperDRIVE, roles are assigned or mapped to persons, not vice
versa as some RBAC literature describes. A person potentially
possesses many roles. Roles do not possess persons.
2.3 Authentication
Authentication and authorization are certainly separate responsibili-
ties and separate activities. Much of the published RBAC literature
treats the choice of authentication strategy as inconsequential with
respect to the functionality of the RBAC strategy. hyperDRIVE, on
the other hand, specifies X.509 [12] certificate-based authentication
as an integral and indispensible component.
The X.509 certificate's "subject" attribute (or field), is the Dis-
tinguished Name (DN) of the certificate's possessor, which is gen-
erally a person. The DN is a unique direct index into the same LDAP
directory information base which holds the operationAccessor and role
objects. The X.509 "subject" DN binds the authenticated identity (of
the entity who possesses and presents the certificate at run time) to
an object in the directory which describes the person. The hyperDRIVE
object "hyperDrivePerson" (see 4.4) extends the directory's person
object . The hyperDrivePerson accomplishes the binding of the authen-
ticated identity to the assigned role(s).
3. Object Relationships
This ASCII representation of a Unified Modeling Language (UML) [8]
schematic illustrates the static object relationships. Observe that
the "Role" object possesses an attribute "operations", which is an
aggregation of references to operationAccessor objects. Likewise, the
hyperDrivePerson object possesses an attribute "roles", which is an
aggregation of references to "Role" objects.
Bartz [Page 4]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
+------------------+
+---| operationAccessor|
| +------------------+
| | |
| | common name |
+------------------+ | | |
+---| Role | | | description |
| +------------------+ | | |
| | | | | objectOwner |
| | common name | | | |
| | | | | organizational- |
| | description | | | -UnitDN |
| | | | | |
| | roleOwner | | | <<URL>> execURL |
| | | | | |
| | organizational- | | | certificate |
| | -UnitDN | | | |
| | | | | review+ApprovalDN|
| | includedRole | | | |
| | | | | maintenanceDN |
| | conflictingRole | | | |
| | | | | member |
| | review+ApprovalDN| | | |
| | | | | operationType |
| | maintenanceDN | | | |
| | | | +------------------+
| | +------------+ | |
+------------------+ | | | Operations |<>----+
| hyperDrivePerson | | | +------------+-+ |
+------------------+ | | | | |
| | | | |<<multi- | |
| objectOwner | | | | -valued>> | |
| | | | |<<disting.- | |
| review+ApprovalDN| | | | -name>> | |
| | | | |______________| |
| maintenanceDN | | +------------------+
| | |
| +-------+ | |
| | Roles |<>---------+
| +-------+------+ |
| | | |
| |<<multi- | |
| | -valued>> | |
| |<<disting.- | |
| | -name>> | |
| |______________| |
+------------------+
Bartz [Page 5]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
4. Object Class Specifications
4.1. ASN.1 representation
id-hyprDrv OBJECT IDENTIFIER ::= { /* to be APPLIED-FOR */ }
/**********************************************************************
* hyperDRIVE Definitions *
* Internal Revenue Service, U.S. Department of the Treasury *
* October 10, 1997 *
* *
* -- Note: borrowed attributes: *
* *
* Attribute Source *
* *
* commonName X.500 Standard Attributes *
* description X.500 Standard Attributes *
* member X.500 Standard Attributes *
* userCertificate X.500 Standard Attributes *
* manager COSINE/Internet X.500 Pilot Attributes*
* labeledURL University of Michigan *
* *
* *
**********************************************************************/
/**********************************************************************
* hyperDRIVE base OIDs *
**********************************************************************/
id-hD OBJECT IDENTIFIER ::= { id-hyprDrv 0 }
id-hD-at OBJECT IDENTIFIER ::= { id-hD 0 }
id-hD-oc OBJECT IDENTIFIER ::= { id-hD 1 }
id-hD-mr OBJECT IDENTIFIER ::= { id-hD 2 }
/**********************************************************************
* hyperDRIVE Attributes *
**********************************************************************/
id-at-hD-organizationalUnitDN OBJECT IDENTIFIER ::= {id-hD-at 0}
id-at-hD-objectOwner OBJECT IDENTIFIER ::= {id-hD-at 1}
id-at-hD-reviewAndApprovalDN OBJECT IDENTIFIER ::= {id-hD-at 2}
id-at-hD-maintenanceDN OBJECT IDENTIFIER ::= {id-hD-at 3}
id-at-hD-roleOwner OBJECT IDENTIFIER ::= {id-hD-at 4}
id-at-hD-locationDN OBJECT IDENTIFIER ::= {id-hD-at 5}
id-at-hD-includedRole OBJECT IDENTIFIER ::= {id-hD-at 6}
Bartz [Page 6]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
id-at-hD-conflictingRole OBJECT IDENTIFIER ::= {id-hD-at 7}
id-at-hD-roles OBJECT IDENTIFIER ::= {id-hD-at 8}
id-at-hD-operations OBJECT IDENTIFIER ::= {id-hD-at 9}
id-at-hD-hyperDriveObjectType OBJECT IDENTIFIER ::= {id-hD-at 10}
/***********************************************************
* hyperDRIVE Structural Object Classes *
***********************************************************/
id-oc-hD-operationAccessor OBJECT IDENTIFIER ::= {id-hD-oc 0 }
id-oc-hD-role OBJECT IDENTIFIER ::= {id-hD-oc 1 }
/***********************************************************
* hyperDRIVE NON-Structural Object Classes *
***********************************************************/
id-oc-hD-hyperDrivePerson OBJECT IDENTIFIER ::= {id-hD-oc 2 }
id-oc-hD-hyperDriveLocality OBJECT IDENTIFIER ::= {id-hD-oc 3 }
id-oc-hD-hyperDriveOrganizationalUnit OBJECT IDENTIFIER ::= {id-hD-oc 4 }
/*******************************************************
* hyperDRIVE Attribute Definitions and Matching Rules *
*******************************************************/
organizationalUnitDN ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-organizationalUnitDN } }
objectOwner ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-objectOwner } }
reviewAndApprovalDN ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-reviewAndApprovalDN } }
maintenanceDN ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-maintenanceDN } }
roleOwner ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-roleOwner } }
Bartz [Page 7]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
locationDN ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-locationDN } }
includedRole ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-includedRole } }
conflictingRole ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-conflictingRole } }
roles ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-roles } }
operations ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
ID { id-at-hD-operations } }
hyperDriveObjectType ATTRIBUTE ::= {
WITH SYNTAX DirectoryString
EQUALITY MATCHING RULE caseIgnoreMatch
SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
ID { id-at-hD-hyperDriveObjectType } }
/***********************************************************
* hyperDRIVE Object Class Definitions *
***********************************************************/
operationAccessor OBJECT-CLASS ::= {
SUBCLASS OF top
MUST CONTAIN commonName
MAY CONTAIN { description |
objectOwner |
organizationalUnitDN |
labeledURL |
userCertificate |
reviewAndApprovalDN |
maintenanceDN |
member |
hyperDriveObjectType }
ID { id-oc-hD-operationAccessor } }
Bartz [Page 8]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
role OBJECT-CLASS ::= {
SUBCLASS OF top
MUST CONTAIN commonName
MAY CONTAIN { description |
roleOwner |
organizationalUnitDN |
reviewAndApprovalDN |
maintenanceDN |
includedRole |
conflictingRole |
operations }
ID { id-oc-hD-role } }
hyperDrivePerson OBJECT-CLASS ::= {
SUBCLASS OF person
MAY CONTAIN { objectOwner |
reviewAndApprovalDN |
maintenanceDN |
locationDN |
organizationalUnitDN |
roles }
ID { id-oc-hD-hyperDrivePerson } }
hyperDriveLocality OBJECT-CLASS ::= {
SUBCLASS OF locality
MAY CONTAIN { labeledURL |
hyperDriveLocality |
organizationalUnitDN |
member }
ID { id-oc-hD-hyperDriveLocality } }
hyperDriveOrganizationalUnit OBJECT-CLASS ::= {
SUBCLASS OF organizationalUnit
MAY CONTAIN { manager |
labeledURL |
hyperDriveOrganizationalUnit |
locationDN |
member }
ID { id-oc-hD-hyperDriveOrganizationalUnit } }
/***********************************************************
* END hyperDRIVE Definitions *
***********************************************************/
Bartz [Page 9]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
4.2. operationAccessor
Description:
The operationAccessor object class is the directory's represen-
tation of an operation (referenced by the URL) which requires
restricted access authorization and navigational representation
in the directory.
Attributes:
- commonName: the full, formal name of the operationAccessor.
- description: mildly verbose description .
- objectOwner: distinguished name(s) of the persons or role(s)
which "own" the right to permit or deny authorization to access
and manipulate the target object/operation.
- organizationalUnitDN: the distinguished name of the highest-
level organizational unit to which the target object/operation
belongs.
- execURL: the URL through which the target object/operation is
accessed, executed, manipulated
- applicationCertificate: the X.509 certificate, containing
public key and other attributes, which the target
object/operation uses to identify itself and its actions.
- review+ApprovalDN: the DN of the operationAccessor through
which the owner's right and responsibility is exercised. .
- maintenanceDN: the DN of the operationAccessor through which
maintenance on this object is performed.
- member: distinguished name(s) of directory object(s) which
are permitted access to the target .
- hyperDriveObjectType: a string value which indicates what
general type of object is represented. Suggested values
include: "production", "information", "administrative", and
"review+approval".
Naming Rules:
The commonName attribute must be used for naming.
Bartz [Page 10]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
Structure Rules:
A directory entry for operationAccessor must have an immedi-
ately superior entry of organizationalUnit.
Relationships:
organizationalUnit
role
4.3. role
Description:
The role object is a container for aggregations of operationAc-
cessor objects.
Attributes:
- commonName: the full, formal name of the role
- description: mildly verbose description
- roleOwner: distinguished name(s) of the persons, or roles
which "own" the right to permit or deny assignment of the role
to persons.
- organizationUnitDN: the distinguished name of the highest-
level organizational unit to which the role object belongs.
- review+ApprovalDN: the DN of the operationAccessor object
through which the owner's right and responsibility is exer-
cised.
- maintenanceDN: the DN of the operationAccessor object through
which maintenance on this object is performed.
- includedRole: a list of one or more distinguished names (DN)
of role object. This attribute supports the implementation of
role hierarchies.
- conflictingRole: a list of one or more distinguished names
(DN) of role object. This attribute supports the implementation
of mutually exclusive role policies.
Bartz [Page 11]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
- operations: a list of one or more distinguished names (DN) of
operationAccessor object.
Naming Rules:
The commonName attribute must be used for naming.
Structure Rules:
A directory entry for operationAccessor must have an immedi-
ately superior entry of organizationalUnit.
Relationships:
organizationalUnit
operationAccessor
hyperDrivePerson
4.4. hyperDrivePerson
Description:
The hyperDrivePerson object is an extension of the directory's
person object, and is a container for aggregations of role
objects.
Attributes:
- objectOwner: distinguished name(s) of the person(s), or
role(s) which "owns" the right to permit or deny authorization
to access and manipulate this object.
- review+ApprovalDN: the DN of the operationAccessor through
which the owner's right and responsibility is exercised.
- maintenanceDN: the DN of the operationAccessor through which
maintenance on this object is performed.
- roles: a list of one or more distinguished names (DN) of role
object. This attribute accomplishes the assignment of role
objects to the person.
Naming Rules:
Bartz [Page 12]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
The commonName attribute must be used for naming.
Structure Rules:
hyperDrivePerson is a non-structural object class which extends
another person-descriptive object class, such as newPilotPer-
son.
Relationships:
organizationalUnit
role
5. Behavioral Overview
The runtime behavior of the hyperDRIVE objects is described in terms
of a proof-of-concept system- or enterprise-scale framework. A frame-
work named hyperDRIVE was developed to demonstrate the functionality
of the RBAC LDAP infrastructure. See [13] for an explicit descrip-
tion.
The hyperDRIVE framework appears to qualify as a system-scale or
enterprise-scale framework, as described in [14], "Horizontal-
Vertical-Metadata" (HVM) design pattern. As per the HVM design pat-
tern, the LDAP-accessible repositories are Metadata and hyperDRIVE
provides a substantial portion of the functionality of the Horizontal
framework.
In brief:
hyperDRIVE's authentication mechanism is via X.509 certificates,
which clients and servers exchange and verify to establish mutually
authenticated Secure Socket Layer (SSL) [9] sessions.
hyperDRIVE's authorization model is Role Based Access Control (RBAC).
The Lightweight Directory Access Protocol (LDAP) directory contains
objects which describe people (hyperDrivePerson) and objects which
describe enterprise information resources and the operations which
involve those resources (operationAccessor). Additional directory
objects (role) are aggregations of operationAccessor. One or more
role objects are assigned to each person, thus achieving the RBAC
objective.
hyperDRIVE provides its customers with a Java applet, which is a GUI
Bartz [Page 13]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
navigation guide, or menu. The hyperDRIVE navigation guide is con-
structed on the fly from the customer's LDAP-hosted RBAC profile.
The hyperDRIVE Guide applet establishes distributed object communica-
tion with an object request broker (ORB) server which resides,
according to the Java applet "sandbox" policy [5], on the same host
from which the applet was served.
The client applet requests role objects and operationAccessor objects
which apply to the customer's DN. We refer to distributed object com-
munication by the name of the Object Management Group's Common Object
Request Broker Architecture (OMG/CORBA) [11] Internet Inter-ORB pro-
tocol, or IIOP.
The hyperDRIVE proof-of-concept framework uses a freeware ORB, known
as HORB [10]. The development roadmap for hyperDRIVE portends a tran-
sition to CORBA compliance and IIOP.
The ORB contacts the well-known LDAP server, requesting role and
operationAccessor objects which apply to the customer's DN.
The LDAP server is "well-known" to the ORB server because its name
was given to the ORB server in a list at the time the ORB server was
instantiated. In hyperDRIVE, ORB servers and active objects are pro-
vided with lists of trusted LDAP servers, just as SSL servers are
provided with a list of trusted certificate authorities.
The LDAP server provides the requested role and operationAccessor
objects.
The ORB provides the requested directory objects. The hyperDRIVE
Guide applet can now act as a navigation tool for the customer,
displaying names, descriptions, and links which describe operations
for which the customer is authorized .
Through the hyperDRIVE Guide applet, the customer invokes an opera-
tion. The customer's web client suite invokes the URL against the
target, while simultaneously attaining a mutually authenticated SSL
session with the web server which hosts the targeted operation.
The targeted server and active objects are (via SSL) provided with
the customer's authenticated identity. Just as the hyperDRIVE Guide
applet, the targeted services will use the customer's DN (from the
X.509 certificate) as an index into the LDAP RBAC information base.
hyperDRIVE provides servers, applications, and active objects with
capabilities and facilities to consult the LDAP-hosted RBAC data.
Through this consultation, the entities assure themselves of the
Bartz [Page 14]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
appropriateness of customer requests. hyperDRIVE empowers servers to
protect their resources. It empowers applications and objects to pro-
tect themselves, in the manner of [4].
6. Security Considerations
This draft describes a directory infrastructure which may be used to
implement and manage a security policy. The data described by this
schema should be protected from casual observance (i.e. "browsing")
and must be protected from anonymous or unauthorized manipulation.
Implementors must exercise due diligence in assuring the authenti-
cated identity of any entities which are allowed to access and mani-
pulate the data described by this schema. The degree of rigor applied
to the authentication process must be commensurate with the sensi-
tivity of the data or processes which are represented by the schema's
accessor objects.
To this end, the authorization parameters of the directory implemen-
tation underlying the LDAP interface, as well as the authorization
policies of the LDAP interface itself, should be set to the maximum
level of restriction which allows the intended functionality.
Failure to apply this strategy with due diligence may result in expo-
sure of the assets the strategy is intended to shield.
7. References
[1] David F. Ferraiolo and Richard Kuhn, "Role Based Access Control",
Proceedings of the 15th NIST-NSA National Computer Security Confer-
ence, Baltimore, MD, 13-16 October 1992.
URL:http://hissa.ncsl.nist.gov/rbac/paper/rbac1.html
[2] John Barkley, "Implementing Role Based Access Control Using
Object Technology", First ACM/NIST Workshop on Role-Based Access Con-
trol, Gaithersburg, MD, USA, Nov. 1995.
URL:http://hissa.ncsl.nist.gov/rbac/rbacot/titlewrkshp.html
[3] David F. Ferraiolo, Janet A. Cugini, D. Richard Kuhn, "Role-Based
Access Control (RBAC): Features and Motivations", National Institute
of Standards and Technology, U.S. Department of Commerce, Gaithers-
burg, MD 20899, 11th Annual Computer Security Applications
Bartz [Page 15]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
Proceedings 1995.
URL:http://hissa.ncsl.nist.gov/rbac/newpaper/rbac.html
[4] Roy H. Campbell, Tin Qian, Willy Liao, Zhaoyu Liu, "Active Capa-
bility: A Unified security Model for Supporting Mobile, Dynamic and
Application Specific Delegation", Security White Paper, System
Software Research Group, Department of Computer Science, University
of Illinois at Urbana-Champaign, February 16, 1996.
URL:http://choices.cs.uiuc.edu/Security/Papers/delegate.ps
[5] J. Steven Fritzinger, Marianne Mueller, "Java Security", (c)
1996, Sun Microsystems, Inc.
URL:http://www.javasoft.com/security/whitepaper.txt
[6] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Pro-
tocol. Request for Comments (RFC) 1777", March, 1995.
URL:ftp://ds.internic.net/rfc/rfc1777.txt
[7] T. Howes, S. Kille, W. Yeong, C. Robbins, "The String Representa-
tion of Standard Attribute Syntaxes. RFC 1778", March, 1995.
URL:ftp://ds.internic.net/rfc/rfc1778.txt
[8] Rational Software Corporation, "UML Notation Guide, Version 1.0",
January 13, 1997.
URL:http://www.rational.com/uml/start/notation_guide.html
[9] Netscape Communications Corporation, "The SSL Protocol, Version
3.0", March 1996. URL:http://home.netscape.com/eng/ssl3/ssl-toc.html
[10] Satoshi, Hirano, "HORB: Distributed Execution of Java Programs",
Electrotechnical Laboratory and RingServer Project, 1-1-4 Umezono
Tsukuba, 305 Japan, March 1997.
URL:http://ring.etl.go.jp/~hirano/horb_wwwca97.ps
[11] Object Management Group, "OMA Executive Overview", February 3,
1997. URL:http://www.omg.org/omg00/omaov.htm
[12] R. Housley, W. Ford, T. Polk, D. Solo, "Internet Public Key
Infrastructure, Part I: X.509 Certificate and CRL Profile", Internet
Draft,August 1, 1997 URL:ftp://ietf.org/internet-drafts/draft-ietf-
pkix-ipki-part1-05.txt
[13] L. S. Bartz, "hyperDrive: Leveraging LDAP to implement RBAC on
the Web", in Proceedings of the Second ACM RBAC Workshop, pgs. 69-74,
November, 1997. URL:http://hissa.ncsl.nist.gov/rbac/
[14] Thomas J. Mowbray, Raphael C. Malveau, "CORBA Design Patterns",
John Wiley and Sons, Inc., 1997
Bartz [Page 16]
INTERNET-DRAFT LDAP Schema for RBAC October 21, 1997
8. Author's Address
Larry Bartz
Internal Revenue Service
575 N. Pennsylvania Street
Attn: Stop 15
Indianapolis, IN 46204
USA
Phone: +1 317 226-7060
Email: lbartz@infostream.cr.irs.gov
Bartz [Page 17]
