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 | | | <> execURL | | | | | | | | | organizational- | | | certificate | | | -UnitDN | | | | | | | | | review+ApprovalDN| | | includedRole | | | | | | | | | maintenanceDN | | | conflictingRole | | | | | | | | | member | | | review+ApprovalDN| | | | | | | | | operationType | | | maintenanceDN | | | | | | | | +------------------+ | | +------------+ | | +------------------+ | | | Operations |<>----+ | hyperDrivePerson | | | +------------+-+ | +------------------+ | | | | | | | | | |<> | | | | | | |<> | | | | | | |______________| | | maintenanceDN | | +------------------+ | | | | +-------+ | | | | Roles |<>---------+ | +-------+------+ | | | | | | |<> | | | |<> | | | |______________| | +------------------+ 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]