Internet-Draft E. Stokes
LDAP Extensions WG D. Byrne
Intended Category: Standards Track IBM
Expires: 10 September 2000 B. Blakley
Dascom
10 March 2000
Access Control Model for LDAP
<draft-ietf-ldapext-acl-model-05.txt>
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Comments and suggestions on this document are encouraged.
Comments on this document should be sent to the LDAPEXT
working group discussion list:
ietf-ldapext@netscape.com
COPYRIGHT NOTICE
Copyright (C) The Internet Society (1997). All Rights
Reserved.
ABSTRACT
This document describes the access control model for the
Lightweight Directory Application Protocol (LDAP)
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 1]
Internet-Draft Access Control Model 10 March 2000
directory service. It includes a description of the
model, the LDAP controls, and the extended operations to
the LDAP protocol. The current LDAP APIs are sufficient
for most access control operations. An API (in a
separate document) is needed for the extended operation
getEffectiveAccess and specifyCredentials.
The keywords "MUST", "SHOULD", and "MAY" used in this
document are to be interpreted as described in
[Bradner97].
1. Introduction
The ability to securely access (replicate and distribute)
directory information throughout the network is necessary
for successful deployment. LDAP's acceptance as an
access protocol for directory information is driving the
need to provide an access control model definition for
LDAP directory content among servers within an enterprise
and the Internet. Currently LDAP does not define an
access control model, but one is needed to ensure
consistent secure access across heterogeneous LDAP
implementations. The major objective is to provide a
simple, but secure, highly efficient access control model
for LDAP while also providing the appropriate flexibility
to meet the needs of both the Internet and enterprise
environments and policies. This document defines the
model and the protocol extensions (controls and extended
operations).
2. Overview
Access Control mechanisms evaluate requests for access to
protected resources and make decisions about whether
those requests should be granted or denied. In order to
make a grant/deny decision about a request for access to
a protected resource, an access control mechanism needs
to evaluate policy data. This policy data describes
security-relevant characteristics of the requesting
subject and the rules which govern the use of the target
object.
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 2]
Internet-Draft Access Control Model 10 March 2000
The access control model defines
- A wire protocol for interoperability: The existing
LDAP protocol flows for add, delete, modify, and
search are used to manipulate access control
information. There is an additional LDAP control
and extended protocol operation defined,
getEffectiveRights, to further help management of
access control information.
- A set of access control information (ACI) attributes
for application portability: These attributes are
used as input to the LDAP APIs so access control
information can be addressed uniformly independent
of how that information is addressed and stored at
the server. These same attributes appear in LDIF
output for interchange of access control
information.
- A set of attributes to identity the access control
mechanisms supported by a server and in a given part
of the namespace.
Encoding of access control information on the wire is per
the LDAPv3 specifications.
The instantiation of an access control model at the
directory server is not defined in this document.
No mechanisms are defined in this document to control
access to access control information or for storage of
access control information at the server; this is vendor
dependent.
A separate requirements document for access control
exists. The access control model used the requirements
documents as a guideline for the development of this
specification and are reflected in this specification to
the extent that the working group could agree on an
access control model.
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 3]
Internet-Draft Access Control Model 10 March 2000
3. Terminology
An "access control list" contains the access control
policy information controlling access to an object or
collection of objects. An access control list consists
of a set of access control list entries.
An "access control list entry" defines a single subject
security attribute's granted rights for the objects
governed by the access control list to which it belongs.
The "access control information" (aci) for an object or a
collection of objects defines which subject security
attributes entitle a subject to which granted rights.
The access control information for an object may be
stored in an access control list.
An "access decision" is a boolean-valued function which
answers the question: "can the subject with these subject
security attributes perform this operation on this
object?"
An "access decision function" is an algorithm which makes
an access decision based on subject security attributes,
access control information, an object identifier, and an
operation name (possibly augmented by additional
contextual information).
An "access decision function interface" is a programmatic
interface through which applications can request an
access decision.
An "access identity" is an identity which is used by an
access decision function to make an access decision.
An "audit identity" is an identity which does not, in the
absence of additional information, enable a party
receiving and examining it to determine which subject it
belongs to.
A "credential" is a collection of subject security
attributes.
"effective rights" are the complete set of rights a
subject is entitled to based on all access control lists
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 4]
Internet-Draft Access Control Model 10 March 2000
which apply to a specific object and based on all of the
subject's security attributes.
"granted rights" are the complete set of rights an access
control list entitles a subject to based on a specific
subject security attribute.
A "group" is a privilege attribute asserting a subject's
membership in the collection of subjects whose name is
that of the group.
An "identity" is a subject security attribute which is
unique to a single subject.
A "privilege attribute" is a subject security attribute
which may be shared by several subjects.
"required rights" are the complete set of rights needed
to authorize a requester to perform a specific operation
on an object of a specific type.
A "right" is the basic unit of access control
administration. For each object type in an information
system, a security administrator defines a set of
required rights for each operation. For each object in
the system, a security administrator defines a set of
granted rights for each subject security attribute. When
an access decision is required, an access decision
function checks to make sure that the requester's subject
security attributes have been granted all required rights
needed to perform the requested operation on the
specified target object.
A "role" is a privilege attribute asserting a subject's
organizational position and entitlement to perform the
operations appropriate to that organizational position.
A "subject' is an entity which initiate actions in an
information system.
A "subject security attribute" is a defined property
which is used by a security policy evaluation system to
make policy decisions.
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 5]
Internet-Draft Access Control Model 10 March 2000
4. The Model
The access control mechanism described in this draft
addresses these activities:
- Definition of subject security attributes
information
- Definition of access control policy
- Retrieval of subject security attributes
- Retrieval of effective access rights
- Externalization of access control policy information
4.1 Access Control Information Model
This document does not define formats for storage of
access control information; it does define the
operational semantics of access control operations.
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 6]
Internet-Draft Access Control Model 10 March 2000
The diagram below illustrates the componentry of a LDAP
system and the placement of the function specified in
this draft.
+-------------+
| Application |<--attrs to address ACI
+-------------+ - ldapACI
+--------+ - policyOwner
| LDAP |
| Client |
+--------+
|
| <-- LDAP control
| - getEffectiveAccess
|
| <-- LDAP extended operation
| - getEffectiveAccess
v
+-----------------------------+
| LDAP Server (e.g. SLAPD) |
+-----------------------------+
. |
. |
. |
. |
v v
+----------+ +-----------+
| Access | | |<-attrs to define
| Control |<--| Datastore | access control mechanisms
| Manager | | | - supportedACIMechanisms
+----------+ +-----------+ - aCIMechanisms
LDAP clients use the control and extended operation
specified in this document to administer access control
policy enforced by LDAP servers. Servers may store
access control information in any way they choose. In
particular, servers may use the access control mechanisms
of their datastores to store and enforce LDAP access
control, or they may implement access control managers
external to their datastores. Datastores and external
access control managers may implement any access control
rule syntax and semantics they choose, as long as the
semantics are compatible with that defined in the section
titled "Operational Semantics of Access Control
Operations".
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 7]
Internet-Draft Access Control Model 10 March 2000
The access control administration mechanisms specified in
this document are neutral with respect to policy
inheritance mechanisms, explicit vs. implicit denial,
and group nesting.
5. Access Control Mechanism Attributes
There are several attributes defined associated with
access control. Two attributes are defined to identify
which access control mechanisms are supported by a given
server and by a given subtree: supportedACIMechanisms
and aCIMechanisms.
5.1 Root DSE Attribute for Access Control Mechanism
The server advertises which access control mechanisms it
supports by inclusion of the 'supportedACIMechanisms'
attribute in the root DSE. This attribute is a list of
OIDs, each of which identify an access control mechanism
supported by the server.
(<OID to be assigned>
NAME 'supportedACIMechanisms'
DESC list of access control mechanisms supported
by this directory server
SYNTAX LDAPOID
USAGE dSAOperation
)
The access control mechanism defined is:
LDAPv3 <OID to be assigned>
Other vendor access control mechanisms can be defined (by
OID) and are the responsibility of those vendors to
provide the definition and OID.
5.2 Subschema Attribute for Access Control Mechanism
A given naming context must provide information about
which access control mechanisms are in effect for that
portion of the namespace. The following attribute must
be in each subschema entry associated with a naming
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 8]
Internet-Draft Access Control Model 10 March 2000
context whose access control mechanism is different from
adjacent naming contexts supported by that directory
server.
aCIMechanisms lists the values (list of OIDs) that
defines the access control mechanism in effect for the
scope of that subschema entry. More than one mechanism
may be in effect for the scope of that subschema entry.
(<OID to be assigned>
NAME 'aCIMechanisms'
DESC list of access control mechanisms supported
in this subtree
SYNTAX LDAPOID
USAGE dSAOperation
)
6. Access Control Information Attributes
The intent of the following attribute definitions is to
design a common interchange format. Any given LDAP
server should be able to translate the below defined
attributes into a meaningful operation requests. Each
server should be able to understand the attributes; there
should not be any ambiguity into what any part of the
syntax means.
While the end goal is to have a common behavior model
between different LDAP server implementations, the
attribute definition alone will not ensure identical ACL
processing behavior between servers. The semantics of
how a server interprets the ACI syntax are defined in the
"Operational Semantics of Access Control' section of this
document. Additionally, while the server must recognize
and act on the attribute when received over the wire,
there are no requirements for the server to physically
store this attribute.
The attribute definition maintains an assumption that the
receiving server supports inheritance within the security
model. If the server does not support inheritance, the
receiving server must expand any inherited information
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 9]
Internet-Draft Access Control Model 10 March 2000
based on the scope flag. If the server does not support
partial inheritance and both the entry and subtree scope
are used, then entry is the prevailing scope.
Two attributes are defined so access control information
(ACI) can be addressed in a server independent of server
implementation. These attributes are used in typical
LDAP APIs and in LDIF output of ACI. These two attributes
may be queried or set on all directory objects: ldapACI
and policyOwner. Their BNF and definitions are defined
below.
6.1 The BNF
< ldapACI > ::= < acl entry syntax >
< acl entry syntax > ::= <familyOID> + '#' + <scope > + '#'
+ < rights > + '#' + < dnType >
+ '#' + < subjectDn >
< policyOwner > ::= < familyOid > + '#' + <scope >
+ '#' +< dnType > + '#' + < subjectDn >
< subjectDn > ::= < printable string > | "public" | "this"
< familyOid > ::= < oid >
<scope > ::= "entry" | "subtree"
< dnType > ::= "access-id" | "role" | "group" | "subtree"
| "ipAddress" | "kerberosID"
| <printableString>
< kerberosID > ::= < userID > + '@' + < realm >
< userID > ::= < printableString >
< realm > ::= < printableString >
< rights > ::= "grant" + ';' + <permissions> + ';'+<attr>
| "deny" + ';' + <permissions> + ';'+<attr> |
"grant"+';'+<permissions>+';'+"deny"+';'+<permissions>+';'+<attr>
< permissions > ::= [ ] | [ <permission>
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 10]
Internet-Draft Access Control Model 10 March 2000
+ [ ',' + <permission> ] ]*
< attr > ::= ["collection" + ':' + [ "[all]" | "[entry]"
| <printableString>] ]
| ["attribute" + ':' <printableString>]
< permission > ::= "a" | "d" | "r" | "s" | "w" |
"c" | "e" | "b"
These are the permissions defined for the IETF LDAP family
OID.
"a" corresponds to add
"d" corresponds to delete
"r" corresponds to read
"s" corresponds to search
"w" corresponds to write
"c" corresponds to compare
"e" corresponds to editDN
"b" corresponds to browseDN
6.2 Other Defined Parameters
This section defines additional parameters that are used
in the two attributes that address access control
information.
6.2.1 Families and Rights
The familyOID tells what permission set etc. will follow
in the string. This allows a different permission set,
scope etc., but with the same syntax.
The following family is defined:
IETF-LDAPv3 <OID to be assigned>
Other families can be defined (by OID). It is the
responsibility of those parties to provide the definition
and OID.
6.2.1.1 IETF-LDAPv3 Family
Access rights can apply to an entire object or to
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 11]
Internet-Draft Access Control Model 10 March 2000
attributes of the object. Each of the LDAP access rights
are discrete. One permission does not imply another
permission. The rights which apply to attributes and the
entry parallel the type of ldap operations that can be
performed.
Rights which apply to attributes:
r Read Read attribute values
w Write Write attribute values
s Search Search entries with specified attributes
c Compare Compare attributes
Rights that apply to an entire entry:
a Add Add an entry below this entry
d Delete Delete this entry
e EditDN Edit an entry's DN
b BrowseDN Browse an entry's DN
When searching, the ldap search filter specifies the
returned set of attributes. To do the search, browse (b)
must be set for the entry (you can search only entries
that you have permission to search so you can't discover
things you don't have permission to) and search (s) must
be set for all attributes used in the filter if you are
testing for existence, otherwise search (s) and read (r)
must be set for all attributes used in the filter because
the filter specifies a test for other than existence.
For a search to return attribute names only, search (s)
must be set for the attribute. For a search to return
attribute names and values, search (s) and read (r) must
be set for the attribute. Search (s) implies knowledge
of the attribute; read (r) implies knowledge of the
value.
6.2.2 DN Types
The following DN Types strings are defined and MUST be
supported:
- access-id
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 12]
Internet-Draft Access Control Model 10 March 2000
- group
- role
The following DN Types strings are defined and SHOULD be
supported:
- ipAddress
- kerberosID
An access-id is a non-collection (non-group and non-role
objects) DN that can be authenticated.
groupOfNames and groupOfUniqueNames (or subclasses from
those object classes) must be recognized as a collection
object. This aids in interoperability during
replication.
Other parties can (and will) define other DN Types. It
is the responsibility of those parties to provide the
definition.
6.3 Basic ACI Attribute (ldapACI)
(<OID to be assigned>
NAME 'ldapACI'
DESC 'ldap access control information'
EQUALITY caseIgnoreMatch
SYNTAX directoryString
USAGE directoryOperation
)
Within the access control syntax, the family OID
describes the permissions, dnType, subjectDn and scope
that will be found in the following string. If the OID
within the ldapACI attribute is listed as other than the
IETF-LDAPv3 family OID, the syntax is the same, but one
or more of the scope, dnType, subjectDn or permissions
may vary from the defined syntax.
Within the access control syntax, there is a string which
describes the rights. This is a composite of the
permissions and resources to which the subject is being
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 13]
Internet-Draft Access Control Model 10 March 2000
granted or denied access. The set of permissions is
fixed. Either or both of the actions "grant" | "deny"
may be used when creating or updating ldapACI.
<attr> describes either an attribute name or an attribute
collection. The keyword attribute indicates that the
following printable string refers to an attribute name.
If the string refers to an attribute not defined in the
given server's schema, the server SHOULD report an error.
The keyword "collection" indicates that the string that
follows describes a group of attributes. The method for
grouping attributes is server specific. Another option
for the collection printable string is "[entry]". This is
provided to describe permissions which apply to an entire
object. This could mean actions such as delete the
object, or add a child object. The third option for a
collection is "[all]" which means the permission set
should apply to all attributes. Even if the server does
not support attribute grouping, it MUST recognize the
"[all]" and "[entry]" keywords. If the server receives
an unrecognized attribute collection name, the server
SHOULD return an error. If the server supports grouping,
the grouping is server and implementation specific.
If the keyword "[all]" and another attribute are both
specified within an aci, the more specific permission set
for the attribute overrides the less specific permission
set for "[all]".
All permissions (for grant and deny) for an attribute and
a given DN MUST be contained within one ldapACI value,
i.e. (in abbreviated form)
ldapACI: ...grant attr1 DN1
ldapACI: ...deny attr1 DN1
must be ldapACI: ...grant ... deny... attr1 DN1
Using the defined BNF it is possible for the permission
string to be empty. The ACI
ldapACI: 1.2.3.4#subtree#grant;;
attribute:attr1#group#cn=Dept XYZ,c=US
ldapACI: 1.2.3.4#subtree#grant;r,s;
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 14]
Internet-Draft Access Control Model 10 March 2000
collection:[all]#group#cn=Dept XYZ,c=US
means that this group (Dept XYZ) is granted permission to
read and search all attributes except attr1 because attr1
is more specific than "[all]".
6.3.1 LDAP Operations
The attributes which are defined for access control
interchange may be used in all LDAP operations.
Within the ldapmodify-delete operation, the entire acl
may be deleted by specifying
dn: cn = some Entry
changetype: modify
delete: ldapACI
In this case, the entry would then inherit its ACI from
some other node in the tree depending on the server
inheritance model.
Similarly, if all values of ldapACI are deleted, then the
access control information for that entry is defined by
that implementation's inheritance model.
6.3.2 Grant/Deny Evaluation Rules
More specific policies must override less specific ones
(e.g. individual user entry in ACI takes precedence over
group entry).
Deny takes precedence over Grant. When there are
conflicting ACI values, deny takes precedence over grant.
Deny is the default when there is no access control
information.
Precendence of Scope Types (highest to lowest)
- entry
- subtree
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 15]
Internet-Draft Access Control Model 10 March 2000
Precedence of Privilege Attribute dnTypes within a scope
(highest to lowest):
- ipAddress
- access-id, kerberosID (both same precedence)
- group
- role
- subtree
Although other types can be defined given the BNF, use of
the well-known types aids in interoperability and
operational consistency.
6.4 Policy Owner Attribute (policyOwner)
(<OID to be assigned>
NAME 'policyOwner'
DESC 'Policy Owner Access Control Information'
EQUALITY caseIgnoreMatch
SYNTAX directoryString
USAGE directoryOperation
)
Policy ownership controls administrative subdomains. It
can also control who has permission to set / change acls
for implementations that do not have ACI controlling
access to itself. If there are multiple policy owners
it is implementation specific as to the behavior of
whether policy owner #1 can override policy owner # 2.
The syntax for policyOwner includes the 'scope' flag.
Servers which do not support inheritance must expand the
policyOwner inheritance similar to the expansion of the
ACI. The scope and any inheritance hierarchy for policy
ownership is distinct from any inheritance hierarchy
defined for ACI values.
If the policy owner is not specified for any object in
the tree, behavior is implementation defined. For
instance, if no object anywhere in the tree has a policy
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 16]
Internet-Draft Access Control Model 10 March 2000
owner, then the server could simply assert that the 'root
DN' is considered the policy owner for all objects. An
alternate approach might be that the implementation
defines the entryDN to be the policy owner.
6.5 ACI Examples
The examples use a family OID = 1.2.3.4
6.5.1 Attribute Definition
The following two examples show an administrative
subdomain being established. The first example shows a
single user being assigned the policyOwner for the entire
domain. The second example shows a group of IDs assigned
to the policy Owner.
policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt
policyOwner: 1.2.3.4#subtree#group#cn=System
Owners,o=Company
The next example shows a ldapACI attribute where a group
"cn=Dept XYZ, c=US" is being given permissions to read,
search and compare attribute attr1. The permission
applies to the entire subtree below the node containing
this ACI.
ldapACI:1.2.3.4#subtree#grant;r,s,c;
attribute:attr1#group#cn=Dept XYZ,c=US
The next example shows an ACI attribute where a role
"cn=SysAdmins,o=Company" is being given permissions to
add objects below this node and read, search, and compare
attributes attr2 and attr3. The permission applies to the
entire subtree below the node containing this ACI.
ldapACI: 1.2.3.4#subtree#grant;a;
collection:[entry]#role#cn=SysAdmins,o=Company
ldapACI: 1.2.3.4#subtree#grant;r,s,c;
attribute:attr2#role#cn=SysAdmins,o=Company
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 17]
Internet-Draft Access Control Model 10 March 2000
ldapACI: 1.2.3.4#subtree#grant;r,s,c;
attribute:attr3#role#cn=SysAdmins,o=Company
6.5.2 Modifying the ldapACI Values
Modify-Replace works as defined in the ldap oepration
modify. If the attribute value does not exist, create the
value. If the attribute does exist, replace the value. If
the ldapACI value is replaced, all ldapACI values are
replaced.
A given ldapACI for an entry:
ldapACI: 1.2.3.4#subtree#deny;r,w;
collection:[all]#group#cn=Dept ABC
ldapACI: 1.2.3.4#subtree#grant;r;
attribute:attr1#group#cn=Dept XYZ
perform the following change:
dn: cn=someEntry
changetype: modify
replace: ldapACI
ldapACI: 1.2.3.4#subtree#grant;r,w;
collection:[all];#group#cn=Dept LMN
The resulting ACI is:
ldapACI: 1.2.3.4#subtree#grant;r,w;
collection:[all];#group#cn=Dept LMN
( ldapACI values for Dept XYZ and ABC are lost through the
replace )
During an ldapmodify-add, if the ACI does not exist, the
create the ACI with the specific ldapACI value(s). If the
ACI does exist, then add the specified values to the given
ldapACI. For example a given ACI:
ldapACI: 1.2.3.4#subtree#grant;r,w;
collection:[all]#group#cn=Dept XYZ
with a modification:
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 18]
Internet-Draft Access Control Model 10 March 2000
dn: cn=someEntry
changetype: modify
add: ldapACI
ldapACI: 1.2.3.4#subtree#grant;r;
attribute:attr1#group#cn=Dept XYZ
would yield an multi-valued aci of:
ldapACI: 1.2.3.4#subtree#grant;r,w;
collection:[all]#group#cn=Dept XYZ
ldapACI: 1.2.3.4#subtree#grant;r;
attribute:attr1#group#cn=Dept XYZ
To delete a particular ACI value, use the regular ldapmodify
- delete syntax
Given an ACI of:
ldapACI: 1.2.3.4#subtree#grant;r,w;
collection:[all]#group#cn=Dept XYZ
ldapACI: 1.2.3.4#subtree#grant;r;
attribute:attr1#group#cn=Dept XYZ
dn: cn = some Entry
changetype: modify
delete: ldapACI
ldapACI: 1.2.3.4#subtree#grant;r;
attribute:attr1#group#cn=Dept XYZ
would yield a remaining ACI on the server of
ldapACI: 1.2.3.4#subtree#grant;r,w;
collection:[all]#group#cn=Dept XYZ
6.5.3 Evaluation
These examples assume that the ldapACI entries listed in
each example are the only ACI which applies to the entry
in question; if backing-store ACI also exists, the
effective policy may be different from that listed in
each example. See section 7 for a discussion of the
semantics of ldapACI entries when backing-store ACI
administration is also used.
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 19]
Internet-Draft Access Control Model 10 March 2000
Assume cn=jsmith is a member of group cn=G1. Assume
cn=jsmith is a member of group cn=G2.
Example #1
dn: o=XYZ, c=US
ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr1;
#access-id#cn=jsmith,ou=ABC,o=XYZ,c=US
ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr1;
#group#cn=G1,ou=ABC,o=XYZ,c=US
What rights does cn=jsmith have to attr1 of o=XYZ,c=US?
Read (r) access; access-id is higher precedence than
group.
Example #2
dn: o=XYZ, c=US
ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr2;
#group#cn=G1,ou=ABC,o=XYZ,c=US
ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr2;
#group#cn=G2,ou=ABC,o=XYZ,c=US
What rights does cn=jsmith have to attr2 of o=XYZ,c=US?
Read-write (r,w) access; ACI is combined because both
dnTypes (group) have same precedence.
Example #3
dn: o=XYZ, c=US
ldapACI: 1.2.3.4#subtree#grant;r,w;attribute:attr3;
#group#cn=G1,ou=ABC,o=XYZ,c=US
ldapACI: 1.2.3.4#subtree#deny;w;attribute:attr3;
#group#cn=G2,ou=ABC,o=XYZ,c=US
What rights does cn=jsmith have to attr3 of o=XYZ, c=US?
Read access; write is denied (deny has precedence over
grant).
Example #4
dn: o=XYZ, c=US
ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr4;
#access-id#cn=jsmith,ou=ABC,o=XYZ,c=US
ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr4;
#subtree#ou=ABC,ou=XYZ,c=US
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 20]
Internet-Draft Access Control Model 10 March 2000
What rights does cn=jsmith have to attr4 of o=XYZ, c=US?
Write (w); rights given to an access-id take precedence
over those given to a subtree.
7. Operational Semantics of Access Control Operations
The semantics of access control operations described in
this document are defined operationally in terms of
"histories". A history is a sequence of actions (x1, x2,
..., xN).
7.1 Types of actions
We consider five types of actions:
- LDAP Access Control Policy Update actions:
invocations of ldap modify when used to add, delete,
or replace the aci attribute; invocations of ldap
add when used to add an entry with an aci attribute.
A LDAP Access Control Policy Update action may
replace the policy (by completely replacing the aci
attribute with new policy information) or it may
grant or deny specific rights while leaving others
unaffected.
- LDAP Access Control Policy Query operations:
invocations of ldap search when used to retrieve the
aci attribute; invocations of ldap search with the
getEffectiveRightsRequest control; invocations of
the ldapGetEffectiveRightsRequest extended
operation.
- Datastore Access Control Policy Update Actions: any
operation implemented by the server which LDAP is
using as its datastore which changes the access
policy enforced with respect to attempts to access
LDAP directory entries and their attributes.
- LDAP Access Request operations: invocations of LDAP
entry or attribute access operations (Read, Update,
Search, Compare, etc...).
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 21]
Internet-Draft Access Control Model 10 March 2000
- Other operations: anything else, including Datastore
operations which do not change the access policy
enforced by the server.
7.2 Semantics of Histories
The semantics of histories are defined as follows:
- LDAP Update (Replace), LDAP Query
The Query will show that the subject has all rights
granted by the Update operation, and no rights not
granted by the Update operation.
- LDAP Update (Grant), LDAP Query
The Query will show that the subject has all rights
granted by the Update operation. The Query may show
that the subject also has other rights not granted
by the Update operation, depending on the policy in
force before the Update operation.
- LDAP Update (Deny), LDAP Query
The Query will show that the subject does not have
any right denied by the Update operation. The Query
may show that the subject has rights not denied by
the Update operation, depending on the policy in
force before the Update operation.
- LDAP Update (Replace), LDAP Access Request
The Request will succeed if it requires only rights
granted to the requesting subject by the Update
operation. The Request will fail if it requires any
right not granted by the Update operation.
- LDAP Update (Grant), LDAP Access Request
The Request will succeed if it requires only rights
granted to the requesting subject by the Update
operation. The Request may succeed if it requires
rights not granted by the Update operation,
depending on the policy in force before the Update
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 22]
Internet-Draft Access Control Model 10 March 2000
operation.
- LDAP Update (Deny), LDAP Access Request
The Request will fail if it requires any right
denied to the requesting subject by the Update
operation. If the Request requires only rights
which were not denied by the Update operation, it
may succeed, depending on the policy in force before
the Update operation.
- LDAP Update (Replace), Other, LDAP Query
The Query will show that the subject has all rights
granted by the Update operation, and no rights not
granted by the Update operation.
- LDAP Update (Grant), Other, LDAP Query
The Query will show that the subject has all rights
granted by the Update operation. The Query may show
that the subject also has other rights not granted
by the Update operation, depending on the policy in
force before the Update operation.
- LDAP Update (Deny), Other, LDAP Query
The Query will show that the subject does not have
any right denied by the Update operation. The Query
may show that the subject has rights not denied by
the Update operation, depending on the policy in
force before the Update operation.
- LDAP Update (Replace), Other, LDAP Access Request
The Request will succeed if it requires only rights
granted to the requesting subject by the Update
operation. The Request will fail if it requires any
right not granted by the Update operation.
- LDAP Update (Grant), Other, LDAP Access Request
The Request will succeed if it requires only rights
granted to the requesting subject by the Update
operation. The Request may succeed if it requires
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 23]
Internet-Draft Access Control Model 10 March 2000
rights not granted by the Update operation,
depending on the policy in force before the Update
operation.
- LDAP Update (Deny), Other, LDAP Access Request
The Request will fail if it requires any right
denied to the requesting subject by the Update
operation. If the Request requires only rights
which were not denied by the Update operation, it
may succeed, depending on the policy in force before
the Update operation.
- LDAP Update (Replace), Datastore Policy Update, LDAP
Query
The result of the Query is not defined.
- LDAP Update (Grant), Datastore Policy Update, LDAP
Query
The result of the Query is not defined.
- LDAP Update (Deny), Datastore Policy Update, LDAP
Query
The result of the Query is not defined.
- LDAP Update (Replace), Datastore Policy Update, LDAP
Access Request
The result of the Access Request is not defined.
- LDAP Update (Grant), Datastore Policy Update, LDAP
Access Request
The result of the Access Request is not defined.
- LDAP Update (Deny), Datastore Policy Update, LDAP
Access Request
The result of the Access Request is not defined.
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 24]
Internet-Draft Access Control Model 10 March 2000
8. Access Control Parameters for LDAP Controls & Extended
Operations
This section defines the parameters used in the access
control LDAP controls and extended operations in this
document.
targetDN specifies the initial directory entry in DN
syntax on which the control or extended operation is
performed.
whichObject specifies whether the access control
information (in the get effective rights control) which
is retrieved is for the target directory entry (ENTRY) or
the target directory entry and its subtree (SUBTREE).
family specifies the family OID that will be retrieved
for the get effective rights control or extended
operation performed. A family has a defined set of
rights, among other things.
rights in the get effective rights control or extended
operation response is of the form specified in the BNF
for <rights>.
dnType speficies the type of subject security attribute.
Defined types are specified in the BNF.
subjectDN is a LDAP string that defines the subject or
value of the dnType. The subjectDN may be a DN or
another string such as IPAddress (dotted-decimal string
representation) on which access control is get/set. If
the subject is an entry in the directory, then the syntax
of the LDAP string is DN. The well-known subjectDNs
strings are defined
- public - meaning public access for all users
- this - meaning the user whose name matches the entry
being accessed
- * - meaning everyone who has access to the entry
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 25]
Internet-Draft Access Control Model 10 March 2000
9. Access Control Information (ACI) Controls
The access control information controls provide a way to
manipulate access control information in conjunction with
a LDAP operation. One LDAP control is defined. This
control allows access control information to be get/set
while manipulating other directory information for that
entry. The control is:
- getEffectiveRights to obtain the effective rights
for a given directory entry(s) for a given subject
during a ldap_search operation
9.1 getEffectiveRights Control
9.1.1 Request Control
This control may only be included in the ldap_search
message as part of the controls field of the
LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
The controlType is set to <OID to be assigned>. The
criticality MAY be either TRUE or FALSE (where absent is
also equivalent to FALSE) at the client's option. The
controlValue is an OCTET STRING, whose value is the BER
encoding of a value of the following SEQUENCE:
getEffectiveRightsRequest ::= SEQUENCE {
effectiveRightsRequest SEQUENCE OF SEQUENCE {
family LDAPOID | "*",
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType "access-id"|"group"|"role"|
"ipAddress"|"kerberosID"|
<printableString> | "*",
subjectDN LDAPString | "public" |
"this" | "*"
}
}
The effectiveRightsRequest is a set of sequences that
state the whichObject (entry or entry plus subtree) and
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 26]
Internet-Draft Access Control Model 10 March 2000
specifics of the control request to be performed. One or
more family can be be obtained for a given subjectDN ad
dnType. A "*" in the family field indicates that the
rights for all families defined for the subjectDN /
dnType are to be returned. A "*" in the dnType field
specifies that all DN types are to be used in returning
the effective rights. This control is applied to the
filter and scope set by the ldap_search operation, i.e.
base, one-level, subtree. So the attributes/values
returned are defined by the ldap_search operation.
9.1.2 Response Control
This control is included in the ldap_search_response
message as part of the controls field of the LDAPMessage,
as defined in Section 4.1.12 of [LDAPv3].
The controlType is set to <OID to be assigned>. There is
no need to set the criticality on the response. The
controlValue is an OCTET STRING, whose value is the BER
encoding of a value of the following SEQUENCE:
getEffectiveRightsResponse ::= {
result ENUMERATED {
success (0),
operationsError (1),
unavailableCriticalExtension (12),
noSuchAttribute (16),
undefinedAttributeType (17),
invalidAttributeSyntax (21),
insufficientRights (50),
unavailable (52),
unwillingToPerform (53),
other (80)
}
}
The effective rights returned are returned with each
entry returned by the search result. The control
response for ldap_search is:
PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
family LDAPOID,
rights <see <rights> in BNF>,
whichObject ENUMERATED {
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 27]
Internet-Draft Access Control Model 10 March 2000
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType "access-id"|"group"|
"role"|"ipAddress"|
"kerberosID"|
<printableString> |
"*",
subjectDN LDAPString | "public" |
"this" | "*"
}
Although this extends the search operation, there are no
incompatibilities between versions. LDAPv2 cannot send a
control, hence the above structure cannot be returned to
a LDAPv2 client. A LDAPv3 client cannot send this
request to a LDAPv2 server. A LDAPv3 server not
supporting this control cannot return the additional
data.
9.1.3 Client-Server Interaction
The getEffectiveRightsRequest control requests the rights
that MUST be in effect for requested directory
entry/attribute based on the subject DN. The server that
consumes the search operation looks up the rights for the
returned directory information based on the subject DN
and returns that rights information.
There are six possible scenarios that may occur as a
result of the getEffectiveRights control being included
on the search request:
1. If the server does not support this control and the
client specified TRUE for the control's criticality
field, then the server MUST return
unavailableCriticalExtension as a return code in
the searchResponse message and not send back any
other results. This behavior is specified in
section 4.1.12 of [LDAPv3].
2. If the server does not support this control and the
client specified FALSE for the control's
criticality field, then the server MUST ignore the
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 28]
Internet-Draft Access Control Model 10 March 2000
control and process the request as if it were not
present. This behavior is specified in section
4.1.12 of [LDAPv3].
3. If the server supports this control but for some
reason such as cannot process specified family and
the client specified TRUE for the control's
criticality field, then the server SHOULD do the
following: return unavailableCriticalExtension as a
return code in the searchResult message.
4. If the server supports this control but for some
reason such as cannot process specified family and
the client specified FALSE for the control's
criticality field, then the server should process
as 'no rights returned for that family' and include
the result Unavailable in the
getEffectiveRightsResponse control in the
searchResult message.
5. If the server supports this control and can return
the rights per the family information, then it
should include the getEffectiveRightsResponse
control in the searchResult message with a result
of success.
6. If the search request failed for any other reason,
then the server SHOULD omit the
getEffectiveRightsResponse control from the
searchResult message.
The client application is assured that the correct rights
are returned for scope of the search operation if and
only if the getEffectiveRightsResponse control returns
the rights. If the server omits the
getEffectiveRightsResponse control from the searchResult
message, the client SHOULD assume that the control was
ignored by the server.
The getEffectiveRightsResponse control, if included by
the server in the searchResponse message, should have the
getEffectiveRightsResult set to either success if the
rights are returned or set to the appropriate error code
as to why the rights could not be returned.
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 29]
Internet-Draft Access Control Model 10 March 2000
The server may not be able to return a right because it
may not exist in that directory object's attribute; in
this case, the rights request is ignored with success.
10. Access Control Extended Operation
An extended operation, get effective rights, is defined
to obtain the effective rights for a given directory
entry for a given subject. This operation may help with
the management of access control information independent
of manipulating other directory information.
10.1 LDAP Get Effective Rights Operation
ldapGetEffectiveRightsRequest ::= [APPLICATION 23]
SEQUENCE {
requestName [0] <OID to be assigned>,
requestValue [1] OCTET STRING OPTIONAL }
where
requestValue ::= SEQUENCE {
targetDN LDAPDN,
updates SEQUENCE OF SEQUENCE {
family LDAPOID | "*",
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
attr SEQUENCE {
attr <see <attr> in BNF >
},
dnType "access-id"|"group"|
"role"|"ipAddress"|
"kerberosID"|
<printableString> |
"*",
subjectDN LDAPString | "public" |
"this" | "*"
}
}
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 30]
Internet-Draft Access Control Model 10 March 2000
The requestName is a dotted-decimal representation of the
OBJECT IDENTIFIER corresponding to the request. The
requestValue is information in a form defined by that
request, encapsulated inside an OCTET STRING.
The server will respond to this with an LDAPMessage
containing the ExtendedResponse which is a rights list.
ldapGetEffectiveRightsResponse ::= [APPLICATION 24]
SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] <OID to be assigned> OPTIONAL,
effectiveRights [11] OCTET STRING OPTIONAL }
where
effectiveRights ::= SEQUENCE OF SEQUENCE {
family LDAPOID,
rights <see <rights> in BNF>,
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType "access-id"|"group"|"role"|
"ipAddress"|"kerberosID"|
<printableString>,
subjectDN LDAPString | "public" | "this"
}
If the server does not recognize the request name, it
MUST return only the response fields from LDAPResult,
containing the protocolError result code.
11. Security Considerations
This document proposes protocol elements for transmission
of security policy information. Security considerations
are discussed throughout this draft. Because subject
security attribute information is used to evaluate
decision requests, it is security-sensitive information
and must be protected against unauthorized modification
whenever it is stored or transmitted.
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 31]
Internet-Draft Access Control Model 10 March 2000
12. References
[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3)", RFC 2251, December 1997.
[ECMA] ECMA, "Security in Open Systems: A Security
Framework" ECMA TR/46, July 1988
[REQTS] Stokes, Byrne, Blakley, "Access Control
Requirements for LDAP", INTERNET-DRAFT <draft-ietf-
ldapext-acl-reqts-03.txt>, February 2000.
[ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille,
"Lightweight Directory Access Protocol (v3)": Attribute
Syntax Definitions, RFC 2252, December 1997.
[UTF] M. Wahl, S. Kille, "Lightweight Directory Access
Protocol (v3)": A UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.
[Bradner97] Bradner, Scott, "Key Words for use in RFCs to
Indicate Requirement Levels", RFC 2119.
AUTHOR(S) ADDRESS
Ellen Stokes Bob Blakley
IBM Dascom
11400 Burnet Rd 5515 Balcones Drive
Austin, TX 78758 Austin, TX 78731
USA USA
mail-to: stokes@austin.ibm.com mail-to: blakley@dascom.com
phone: +1 512 838 3725 phone: +1 512 458 4037 ext 5012
fax: +1 512 838 8597 fax: +1 512 458 237
Debbie Byrne
IBM
11400 Burnet Rd
Austin, TX 78758
USA
mail-to: djbyrne@us.ibm.com
phone: +1 512 838 1960
fax: +1 512 838 8597
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 32]
Internet-Draft Access Control Model 10 March 2000
Stokes, Byrne, Blakley Expires 10 September 2000 [Page 33]
CONTENTS
1. Introduction....................................... 2
2. Overview........................................... 2
3. Terminology........................................ 4
4. The Model.......................................... 6
4.1 Access Control Information Model............. 6
5. Access Control Mechanism Attributes................ 8
5.1 Root DSE Attribute for Access Control
Mechanism.................................... 8
5.2 Subschema Attribute for Access Control
Mechanism.................................... 8
6. Access Control Information Attributes.............. 9
6.1 The BNF...................................... 10
6.2 Other Defined Parameters..................... 11
6.2.1 Families and Rights 11
6.2.2 DN Types 12
6.3 Basic ACI Attribute (ldapACI)................ 13
6.3.1 LDAP Operations 15
6.3.2 Grant/Deny Evaluation Rules 15
6.4 Policy Owner Attribute (policyOwner)......... 16
6.5 ACI Examples................................. 17
6.5.1 Attribute Definition 17
6.5.2 Modifying the ldapACI Values 18
6.5.3 Evaluation 19
7. Operational Semantics of Access Control
Operations......................................... 21
7.1 Types of actions............................. 21
7.2 Semantics of Histories....................... 22
8. Access Control Parameters for LDAP Controls &
Extended Operations................................ 25
9. Access Control Information (ACI) Controls.......... 26
9.1 getEffectiveRights Control................... 26
9.1.1 Request Control 26
9.1.2 Response Control 27
9.1.3 Client-Server Interaction 28
- i -
10. Access Control Extended Operation.................. 30
10.1 LDAP Get Effective Rights Operation.......... 30
11. Security Considerations............................ 31
12. References......................................... 32
- ii -
Full Copyright Statement
Copyright (C) The Internet Society (1999).á All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works.á However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
- iii -
