Internet-Draft E. Stokes
LDAP Extensions WG B. Blakley
Intended Category: Standards Track Tivoli Systems
Expires: 2 September 2001 D. Rinkevich
IBM
R. Byrne
Sun Microsystems
2 March 2001
Access Control Model for LDAPv3
<draft-ietf-ldapext-acl-model-07.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 (2000). All Rights
Reserved.
ABSTRACT
This document describes the access control model for the
Lightweight Directory Application Protocol V3 (LDAPv3)
directory service. It includes a description of the model,
the schema for the model, and the LDAP control to the LDAP
protocol. The current LDAP APIs are sufficient for the
Stokes, et al Expires 2 September 2001 [Page 1]
Internet-Draft Access Control Model 2 March 2001
access control operations. A separate requirements document
for access control exists [REQTS]. The access control model
used the requirements document 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 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,
replication, and management across heterogeneous LDAP
implementations. The major objective is to provide a simple,
usable, and implementable, but secure and efficient access
control model for LDAP accessible directory content while
also providing the appropriate flexibility to meet the needs
of both the Internet and enterprise environments and
policies. This document defines the model, the schema, and
the LDAP control.
This draft does not (and cannot) fully specify the behavior
of the Access Control Model in a distributed environment
(e.g. propagating access control information across servers
and ACI administration) because there is no LDAP standard
defining how to distribute directory data between LDAP
servers. The behavior of the Access Control Model in
distributed environments is beyond the scope of this draft.
***NOTE TO READERS***
This draft has been updated to reflect most, but not all, of
the previous comments. The list of items still to be
updated in this is draft are:
- search operation / permissions, section 5.2
Stokes, et al Expires 2 September 2001 [Page 2]
Internet-Draft Access Control Model 2 March 2001
- filter use in ACI
- permission extensibility for extended operations
- proxy permission
- equality matching rule for ACI attributes entryACI and
subtreeACI
- ACI binary representation (section 4.1.2) to match the
BNF (section 4.1.1) for <rights>
- syntax and matching rule clauses of entryACI and
subtreeACI definitions in section 4 to match section
4.1.2
2. The LDAPv3 Access Control Model
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.
No mechanism is defined in this document for storage of
access control information at the server beyond indicating
that the attribute holding access control information is an
operational attribute.
The access control mechanisms specified in this document are
neutral with respect to policy inheritance mechanisms,
explicit vs. implicit denial, and group nesting.
The access control model defines
- What flows on the wire for interoperability
The existing LDAP protocol flows for ldap operations
are used to manipulate access control information. A
set of permissions and their semantics with respect to
ldap operations is defined. The permissions parallel
the defined set of ldap operations. What is
transmitted is exactly what is read back. Encoding of
access control information on the wire is per the
LDAPv3 specifications.
Stokes, et al Expires 2 September 2001 [Page 3]
Internet-Draft Access Control Model 2 March 2001
There is a LDAP control defined, GetEffectiveRights.
LDAP clients use the control to manage and 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/exploit access control managers external to
their datastores. Datastores and external access
control managers MAY implement any access control rule
syntax and semantics they choose, but the semantics
MUST be compatible with those defined in the section
titled "Required Permissions for Each LDAP Operation".
- Attributes and classes for application portability of
access control information
Two access control information attribute (entryACI and
subtreeACI) 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 accessed and
stored at the server. This same attribute appears in
LDIF output for interchange of access control
information.
An access control information subentry class
(ldapACISubEntry) and a set of attributes
(supportedAccessControlSchemes which is used in the
rootDSE, and accessControlSchemes which is used in the
subentry ldapACISubEntry) to identity the access
control mechanisms supported by a server and in a given
part of the namespace, respectively.
- A mechanism to control access to access control
information: The access control information
operational attributes, entryACI and subtreeACI, are
also used to control access to access control
information (controls access to itself). How to get
initial entryACI and subtreeACI attributes in the
directory is server specific and beyond the scope of
this model.
Servers can support multiple access control mechanisms, but
MUST be capable of supporting the LDAP Mechanism in the DIT
scoped by the rootDSE (entire server's DIT) for that server
and SHOULD be capable of supporting the LDAP mechanism in an
arbitrary part (subtree) of the DIT.
The accessControlSchemes attribute in the ldapACISubEntry
Stokes, et al Expires 2 September 2001 [Page 4]
Internet-Draft Access Control Model 2 March 2001
indicates which access control mechanisms are in effect for
the scope of that ldapACISubEntry. The
supportedAccessControlSchemes attribute in the rootDSE
indicates which acess control mechanisms are supported by
the server; those mechanisms are in effect in that server's
DIT unless overridden by a mechanism defined in a
ldapACISubEntry elsewhere in that DIT.
Changing the value(s) of either the
supportedAccessControlSchemes or accessControlSchemes
attributes changes the mechanism(s) in effect for the scope
of those attributes (where scope is either that of the
rootDSE or ldapACISubEntry).
Through the use of the supportedAccessControlSchemes
attrbiute in the rootDSE and the accessControlSchemes
attribute in the ldapACISubEntry, it is possible to run
multiple mechanisms in either the same subtree or separate
subtrees. If two mechanisms are run in the same subtree, it
is desirable that the result be the same independent of
mechanism, but definition and discussion of this is beyond
the scope of this model.
3. Access Control Mechanism Attributes
Two attributes are defined to identify which access control
mechanisms are supported by a given server and by a given
subtree: supportedAccessControlSchemes and
accessControlSchemes. (We chose these names based on the
X.500 attribute, AccessControlScheme which is single-valued
and defined in X.501).
3.1 Root DSE Attribute for Access Control Mechanism
The server advertises which access control mechanisms it
supports by inclusion of the 'supportedAccessControlSchemes'
attribute in the root DSE. This attribute is a list of
OIDs, each of which identify an access control mechanism
supported by the server. By default, these are also the
mechanisms in effect in subtrees beneath the root in that
server unless overridden by a ldapACISubEntry (see section
"Subentry Class Access Control Mechanism").
(<OID to be assigned>
NAME 'supportedAccessControlSchemes'
DESC list of access control mechanisms supported
by this directory server
EQUALITY objectIdentifierMatch
Stokes, et al Expires 2 September 2001 [Page 5]
Internet-Draft Access Control Model 2 March 2001
SYNTAX OID
USAGE dSAOperation
)
The access control mechanism defined is:
LDAPv3 <OID to be assigned>
Other vendor access control mechanisms MAY be defined (by
OID) and are the responsibility of those vendors to provide
the definition and OID.
3.2 Subentry Class Access Control Mechanism
A given naming context MUST provide information about which
access control mechanisms are in effect for that portion of
the namespace. This information is contained in a subentry
(ldapACISubEntry class), derived from [SUBENTRY].
ldapACISubEntry MAY be used to define the scope of an access
control mechanism. The value(s) held in the rootDSE
attribute, supportedAccessControlSchemes, are the mechanisms
in effect in subtrees beneath the root in that server unless
overridden in a ldapACISubEntry further down the tree held
by that server. The scope of that ldapACISubEntry is to the
end of the subtree held by that server or until another
ldapACISubEntry is encountered in that subtree held by that
server. The ldapACISubEntry class is defined as:
( <OID to be assigned>
NAME 'ldapACISubEntry'
DESC 'LDAP ACI Subentry class'
SUP ldapSubEntry STRUCTURAL
MUST ( accessControlSchemes )
)
The accessControlSchemes attribute MUST be in each
ldapACISubEntry entry associated with a naming context whose
access control mechanism is different from adjacent naming
contexts supported by that directory server.
accessControlSchemes lists the values (list of OIDs) that
define the access control mechanisms in effect for the scope
of that ldap access control subentry (either until another
ldapACISubEntry is encountered in that subtree or end of
subtree is reached on the server). Although, in general,
this attribute will define only a single mechanism (single
value), more than one mechanism MAY be in effect for the
scope of that subentry.
(<OID to be assigned>
NAME 'accessControlSchemes'
Stokes, et al Expires 2 September 2001 [Page 6]
Internet-Draft Access Control Model 2 March 2001
DESC list of access control mechanisms supported
in this subtree
EQUALITY objectIdentifierMatch
SYNTAX OID
USAGE dSAOperation
)
4. The Access Control Information Attributes
The access control information attributes, entryACI and
subtreeACI, are defined as:
(<OID to be assigned>
NAME 'entryACI'
DESC 'ldap access control information, scope of
entry'
EQUALITY caseIgnoreMatch
SYNTAX directoryString
USAGE directoryOperation
)
(<OID to be assigned>
NAME 'subtreeACI'
DESC 'ldap access control information, scope of
subtree'
EQUALITY caseIgnoreMatch
SYNTAX directoryString
USAGE directoryOperation
)
The intent of the attribute definitions is to define a
common interchange format and have a separation of
responsibilities to allow different people to administer the
different attribute types. (X.500 overcomes this by allowing
access control on a per-value basis, which is complex). Any
given LDAP server should be able to translate the defined
attribute into meaningful requests. Each server should be
able to understand the attribute; 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
definitions alone will not ensure identical ACL processing
behavior between servers. The semantics of how a server
interprets the ACI syntax are defined in the "Required
Permissions for Each LDAP Operation" section of this
document. Additionally, while the server must recognize and
act on the attribute when received over the wire, there are
Stokes, et al Expires 2 September 2001 [Page 7]
Internet-Draft Access Control Model 2 March 2001
no requirements for the server to physically store these
attributes.
The attribute definitions maintain an assumption that the
receiving server supports ACI inheritance within the
security model. If the server does not support inheritance,
the receiving server must expand any inherited information
based on the scope flag.
The 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 attributes may be
queried or set on all directory objects. The BNF and
definitions are given below.
4.1 The BNF
4.1.1 ACI UTF-8 String Representation
Values of this syntax are encoded according to the
following BNF which follows the BNF encoding
conventions described in [ABNF]:
entryACI = rights "#" attr "#" subject
subtreeACI = rights "#" attr "#" subject
rights = (("grant:" / "deny:") permissions) /
("grant:" permissions ";deny:" permissions)
permissions = ([permission ("," permission)*])
permission = "a" / ; add
"d" / ; delete
"e" / ; export
"i" / ; import
"n" / ; renameDN
"b" / ; browseDN
"t" / ; returnDN
"r" / ; read
"s" / ; search
"w" / ; write (mod-add)
"o" / ; obliterate (mod-del)
"c" / ; compare
"m" / ; make
; permissions r, w, o, s, c, m work on attributes
; permisisons a, d, e, i, n, b, t work on entries
Stokes, et al Expires 2 September 2001 [Page 8]
Internet-Draft Access Control Model 2 March 2001
attr = "[all]" / "[entry]" / (attribute ("," attribute)*)
attribute = ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38)
; from [ATTR]
subject = ["authnLevel:" authnLevel ":"]
(("authzID-" authzID) /
("role:" dn) /
("group:" dn) /
("subtree:" dn) /
("ipAddress:" ipAddress) /
"public:" /
"this:")
authnLevel = "any" /
"simple" /
sasl /
"none" /
"anonymous" /
sasl = "sasl:"
("any" /
mechanism)
mechanism = ; sasl mechanism from 4.2 of [LDAPv3]
authzID = ; authzID from [AuthMeth] repeated below
; for convenience
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
dn = utf8string ; with syntax defined in [UTF]
; unspecified userid, UTF-8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; syntax unspecified
; IP address
ipAddress = IPv6address | printableString
; printableString to use a wildcard
; domain name such as *.airius.com
; to specify a specific DNS domain
; following is excerpted from [IPV6]
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT
Stokes, et al Expires 2 September 2001 [Page 9]
Internet-Draft Access Control Model 2 March 2001
IPv6prefix = hexpart "/" 1*2DIGIT
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
printableString ; printableString syntax from [ATTR]
Note that the colon following the "public" and "this"
subject options exist only to simplify string parsing.
Note also that per [AuthMeth], authzID may be expanded in
the future.
See section titled 'ACI Examples' for examples of the string
representation.
4.1.2 ACI Binary Representation
The following ASN.1 data type is used to represent this
syntax when transferred in binary form:
EntryACI ::= SEQUENCE {
rights SEQUENCE OF CHOICE {
grant [0] Permissions,
deny [1] Permissions },
attr CHOICE {
all [0] NULL,
entry [1] NULL,
attributes [2] SEQUENCE OF Attribute },
subject SEQUENCE {
authnLevel CHOICE {
any [0] NULL,
simple [1] NULL,
sasl [2] CHOICE {
any [0] NULL,
mechanism [1] LDAPString -- from [LDAPv3]
}
none [3] NULL,
anonymous [4] NULL
},
subjectName CHOICE {
dn [0] DN,
user [1] UTF8String
role [1] DN,
group [2] DN,
subtree [3] DN,
Stokes, et al Expires 2 September 2001 [Page 10]
Internet-Draft Access Control Model 2 March 2001
ipAddress [4] IPAddress,
public [6] NULL,
this [7] NULL }, } -- may be expanded
per [AuthMeth]
SubtreeACI ::= SEQUENCE {
rights SEQUENCE OF CHOICE {
grant [0] Permissions,
deny [1] Permissions },
attr CHOICE {
all [0] NULL,
entry [1] NULL,
attributes [2] SEQUENCE OF Attribute },
subject SEQUENCE {
authnLevel CHOICE {
any [0] NULL,
simple [1] NULL,
sasl [2] CHOICE {
any [0] NULL,
mechanism [1] LDAPString -- from [LDAPv3]
}
none [3] NULL,
anonymous [4] NULL
},
subjectName CHOICE {
dn [0] DN,
user [1] UTF8String
role [1] DN,
group [2] DN,
subtree [3] DN,
ipAddress [4] IPAddress,
public [6] NULL,
this [7] NULL }, } -- may be expanded
per [AuthMeth]
Permissions ::= SEQUENCE OF ENUMERATED {
add (0),
delete (1),
export (2),
import (3),
renameDN (4),
browseDN (5),
returnDN (6),
read (7),
search (8),
write (9),
obliterate (10),
compare (11),
make (12) }
Stokes, et al Expires 2 September 2001 [Page 11]
Internet-Draft Access Control Model 2 March 2001
; permissions read, write, obliterate, ssearch, ccompare,
; make work on attributes
; permissions add, delete, export, import, renameDN,
; browseDN, returnDN work on entries
Attribute ::= AttributeType -- from [LDAPv3]
IPAddress ::= PrintableString -- (e.g. 10.0.0.6) ***FIX
to match the BNF***
4.2 The Components of entryACI and subtreeACI Attributes
This section defines components that comprise the access
control information attributes, entryACI and subtreeACI.
The access control information in the entryACI attribute
applies only to the entry in which it is contained.
The access control information in the subtreeACI attribute
applies to each entry down the subtree unless it is
overridden by an entry-specific entryACI whose values are
more specific.
Use of prescriptive ACIs and scoping via use of a
ldapACISubEntry is outside the scope of this document.
4.2.1 Access Rights and Permissions
Access rights can apply to an entire object or to attributes
of the object. Access can be granted or denied. Either or
both of the actions "grant" | "deny" may be used when
creating or updating entryACI and subtreeACI.
Each of the LDAP access permissions are discrete. One
permission does not imply another permission. The
permissions which apply to attributes and the entry parallel
the type of ldap operations that can be performed.
Permissions which apply to attributes:
r Read Read attribute values
w Write Modify-add values
o Obliterate Modify-delete values
s Search Search entries with specified attributes
c Compare Compare attributes
m Make Make attributes on a new entry below
this entry
Stokes, et al Expires 2 September 2001 [Page 12]
Internet-Draft Access Control Model 2 March 2001
1. r Read
If granted, permits attributes and values to be
returned in a read or search operation.
2. w Write
If granted, permits attributes and values to be added
in a modify-add operation.
3. o Obliterate
If granted, permits attributes and values to be
deleted in a modify-delete operation.
4. s Search
If granted, permits attributes and values to be
included in the search filter of a search operation.
5. c Compare
If granted, permites attributes and value to be used
in a compare operation.
6. m Make
The attribute permission "m" is required for all
attributes that are placed on an object when it is
created. Just as the "w" and "o" permissions are used
in the Modify operation, the "m" permission is used in
the Add operation. Additionally, note that "w" and "o"
have no bearing on the Add operation and "m" has no
bearing on the Modify operation. Since a new object
does not yet exist, the "a" and "m" permissions needed
to create it must be granted on the new object's
parent. This differs from "w" and "o" which must be
granted on the object being modified. The "m"
permission is distinct and separate from the "w" and
"o" permissions so that there is no conflict between
the permissions needed to add new children to an entry
and the permissions needed to modify existing children
of the same entry.
Note: Modify-replace values of an attribute requires "w"
and "o" permission.
Permissions that apply to an entire entry:
a Add Add an entry below this entry
Stokes, et al Expires 2 September 2001 [Page 13]
Internet-Draft Access Control Model 2 March 2001
d Delete Delete this entry
e Export Export entry & subordinates to new
location
i Import Import entry & subordinates from some
location
n RenameDN Rename an entry's DN
b BrowseDN Browse an entry's DN
t ReturnDN Allows DN of entry to be disclosed in
an operation result
1. a Add
If granted, permits creation of an entry in the DIT
subject to access control on all attributes and values
to be placed in the new entry at time of creation. In
order to add an entry, permission must also be granted
to add all attributes that exist in the add operation.
2. d Delete
If granted, permits the entry to be removed from the
DIT regardless of controls on attributes within the
entry. Delete only works on leaf entries (same as
X.500).
3. e Export
If granted, permits an entry and its subordinates (if
any) to be exported; that is, removed from the current
location and placed in a new location subject to the
granting of suitable permission at the destination.
If the last RDN is changed, Rename is also required at
the current location. In order to export an entry or
its subordinates, there are no prerequisite
permissions to contained attributes, including the RDN
attributes; this is true even when the operation
causes new attribute values to be added or removed as
the result of the changes of RDN.
4. i Import
If granted, permits an entry and its subordinates (if
any) to be imported; that is, removed from some other
location and placed below the location to which the
permission applies subject to the granting of suitable
permissions below the source location. In order to
import an entry or its subordinates, there are no
prerequisite permissions to contained attributes,
including the RDN attributes; this is true even when
the operation causes new attribute values to be added
Stokes, et al Expires 2 September 2001 [Page 14]
Internet-Draft Access Control Model 2 March 2001
or removed as the result of the changes of RDN.
5. n RenameDN
Granting Rename is necessary for an entry to be
renamed with a new RDN. There are many cases here
surrounding the use of this permission. See the
section on 'Modify DN Operation'.
6. b BrowseDN
If granted, permits entries to be accessed using
directory operations which do not explicitly provide
the name of the entry.
7. t ReturnDN
If granted, allows the distinguished name of the entry
to be disclosed in the operation result.
All permissions (for grant and deny) for an attribute/entry
and a given subject MUST be contained within one entryACI
value, i.e. (in abbreviated form); likewise for subtreeACI.
entryACI: ...grant OID.attr1 subjectA
entryACI: ...deny OID.attr1 subjectA
is illegal; instead it must be
entryACI: ...grant ... deny... OID.attr1 subjectA
Using the defined BNF it is possible for the permission
string to be empty. The ACI
subtreeACI: grant#OID.attr1#group:cn=Dept XYZ,c=US
subtreeACI: grant:r,s#[all]#group:cn=Dept XYZ,c=US
means that this group (Dept XYZ) is granted permission to
read and search all attributes except OID.attr1 because
OID.attr1 is more specific than "[all]".
4.2.2 Attributes
Attribute describes an attribute name in the form of a
dotted decimal OID for that <attr>. If the string (OID)
refers to an attribute not defined in the given server's
schema, the server SHOULD report an error. The use of
"[entry]" or "[all]" helps to focus the permissions to
either entry or attribute quickly, and hence helps in
parsing.
Stokes, et al Expires 2 September 2001 [Page 15]
Internet-Draft Access Control Model 2 March 2001
"[entry]" means the permissions apply to the entire object.
This could mean actions such as delete the object, or add a
child object. When used in subtreeACI, the specified
permissions (on the entry set of permissions are legal here
- see the BNF) apply to each entry in the subtree.
"[all]" means the permission set applies to all attributes
of the entry. When used in subtreeACI, "[all]" applies to
all attributes of each entry in the subtree.
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]".
4.2.3 Subjects and Associated Authentication
The following subjects are defined and MUST be supported:
- authzID, defined per [authmeth]
- group, defined as the distinguished name of a
groupOfNames or groupOfUniqueNames entry
- role, asserts a subject's organizational position and
entitlement to perform the operations appropriate to
that organizational position
- subtree, defined as some distinguished name of a non-
leaf node in the DIT
- ipAddress, in IPv6 text format [IPV6]
- public, defined as public access
- this, defined as the user whose name matches that of
the entry being accessed
Other parties MAY define other subjects. It is the
responsibility of those parties to provide the definition.
A subject may be qualified by the type of authentication
required for access to a given attribute(s) or entry. If no
authnLevel is present, then no specific type of
authentication is additionally required for access. If
authnLevel is specified, then that type of authentication is
additionally required for access. The authnLevels parallel
the authentication mechanisms specified for LDAPv3: simple,
SASL (any type of SASL mechanism), and a SASL-specific
mechanism. The authnLevel 'anonymous' is equivalent to
Stokes, et al Expires 2 September 2001 [Page 16]
Internet-Draft Access Control Model 2 March 2001
LDAPv3 simple authentication with no password. The
authnLevel of 'any' means that the accessor must be
authenticated by some mechanism (no authentication is not an
acceptable mechanism for this case) as part of obtaining
access.
For permission to be granted, the subject must have been
authenticated to at least the level specified, but that if
the right is a deny, then everyone is denied access unless
they have been authenticaated to at least the level
specified in authnLevel.
4.3 Grant/Deny Evaluation Rules
The decision whether to grant or deny a client access to a
particular piece of information is based on several pieces
of information found within the ldapaci values. Throughout
the decision making process, there are guiding principals.
- Specificity: 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 or when evaluation of the access control
information yields no result that allows requester
access.
Precendence of Scope Types (highest to lowest)
- entry (entryACI)
- subtree (subtreeACI)
Precedence of Subjects within a Scope (highest to lowest):
- ipAddress
- authzID
- this
- role
Stokes, et al Expires 2 September 2001 [Page 17]
Internet-Draft Access Control Model 2 March 2001
- group
- subtree
- public
Although other types MAY be defined given the BNF, use of
the well-known types aids in interoperability and
operational consistency.
Access Decision algorithm:
1. Determine all the entryACI and subtreeACI values which
could apply to the target DN which is being accessed.
This is the DN of the entry which is being queried in
a search, modified, deleted, etc. entryACI values
take precedence over subtreeACI values.
2. Determine which entryACI and subtreeACI values (of the
set determined in step 1) apply to the bound DN. This
is determined by looking at the subject (combination
of subject type and subject value) and bind type. If
no bind is in effect, then treat this lack of bind as
if bound as anonymous. Start with the most specific
subject type. If at any time, at least one entryACI
or subtreeACI value exists for a specificity level,
then processing stops. Evaluation should take place
on set of entryACI or subtreeACI values which are all
of the same specificity level. Subjects of the same
precedence are combined using union semantics.
3. Evaluate the remaining entryACI and subtreeACI values
and determine a grant/deny decision. If conflicting
values exists for the same attribute(s) (i.e. one
grants permission and another denies permission), then
deny takes precedence over grant. For example, if one
is granted permission to "objectclass" in one value by
being a member of group cn=Admin, and denied
permission by being a member of cn = NontrustedAdmins,
then the bound user would not receive permission to
objectclass.
The rule of specificity also applies to the
attributes. If one is denied permission to "[ all ]"
attributes, but granted permission to "objectclass"
then the more specific value of "objectclass" takes
precedence over the less specific value of "[ all ] ".
In this case the user would be granted permission to
"objectclass" but denied permission to all other
attributes.
Stokes, et al Expires 2 September 2001 [Page 18]
Internet-Draft Access Control Model 2 March 2001
5. Required Permissions for each LDAP Operation
This section defines the required permissions for each LDAP
operation. Even if these requirements are satisfied, the
server MAY refuse to carry out the operation due to other
implementation specific security considerations. For
example, a server may refuse to modify an entry because the
database where that entry resides is in read only mode.
Another example might be that although the access control is
available to the userPassword attribute a server may refuse
modifications due to some server specific policy governing
access to passwords.
Here, we specify the rights required by a user when
performing an LDAP operation in terms of the LDAP
permissions specified in section 6.1. Recall that "a, d,
e, i, n, b, t" are permissions that apply to entries as a
whole while permissions "r, s, w, o, c, m" apply to
attributes within entries.
Required permissions for LDAP extended operations and LDAP
controls are beyond the scope of this draft.
For the following, assume that the authorization identity of
the user doing the operation is authzID.
5.1 Bind Operation
This draft does not require any permissions to allow a bind
operation to proceed.
5.2 Search Operation
Recall that the parameters of the Search operation per RFC
2251 [LDAPv3] Section 4.5 are:
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
Stokes, et al Expires 2 September 2001 [Page 19]
Internet-Draft Access Control Model 2 March 2001
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }
Suppose a server is processing a search request from user
authzID with parameters as above and is processing the entry
with dn candidateDN to decide if it may be returned or not.
Then the permissions required by authzID that need to be
evaluated are as follows:
1. permission "b" to the entry candidateDN
If this permission is not granted then the dn
candidateDN MUST not be returned nor any attribute
type nor attribute value from this entry.
If this permission is granted then the dn candidateDN
MAY be returned.
Note: The idea of the "b" permission is to say "a user
has discovery rights" at a certain entry in the
directory. Assuming that the further required
permissions below are satisfied then having "b" right
is enough to allow the server to return candidateDN.
Of course candidateDN contains in its components,
attributes and attribute values for all the ancestors
of candidateDN. This can lead to the slightly odd
situation that we can discover the naming attribute of
an entry and that attribute's value by virtue of
having the required searching permissions to its child
but not by searching the entry directly.
2. permission "s" to each attribute appearing in a search
filter presence test during the evaluation of the
search filter. permission "r" and "s" to each
attribute appearing in non-presence tests (see
rfc1960, section 3: equalityMatch, substrings,
greaterOrEquial, lessOrEqual, present, approxMatch,
extensibleMatch) during the evaluation of the search
filter.
The above statement covers the case where the
attributes are being evaluated as part of an
extensibleMatch (RFC 2251 section 4.5.1) which appears
in the filter. In the case where the dnAttributes
field of the extensibleMatch is true then we do not
require any access checks to the attributes of the dn
candidateDN as access to these is taken to be granted
by the "b" permission, which has already been required
Stokes, et al Expires 2 September 2001 [Page 20]
Internet-Draft Access Control Model 2 March 2001
above.
If there is an attribute in a filter element to which
the required permission is not granted then that
filter element evaluates to "Undefined" of the three-
valued-logic of X.511(93).
Note A: Although both "r" and "s" permissions will
typically be granted to attributes we keep both
permissions as there are cases where the distinction
is useful. For example, the ability to grant the
right to discover that a user entry contains a
userPassword attribute, but not to read its value ("s"
but not "r"). A reverse telephone lookup is an
example of the converse, that is, granting "r" but not
"s" permission.
Note B: There is an unusual behaviour with respect to
naming attributes illustrated in the following
example:
Suppose I have "b" rights to cn=fred,o=sun.com and "r"
rights to attribute objectclass but not "r" rights to
cn then with search filter (objectclass=*) I get back
the dn and objectclass (and so can see the value of
cn), but with a search filter of (cn=fred) I do not
get anything.
3. permission "r" to each attribute in the attribute list
AttributeDescriptionList (or all attributes in the
entry candidateDN if AttributeDescriptionList is *)
whose type and/or value will be returned.
Note: The presence of an attribute in an entry is only
ever volunteered by the server if "r" permission is
granted to it, though a user may infer the presence of
an attribute with "s" permission by using a presence
test on that attribute in the search filter.
4. permission "t" to the entry candidateDN
If this permission is not granted then the dn
candidateDN MUST NOT be returned. If the server knows
of an alias for the entry, this alias may be returned
instead. If no alias name is available then the entry
candidateDN MUST be omitted from the search results.
5. Disclose on error for the Search operation
Stokes, et al Expires 2 September 2001 [Page 21]
Internet-Draft Access Control Model 2 March 2001
If every entry in the scope of the search fails to
satisfy item 1 (browse right on the candidate entry)
or item 2 (right to use the filter on that entry) and
if discloseOnError is not granted to the entry then
the operation MUST fail with a "no such object error"
and the matchedDN of the LDAPResult MUST be set to "".
If every entry in the scope of the search fails to
satisfy items 1 or 2 above and discloseOnError is
granted to the baseObject then the empty set of
results is returned.
5.3 Modify Operation
Recall that the parameters of the Modify operation per
RFC2251 [LDAPv3] Section 4.6 are:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Then the permissions required by authzID that need to be
evaluated are as follows:
1. permission "w" to each attribute being added to object
If this permission is not granted to such an
attribute, then the operation MUST fail. In this
case, if discloseOnError is not granted to the entry
then "no such object" error is returned; if
discloseOnError is granted to the entry and a
duplicate attribute value is being added then
"attribute value already exists" error is returned; if
discloseOnError is granted to the entry and no
duplicate value is being added then an "insufficient
access" error is returned.
2. permission "o" to each attribute for which a value is
being deleted from object
Stokes, et al Expires 2 September 2001 [Page 22]
Internet-Draft Access Control Model 2 March 2001
If this permission is not granted to such an attribute
then the operation MUST fail. In this case, if
discloseOnError is not granted to the entry then "no
such object" error is returned; if discloseOnError is
granted to the entry and the attribute or one of the
values to be deleted does not exist then a "no such
attribute or value" error is returned; if
discloseOnError is granted to the entry and the
attribute and all values specified to be deleted exist
then an "insufficient access" error is returned.
3. permissions "o" and "w" to each attribute being
replaced in object
If one of these these permissions is not granted to
such an attribute then the operation MUST fail. In
this case, if discloseOnError is not granted to the
entry then a "no such object" error is returned; if
discloseOnError is granted to the entry then
"insufficient access" error is returned.
5.4 Add Operation
Recall that the parameters of the Add operation per RFC2251
[LDAPv3] Section 4.7 are:
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Then the permissions required by authzID that need to be
evaluated are as follows:
1. permission "a" to the parent of entry
The access rights required for the creation of a root
entry in the Directory are beyond the scope of this
document. They will be vendor specific.
2. permission "m" to the parent of entry for each
attribute being added to entry
If any of these permissions are not granted then the
operation MUST fail. In this case if discloseOnError is on
Stokes, et al Expires 2 September 2001 [Page 23]
Internet-Draft Access Control Model 2 March 2001
and the entry to be added does not already exist then
"insufficient access" is returned. If the entry does exist
then "Entry already exists" is returned. If discloseOnError
is off then "No such object" is returned and matchedDN="".
If they are all granted then the operation MAY proceed.
Note: We require "m" permission to each attribute to prevent
an entry from aquiring "unintended" rights (via group or
role membership), to stop a "rogue" ACI being added that
would prevent even admins deleting the entry and general
consistency with the MODIFY operation.
Note: The access rights required for the creation of the
first entry in the directory are beyond the scope of this
document.
5.5 Delete Operation
Recall that the parameters of the Delete operation per
RFC2251 [LDAPv3] Section 4.10 are:
DelRequest ::= [APPLICATION 10] LDAPDN
Then the permissions required by authzID that need to be
evaluated are as follows:
1. permission "d" to the entry in the Delete request
If this permission is not granted, then the operation MUST
fail. In this case if discloseOnError is on and the entry
to be deleted exists then "insufficient access" is returned.
If the entry does not exist then "No such Object" is
returned. If discloseOnError is off then "No such object"
is returned and matchedDN="".
If this permission is granted, then the operation MAY
proceed.
Note: One could also require the "o" permission to be
granted to allow the operation to proceed, but customer
experience has shown that the requirement of the additional
permission is not useful nor expected, and X.500 requires
only the "d" permission.
5.6 Modify DN Operation
Recall that the parameters of the Modify DN operation per
Stokes, et al Expires 2 September 2001 [Page 24]
Internet-Draft Access Control Model 2 March 2001
RFC2251 [LDAPv3] Section 4.6 are:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
The variants of the ModifyDN operation are listed below.
Combinations of the write, obliterate, import, export and
renameDN permissions are needed for each variant.
1. Rename an entry by moving the conceptual RDN flag
between two existing attribute values, without
altering any attribute values at all. Permissions
needed are renameDN.
2. Rename an entry by adding a new attribute value.
Permissions needed are renameDN and write.
3. Rename an entry using an existing attribute value and
delete the current attribute value. Permissions
needed are renameDN and obliterate.
4. Rename an entry adding a new attribute value and
deleting the current attribute value. Permissions
needed are renameDN, write, and obliterate.
5. Move an entry to a new place in the DIT, keeping its
existing RDN as is. Permissions needed are import and
export.
6. Move an entry to a new place coupled with 1. above
Permissions needed are import, export, and renameDN.
7. Move coupled with 2. above. Permissions needed are
import, export, renameDN, and write.
8. Move coupled with 3. above. Permissions needed are
import, export, renameDN, and obliterate.
9. Move coupled with 4. above. Permissions needed are
import, export, renameDN, write, and obliterate.
5.7 Compare Operation
Recall that the parameters of the Compare operation per
RFC2251 [LDAPv3] Section 4.10 are:
CompareRequest ::= [APPLICATION 14] SEQUENCE {
Stokes, et al Expires 2 September 2001 [Page 25]
Internet-Draft Access Control Model 2 March 2001
entry LDAPDN,
ava AttributeValueAssertion }
Then the permissions required by authzID that need to be
evaluated are as follows:
1. permission "c" to the attribute in entry on which the
comparison is being made.
If any of these permissions are not granted then the
operation MUST fail. In this case, if discloseOnError is on
then an "insufficient access error" is returned. Otherwise,
"No such object" is returned.
If they are all granted then the operation MAY proceed.
5.8 Abandon Operation
Recall that the parameters of the Abandon operation per
RFC2251 [LDAPv3] Section 4.6 are:
AbandonRequest ::= [APPLICATION 16] MessageID
authzID always has the right to send an Abandon Operation
for an operation he previously initiated.
5.9 Extended Operation
Recall that the parameters of the Extended operation per
RFC2251 [LDA{v3] Section 4.12 are:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
The access required for an Extended Operation is beyond the
scope of this document. The required access will normally
be defined by the implementor of the extended request.
6. Required Permissions for Handling Aliases and References
Use of aliases and referrals are part of LDAPv3. However,
neither is particularly well-defined. Alias objects and
attributes are defined in RFC 2256 as derived from X.500,
but LDAPv3 does not explicitly define their semantics or
Stokes, et al Expires 2 September 2001 [Page 26]
Internet-Draft Access Control Model 2 March 2001
behavior. X.500 does define alias semantics and behavior
with respect to access control; we define its behavior in
LDAPv3 based on the X.511 (1993), section 7.11.1. Referrals
and knowledge information are still under design in LDAPv3;
they are defined in X.500, however, X.500 does not specify
their semantics and behavior with respect to access control.
We define their semantics and behavior in LDAPv3 in terms
that should be independent of the future LDAPv3 definition
of referrals and knowledge information.
6.1 ACI Distribution
Currently there is no LDAP standard defining how to
distribute directory data between LDAP servers. Consequently
this draft cannot fully specify the behavior of the Access
Control Model in a distributed environment. The case of
distribution via referrals is treated in the "Referrals"
section below. In the case of chaining (where one LDAP
server forwards a request to another on behalf of a client)
then it is server specific how the access control model
behaves in this environment. Similarly it is server specific
how the server determines whether the chaining of an
operation is permitted in the first place. For example, the
implementation may choose to regard the local naming context
and the remote subordinate naming context as seperate Access
Control Specific Areas, or it may regard the DIT as one
Access Control Specific Area and implement mechanisms to
propagate access control information between the two
servers. The behavior of the Access Control Model in
distributed environments such as these is beyond the scope
of this draft.
6.2 Aliases
There are two things to protect with respect to aliases:
the real name of the aliased object and the location of the
server holding it.
If alias de-referencing is required in the process of
locating a target entry, no specifc permissions are
necessary for alias de-referencing to take place. Access
control is enforced at the object pointed to by the alias.
If alias de-referencing would result in a
continuationReference (e.g. from a search operation), then
browse permission is required to the alias entry and read
permission is required to the 'aliasedObjectName' attribute.
Requiring these permission closes the hole of discovery.
Stokes, et al Expires 2 September 2001 [Page 27]
Internet-Draft Access Control Model 2 March 2001
6.3 Referrals
If a referral is to be followed, no specifc permissions are
necessary for the ldap client to follow the referral. Access
control is enforced at the referenced object. If a referral
is returned, then browse is required on the entry and read
permission is required to the attribute containing the
referral (we cannot name this attribute exactly today
because there are no RFCs on this - only drafts). If the
server implements a default referral, then no special
permissions are required to read and return that referral.
Requiring these permissions closes the hole of discovery.
In the default case, it is assumed that a default referral
is public.
7. Controlling Access to Access Control Information
The entryACI and subtreeACI attributes are used to specify
control for who has permission to set/change access control
information (entryACI and subtreeACI). The entryACI and
subtreeACI attributes/OIDs are just another attribute
described with set of rights and permissions, and subject as
a value of the entryACI and subtreeACI attributes. (See the
example in the "ACI Examples" section).
If the policy for controlling the entryACI and subtreeACI
attributes are not specified for any object in the tree,
behavior is implementation defined. For instance, if no
object anywhere in the tree defines the access for
entryACI/subtreeACI within the entryACI/subtreeACI
attributes, then the server could simply assert that the
'root DN' is considered the policy owner (controller for
controlling access control) for all objects.
8. ACI Examples
Note that in the examples, the form "OID.<attrname>" refers
to the OID in dotted decimal form for the attribute
<attrname>. This shorthand notation is used only for the
examples. In implementation, the dotted decimal form of the
OID is used.
8.1 Attribute Definition
The following examples show the access required to control
access to the entryACI and subtreeACI attributes. The first
Stokes, et al Expires 2 September 2001 [Page 28]
Internet-Draft Access Control Model 2 March 2001
example shows controlling the access control on an
individual entry and its attributes. The second example
shows controlling the access control on a subtree.
entryACI: grant:r,w,o#
OID.entryACI#authnLevel:any:role:cn=aciAdmin
subtreeACI: grant:r,w,o#
OID.subtreeACI#authnLevel:any:role:cn=aciAdmin
The next example shows a subtreeACI 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.
Authentication of a specified type is not required.
subtreeACI: grant;r,s,c#
OID.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
browseDN and returnDN for objects below this node. The role
is also being given permission to read, search, and compare
to attribute attr2 and read, search, compare, write,
obliterate to attr3. The permissions apply to the entire
subtree below the node containing this ACI.
subtreeACI: grant:b,t#
[entry]#role:cn=SysAdmins,o=Company
subtreeACI: grant:r,s,c#
OID.attr2#role:cn=SysAdmins,o=Company
subtreeACI: grant:r,s,c,w,o#
OID.attr3#role:cn=SysAdmins,o=Company
8.2 Modifying the entryACI and subtreeACI Values
Modify-Replace works as defined in the ldap operation
modify. If the attribute value does not exist, create the
value. If the attribute does exist, replace the value. If
the entryACI/subtreeACI value is replaced, all
entryACI/subtreeACI values are replaced. To modify the
entryACI/subtreeACI attributes requires you to have 'w' and
'o' permission on the entryACI/subtreeACI attribute (recall
that a value of entryACI/subtreeACI specifies
entryACI/subtreeACI so one can control access to the
entryACI/subtreeACI attribute). The examples in this
section assume that you have access to control
entryACI/subtreeACI.
Stokes, et al Expires 2 September 2001 [Page 29]
Internet-Draft Access Control Model 2 March 2001
A given subtreeACI for an entry:
subtreeACI: deny:r,w#[all]#group:cn=Dept ABC
subtreeACI: grant:r#OID.attr1#group:cn=Dept XYZ
perform the following change:
dn: cn=someEntry
changetype: modify
replace: subtreeACI
subtreeACI: grant:r,w#[all]#group:cn=Dept LMN
The resulting ACI is:
subtreeACI: grant:r,w#[all]#group:cn=Dept LMN
( subtreeACI 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 entryACI/subtreeACI
value(s). If the ACI does exist, then add the specified
values to the given entryACI/subtreeACI. For example a
given ACI:
subtreeACI: grant:r,w#[all]#group:cn=Dept XYZ
with a modification:
dn: cn=someEntry
changetype: modify
add: subtreeACI
subtreeACI: grant:r#OID.attr1#group:cn=Dept XYZ
would yield an multi-valued ACI of:
subtreeACI: grant:r,w#[all]#group:cn=Dept XYZ
subtreeACI: grant:r#OID.attr1#group:cn=Dept XYZ
To delete a particular ACI value, use the regular ldapmodify
- delete syntax
Given an ACI of:
subtreeACI: grant:r,w#[all]#group:cn=Dept XYZ
subtreeACI: grant:r#OID.attr1#group:cn=Dept XYZ
dn: cn = some Entry
changetype: modify
Stokes, et al Expires 2 September 2001 [Page 30]
Internet-Draft Access Control Model 2 March 2001
delete: subtreeACI
subtreeACI: grant:r#OID.attr1#group:cn=Dept XYZ
would yield a remaining ACI on the server of
subtreeACI: grant:r,w#[all]#group:cn=Dept XYZ
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: entryACI
dn: cn = some Entry
changetype: modify
delete: subtreeACI
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 entryACI and subtreeACI are
deleted, then the access control information for that entry
is defined by that implementation's inheritance model.
8.3 Evaluation
These examples assume that the ACI 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 10 for a discussion of the semantics of ldapACI
entries when backing-store ACI administration is also used.
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
subtreeACI: grant:r#OID.attr1
#authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
subtreeACI: grant:w#OID.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; authzID is higher precedence than
Stokes, et al Expires 2 September 2001 [Page 31]
Internet-Draft Access Control Model 2 March 2001
group.
Example #2
dn: o=XYZ, c=US
subtreeACI: grant:r#OID.attr2
#group:cn=G1,ou=ABC,o=XYZ,c=US
subtreeACI: grant:w#OID.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
subjects (group) have same precedence.
Example #3
dn: o=XYZ, c=US
subtreeACI: grant:r,w#OID.attr3
#group:cn=G1,ou=ABC,o=XYZ,c=US
subtreeACI: deny:w#OID.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
subtreeACI: grant:w#OID.attr4
#authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
subtreeACI: grant:r#OID.attr4#subtree:ou=ABC,ou=XYZ,c=US
What rights does cn=jsmith have to attr4 of o=XYZ, c=US?
Write (w); rights given to an authzID take precedence
over those given to a subtree.
Example #5
dn: o=XYZ, c=US
subtreeACI: grant:m#OID.attr5
#authzID-dn:cn=jsmith,o=ABC,c=US
subtreeACI: grant:m#OID.cn
#authzID-dn:cn=jsmith,o=ABC,c=US
subtreeACI: grant:m#OID.sn
#authzID-dn:cn=jsmith,o=ABC,c=US
subtreeACI: grant:a#[entry]
#authzID-dn:#cn=jsmith,o=ABC,c=US
What rights does cn=jsmith have to o=XYZ, c=US?
Make(m) on attributes attr5, cn, and sn and Add(a)
on the entry. These are the minimal yet sufficient
Stokes, et al Expires 2 September 2001 [Page 32]
Internet-Draft Access Control Model 2 March 2001
permissions to create a new object,
cn=New, o=XYZ, c=US with values for the attr5, cn,
and sn attributes. This example illustrates how the
"m" permission can be used to limit the attributes
that can be created on a new entry.
Example #6
dn: c=US
subtreeACI: grant:m#[all]#subtree:c=US
dn: o=XYZ, c=US
subtreeACI: grant:a#[entry]#
authzID-dn:cn=jsmith,o=ABC,c=US
What rights does cn=jsmith have to o=XYZ, c=US?
Make(m) on attributes all attributes and Add(a) on the
entry. These are sufficient permissions to create a new
object, cn=New, o=XYZ, c=US with values any desired
attributes. For administrators who do not wish to limit
the attributes that can be created on new entries, this
example shows how a single ldapACI at the top of the
domain solves the problem.
8.4 ModDN
There are many different actions that can happen when the
modDN command are used. The following illustrates the
permissions needed in order to execute each scenario. For
all examples, we will assume the role cn=Admins is working
with the following entry:
dn: cn=personA, o=Company
cn: personA
cn: First Name
sn: LastName
objectclass: person
Example 1. Perform a modRDN only, using an existing
attribute value. In this case, we perform a modRDN and
rename cn=personA, o=Company to cn=FirstName, o=Company. The
entrypACI value for this entry must give the cn=Admin role
rename permission on the entry.
entryACI: grant:N#[entry]#role:cn=Admin
Example 2. We wanted to perform a ModRDN and add a new
atttribute value. In this case we are renaming cn=personA,
o=Company to cn=newFirstName, o=Company. The entryACI value
must give the cn=Admin role rename permission on the entry
and w permission on the cn attribute.
Stokes, et al Expires 2 September 2001 [Page 33]
Internet-Draft Access Control Model 2 March 2001
entryACI: grant:N#[entry]#role:cn=Admin
entryACI: grant:w#OID.cn#role:cn=Admin
Example 3. Perform a modRdn, using an existing attribute,
but delete the old RDN value. Here, we perform a modRdn and
rename cn=personA, o=Company to cn=FirstName, o=Company and
set the deleteOldRdn flag to true. The cn=Admin role must
have permission to rename the entry, and to delete a cn
attribute value ( i.e. 'o' ).
entryACI: grant:n#[entry]#role:cn=Admin
entryACI: grant:o#OID.cn#role:cn=Admin
Example 4. Perform a modRdn, using an new cn attribute value
(cn=newFirstName), and delete the old RDN value
(cn=personA). Here, we perform a modRdn and rename
cn=personA, o=Compnay to cn=newFirstName, o=Company and set
the deleteOldRdn flag to true. The cn=Admin role must have
permission to rename the entry, and to delete and write the
cn attribute value.
entryACI: grant:n#[entry]#role:cn=Admin
entryACI: grant:wo#OID.cn#role:cn=Admin
Example 5. We want to change the entry's location in the DIT
( modDN ) and keep the same RDN Value. In this case we are
moving cn=personA, o=Company to cn=personA, o=CompanyB. The
cn=Admin role must have export permission on the original
entry, and import permission on the new superior object (
the new parent ). The cn=personA, o=Company entryACI is:
entryACI: grant:e#[entry]#role:cn=Admin
and the o=CompanyB entryACI is:
entryACI: grant:i#[entry]#role:cn=Admin
Example 6. We want to change the entry's location in the DIT
( modDN ) and change the RDN Value to an existing attribute
value. In this case we are moving cn=personA, o=Company to
cn=firstName, o=CompanyB. The cn=Admin role must have rename
and export permission on the original entry, and import
permission on the new superior object ( the new parent ).
The cn=personA, o=Company entryACI is:
entryACI: grant:e,n#[entry]#role:cn=Admin
and the o=CompanyB entryACI is:
entryACI: grant:i#[entry]#role:cn=Admin
Stokes, et al Expires 2 September 2001 [Page 34]
Internet-Draft Access Control Model 2 March 2001
Example 7. We want to change the entry's location in the DIT
( modDN ) and change the RDN Value to a new attribute value.
In this case we are moving cn=personA, o=Company to
cn=newfirstName, o=CompanyB. The cn=Admin role must have
rename and export permission on the original entry, write
permission on the naming attribute ( cn) and import
permission on the new superior object ( the new parent ).
The cn=personA, o=Company entryACI is:
entryACI: grant:e,n#[entry]#role:cn=Admin
entryACI: grant:w#OID.cn#role:cn=Admin
and the o=CompanyB entryACI is:
entryACI: grant:i#[entry]#role:cn=Admin
Example 8. We want to change the entry's location in the DIT
( modDN ) and change the RDN Value to an existing attribute
value, and delete the old RDN value. In this case we are
moving cn=personA, o=Company to cn=firstName, o=CompanyB and
deleteing the attribute value personaA. The cn=Admin role
must have rename and export permission on the original
entry, delete ('o') permission on the naming attribute (cn)
and import permission on the new superior object ( the new
parent ). The cn=personA, o=Company entryACI is:
entryACI: grant:e,n#[entry]#role:cn=Admin
entryACI: grant:o#OID.cn#role:cn=Admin
and the o=CompanyB entryACI is:
entryACI: grant:i#[entry]#role:cn=Admin
Example 9. We want to change the entry's location in the DIT
( modDN ) and change the RDN Value to a new attribute value,
and delete the old RDN value. In this case we are moving
cn=personA, o=Company to cn=newfirstName, o=CompanyB and
deleteing the attribute value personaA. The cn=Admin role
must have rename and export permission on the original
entry, write ('w'), and delete ('o') permission on the
naming attribute (cn) and import permission on the new
superior object ( the new parent ). The cn=personA,
o=Company entryACI is:
entryACI: grant:e,n#[entry]#role:cn=Admin
entryACI: grant:w,o#OID.cn#role:cn=Admin
and the o=CompanyB entryACI is:
entryACI: grant:i#[entry]#role:cn=Admin
Stokes, et al Expires 2 September 2001 [Page 35]
Internet-Draft Access Control Model 2 March 2001
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 retrieved while
manipulating other directory information for that entry.
The control is:
GetEffectiveRights - obtain the effective rights for a
given directory entry(s) for a given subject during a
ldap_search operation
The following parameters are used in the access control LDAP
control.
- targetDN - specifies the initial directory entry in DN
syntax on which the controlis 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).
- rights - in the get effective rights control response
is of the form specified in the BNF for <rights>.
- subject - specifies a LDAP string that defines the
subject. Access control is get/set on a subject. The
syntax of the subject is the same as the subject field
in the BNF.
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 {
Stokes, et al Expires 2 September 2001 [Page 36]
Internet-Draft Access Control Model 2 March 2001
whichObject ENUMERATED {
ldap-entry (1),
ldap-subtree (2)
},
subject <see <subject > in BNF> | "*" ;*expand it*
}
}
The effectiveRightsRequest is a set of sequences that state
the whichObject (entry or entry plus subtree) and specifics
of the control request to be performed. A "*" in the subject
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 {
rights <see <rights> in BNF>,
whichObject ENUMERATED {
LDAP_ENTRY (1),
Stokes, et al Expires 2 September 2001 [Page 37]
Internet-Draft Access Control Model 2 March 2001
LDAP_SUBTREE (2)
},
subject < see <subject> in BNF > ;*expand it*
}
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 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 it 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 it and the client
specified FALSE for the control's criticality field,
then the server should process as 'no rights returned'
Stokes, et al Expires 2 September 2001 [Page 38]
Internet-Draft Access Control Model 2 March 2001
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 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.
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. 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.
Interaction of access control with other directory functions
(other than the ones defined in this document) are not
defined in this document, but instead in the documents where
those directory functions are defined. For example, the
directory replication documents should address the
interaction of access control with the replication function.
Stokes, et al Expires 2 September 2001 [Page 39]
Internet-Draft Access Control Model 2 March 2001
11. 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", RFC 2820, May 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.
[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R.
Morgan, "Authentication Methods for LDAP", RFC 2829, May
2000.
[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[IPV6] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
ACKNOWLEDGEMENT
This is to acknowledge the numerous companies and individuals who have
contributed their valuable help and insights to the development of this
specification.
AUTHOR(S) ADDRESS
Ellen Stokes Bob Blakley
Tivoli Systems Tivoli Systems
6300 Bridgepoint Parkway 6300 Bridgepoint Parkway
Austin, TX 78731 Austin, TX 78731
USA USA
mail-to: estokes@tivoli.com mail-to: blakley@tivoli.com
phone: +1 512 436 9098 phone: +1 512 436 1564
fax: +1 512 436 1199 fax: +1 512 436 1199
Stokes, et al Expires 2 September 2001 [Page 40]
Internet-Draft Access Control Model 2 March 2001
Debbie Rinkevich Robert Byrne
IBM Sun Microsystems
11400 Burnet Rd 29 Chemin du Vieux Chene
Austin, TX 78758 Meylan ZIRST 38240
USA France
mail-to: djbrink@us.ibm.com mail-to: rbyrne@france.sun.com
phone: +1 512 838 1960 phone: +33 (0)4 76 41 42 05
fax: +1 512 838 8597
Stokes, et al Expires 2 September 2001 [Page 41]
Internet-Draft Access Control Model 2 March 2001
Stokes, et al Expires 2 September 2001 [Page 42]
CONTENTS
1. Introduction....................................... 2
2. The LDAPv3 Access Control Model.................... 3
3. Access Control Mechanism Attributes................ 5
3.1 Root DSE Attribute for Access Control
Mechanism..................................... 5
3.2 Subentry Class Access Control Mechanism....... 6
4. The Access Control Information Attributes.......... 7
4.1 The BNF....................................... 8
4.1.1 ACI UTF-8 String Representation 8
4.1.2 ACI Binary Representation 10
4.2 The Components of entryACI and subtreeACI
Attributes.................................... 12
4.2.1 Access Rights and Permissions 12
4.2.2 Attributes 15
4.2.3 Subjects and Associated
Authentication 16
4.3 Grant/Deny Evaluation Rules................... 17
5. Required Permissions for each LDAP Operation....... 19
5.1 Bind Operation................................ 19
5.2 Search Operation.............................. 19
5.3 Modify Operation.............................. 22
5.4 Add Operation................................. 23
5.5 Delete Operation.............................. 24
5.6 Modify DN Operation........................... 24
5.7 Compare Operation............................. 25
5.8 Abandon Operation............................. 26
5.9 Extended Operation............................ 26
6. Required Permissions for Handling Aliases and
References......................................... 26
6.1 ACI Distribution.............................. 27
6.2 Aliases....................................... 27
6.3 Referrals..................................... 28
7. Controlling Access to Access Control
Information........................................ 28
8. ACI Examples....................................... 28
8.1 Attribute Definition.......................... 28
8.2 Modifying the entryACI and subtreeACI
Values........................................ 29
8.3 Evaluation.................................... 31
8.4 ModDN......................................... 33
- i -
9. Access Control Information (ACI) Controls.......... 36
9.1 GetEffectiveRights Control.................... 36
9.1.1 Request Control 36
9.1.2 Response Control 37
9.1.3 Client-Server Interaction 38
10. Security Considerations............................ 39
11. References......................................... 40
- ii -
Full Copyright Statement
Copyright (C) The Internet Society (2000).á 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 -
