[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
draft-ietf-ldapext-acl-model-02.txt
Drafts editor,
Please post for Mar IETF ldapext session.
Working group,
Attached is the updated access control model draft that
incoporates comments from the ldapext session last Dec
plus a proposed LDIF.
Thanks.
Ellen
Internet-Draft B. Blakley
LDAP Extensions WG D. Byrne
Intended Category: Standards Track E. Stokes
Expires: 26 August 1999 IBM
26 February 1999
Access Control Model for LDAP
<draft-ietf-ldapext-acl-model-02.txt>
STATUS OF THIS MEMO
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that
other groups may also distribute working documents as
Internet Drafts.
Internet Drafts are draft documents valid for a maximum
of six months. Internet Drafts may be updated, replaced,
or obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material
or to cite them other than as a "working draft" or "work
in progress."
To learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net,
nic.nordu.net, ftp.isi.edu, or munnari.oz.au.
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
ABSTRACT
This document describes the access control model for the
Lightweight Directory Application Protocol (LDAP)
directory service. It includes a description of the
model, the LDAP controls, and the extended operations to
the LDAP protocol. A separate document defines the
corresponding application programming interfaces (APIs).
RFC2219 [Bradner97] terminology is used.
Blakley, Byrne, Stokes [Page 1]
Internet-Draft Access Control Model 26 February 1999
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 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).
A separate document defines the corresponding application
programming interfaces (APIs).
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.
This proposal defines the protocol elements for
transmission of this access control policy data in an
LDAP environment and an attribute that defines the access
control mechanism in effect for a given part of the LDAP
namespace. The instantiation of an access control model
at the directory server is not defined in this document.
By defining only what flows on the wire allows existing
access control mechanisms to be used at the directory
server.
No mechanism is defined in this document to control
access to access control information; this is vendor
Blakley, Byrne, Stokes [Page 2]
Internet-Draft Access Control Model 26 February 1999
dependent.
Encoding of access control information on the wire is per
the LDAPv3 specifications.
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 policy information" (acpi) for an
object or a collection of objects defines which subject
security attributes entitle a subject to which granted
rights. The access control policy information for an
object is 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 policy 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.
Blakley, Byrne, Stokes [Page 3]
Internet-Draft Access Control Model 26 February 1999
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
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.
An "object" is the target of operations in an information
system.
An "operation" is the result of executing the code
accessed through a named entry point in an information
system.
An "operation name" is the name of the entry point
through which an operation is invoked in an information
system.
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 policy
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
Blakley, Byrne, Stokes [Page 4]
Internet-Draft Access Control Model 26 February 1999
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 intiates 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.
4. The Model
4.1 Access Control Activity Lifecycle
The access control proposal described in this draft
addresses four activities:
- Creation of subject security attribute information
and access control policy information
- Retrieval of subject security attribute information
at the time an access request is made
- Evaluation of access requests against policy,
resulting in an access decision
- Replication of access control policy information
from one server to another
4.2 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.
Blakley, Byrne, Stokes [Page 5]
Internet-Draft Access Control Model 26 February 1999
The diagram below illustrates the componentry of an LDAP
system and the placement of the function specified in
this draft.
+-------------+
| Application |
+-------------+
+--------+
| LDAP |
| Client |
+--------+
|
|
| <-- LDAP Extended Access Control
Controls
| or Extended Access Control
Operations
v
+-----------------------------+
| LDAP Server (e.g. SLAPD) |
+-----------------------------+
. |
. |
. |
. |
v v
+----------+ +-----------+
| Access | | |
| Control |<.....| Datastore |
| Manager | | |
+----------+ +-----------+
LDAP clients use the controls and extended operations
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 is compatible with that defined in the section
titled "Operational Semantics of Access Control
Operations" (found after the control and extended
Blakley, Byrne, Stokes [Page 6]
Internet-Draft Access Control Model 26 February 1999
operation definition).
The access control administration mechanisms specified in
this document are neutral with respect to policy
inheritance mechanisms, explicit vs. implicit denial,
and group nesting.
4.3 Bind and Credentials
A bind authenticates a principal to the directory. A
principal is represented by a DN. A principal has a set
of credentials that are used for determining whether
access to resources specified in ldap operations. These
credentials may be pushed to the server by the client or
may be pulled by the server from the directory data.
Credentials may be local with respect to the server. If
not local (owned by another server or administrative
scope), then the server may decide to define a trust
model that states how to evaluate the trust of a
credential at bind time. The definition of such a trust
model is outside the scope of this document.
5. Access Control Information Schema
5.1 Attributes
5.1.1 Root DSE Attribute for Access Control Mechanism
The following attribute may be included in the Root DSE.
(<OID to be assigned>
NAME 'supportedACIMechanisms'
DESC list of access control mechanisms supported
by this directory server
SYNTAX LDAPOID
)
Two access control mechanisms are defined by this
document:
LDAPv3 <OID to be assigned>
X500 <OID to be assigned>
Blakley, Byrne, Stokes [Page 7]
Internet-Draft Access Control Model 26 February 1999
Other vendor access control mechanisms can be defined (by
OID) and are the responsibility of those vendors to
provide the definition and OID.
5.1.2 Subschema Attribute for Access Control Mechanism
A given naming context must provide information about
which access control mechanism is in effect for that
portion of the namespace. The following attribute must
be in each subschema entry associated with a naming
context whose access control mechanism is different from
adjacent naming contexts supported by that directory
server.
- aCIMechanism lists the value (an OID) that defines
the access control mechanism in effect for the scope
of that subschema entry
5.2 Other Defined Parameters/OIDs
5.2.1 Rights Families and Rights
The following rights families are defined:
LDAPv3 <OID to be assigned>
X500 <OID to be assigned>
Other parties can (and will) define other rights
families. It is the responsibility of those parties to
provide the definition and OID.
5.2.1.1 LDAPv3 Rights Family
Access rights can apply to an entire object or to
attributes of the object. Each of the LDAP access rights
are discrete. One permission does not imply another
permission. The rights may be ORed together to provide
the desired rights list.
Rights which apply to attributes are:
1 Read Read attribute values
2 Write Write attribute values
4 Search Search entries with specified attributes
8 Compare Compare attributes
Blakley, Byrne, Stokes [Page 8]
Internet-Draft Access Control Model 26 February 1999
Rights that apply to an entire object are:
16 Add Add an object below this object
32 Delete Delete this object
Rights that apply to the object to which the directory
object points are:
64 Manage Perform a privileged operation; used to
restrict access to operations which
read or write especially sensitive data
128 Use Execute; useful in controlling access to
the objects referred to by directory
entries than in controlling access to
the directory entries themselves
256 Get Get retrieves the attribute values
512 Set Set writes the attribute values
5.2.1.2 The X.500 Rights Family
<define the rights for X.500>
5.2.2 DN Types
The following DN Types are defined:
- access-id, OID=<OID to be assigned>
- group, OID=<OID to be assigned>
- role, OID=<OID to be assigned>
access-id, group, and role MUST be supported. An acess-
id is a non-collection (non-group and non-role objects)
DN that can be authenticated.
Other parties can (and will) define other DN Types. It
is the responsibility of those parties to provide the
definition and OID.
6. Access Control Parameters for LDAP Controls & Extended
Operations
This section defines the parameters used in the access
Blakley, Byrne, Stokes [Page 9]
Internet-Draft Access Control Model 26 February 1999
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 which is get/set is for the directory entry
(ENTRY) or the directory entry and its subtree (SUBTREE).
rightsFamily specifies the family of rights that will be
get/set for the control or extended operation performed.
A rights family has a defined set of rights.
dnType speficies the type of subject security attribute.
Defined types are access-id, group, and role.
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. We define two well-known
subjectDNs, the strings
- public - meaning public access for all users
- this - meaning the user whose name matches the entry
being accessed
Four operations are defined:
- ACI_GRANT grants the rights specified in the
rightsList for the given subject. If an access
control list does not exist for the specified
entry/attribute, then the access control list is
created with the granted rights for the given
subject. If the access control list already exists
for the specified entry/attribute, then the access
control list is modified to grant the rights for the
given subject.
- ACI_DENY denies the rights specified in the
rightsList for the given subject. No implementation
Blakley, Byrne, Stokes [Page 10]
Internet-Draft Access Control Model 26 February 1999
is implied for this operation. For example, denial
of rights may be implemented as explicit denial
(negative rights) on the access control list or
removal of rights from the access control list.
- ACI_REPLACE replaces the entire access control list
for the specified entry/attribute. If an access
control list does not exist for the specified
entry/attribute, then the access control list is
created with the granted rights for the given
subject.
- ACI_DELETE deletes the entire access control list
for the specified entry/attribute.
attrs specifies the list of attributes against which the
operation is performed. attrs can be defined using a
LDAP filter expression.
7. Access Control Information (ACI) Controls
The access control information controls provide a way to
manipulate access control information in conjunction with
an LDAP operation such as ldap_add, ldap_modify, or
ldap_search. Four LDAP controls are defined for
transmission of access control information. These
controls allow access control information to be get/set
while manipulating other directory information. The
controls are:
- updateAccessControl to manipulate access control
information during ldap_add and ldap_modify
operations
- getEffectiveAccess to obtain the effective rights
for a given directory entry(s) for a given subject
during a ldap_search operation
- listSubjectRights to get the access control
information for a given directory entry(s) during a
ldap_search operation
- specifyCredentials to specify a set of credentials
for the bind identity (DN) during a ldap_bind
Blakley, Byrne, Stokes [Page 11]
Internet-Draft Access Control Model 26 February 1999
operation
7.1 updateAccessControl
7.1.1 Request Control
This control is included in the ldap_add and
ldap_modify 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:
updateAccessControlRequest ::= SEQUENCE {
targetDN LDAPDN,
updates SEQUENCE OF SEQUENCE {
rightsFamily LDAPOID,
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType LDAPOID,
subjectDN LDAPString,
perms SEQUENCE OF SEQUENCE {
operation ENUMERATED {
ACCESS_GRANT (1),
ACCESS_DENY (2),
ACCESS_REPLACE (4),
ACCESS_DELETE (8)
},
rightsList ENUMERATED,
attrs LDAPSTRING
}
}
}
The targetDN specifies the initial directory entry in DN
syntax on which the updateAccessControl control is
performed. updates is a set of sequences that state the
whichObject (entry or entry plus subtree) and specifics
Blakley, Byrne, Stokes [Page 12]
Internet-Draft Access Control Model 26 February 1999
of the control request to be performed. One or more
rightsFamily can be updated. The rightsList can be set
(per the specified operation) on one or more attributes
(defined by a LDAPString using LDAP filters to define
which attributes) for a given rightsFamily, dnType, and
subjectDN.
7.1.2 Response Control
This control is included in the ldap_add and ldap_modify
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). The controlValue is an OCTET
STRING, whose value is the BER encoding of a value of the
following SEQUENCE:
updateAccessControlResponse ::= {
result ENUMERATED {
success (0),
operationsError (1),
unavailableCriticalExtension (12),
noSuchAttribute (16),
undefinedAttributeType (17),
invalidAttributeSyntax (21),
unavailable (52),
unwillingToPerform (53),
other (80)
}
}
7.1.3 Client-Server Interaction
The updateAccessControlRequest control specifies that for
the given target, a scope and a set of rights are
updated. The server that consumes the add or modify
operation can also set the access control information for
those directory entry(s).
There are six possible scenarios that may occur as a
result of the updateAccessControl control being included
on the add or modify request:
Blakley, Byrne, Stokes [Page 13]
Internet-Draft Access Control Model 26 February 1999
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 addResponse or modifyResponse 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 specified
rightsFamily 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 addResult or modifyResult message and include
the updateAccessControlResponse control in the
addResult or modifyResult message.
4. If the server supports this control but for some
reason such as cannot process specified
rightsFamily and the client specified FALSE for the
control's criticality field, then the server should
process as 'no rights updated for that family' and
include the result Unavilable in the
updateAccessControlResponse control in the
addResult or modifyResult message.
5. If the server supports this control and can set the
rights per the rightsFamily information, then it
should include the updateAccessControlResponse
control in the addResult or modifyResult message
with a result of success.
6. If the add/modify request failed for any other
reason, then the server SHOULD omit the
updateAccessControlResponse control from the
addResult or modifyResult message.
Blakley, Byrne, Stokes [Page 14]
Internet-Draft Access Control Model 26 February 1999
The client application is assured that the correct rights
are set if and only if the result code in the
updateAccessControlResponse control is success. If the
server omits the updateAccessControlResponse control from
the addResult or modifyResult message, the client SHOULD
assume that the control was ignored by the server.
The updateAccessControlResponse control, if included by
the server in the addResponse or modifyResponse message,
should have the result set to either success if the
rights were updated or set to the appropriate error code
as to why the rights could not be updated.
The server may not be able to remove a right because it
may not exist in that target object's attribute; in this
case, the remove request for that right is ignored with
success.
7.2 getEffectiveRights Control
7.2.1 Request Control
This control is 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 {
targetDN LDAPDN,
request SEQUENCE OF SEQUENCE {
rightsFamily LDAPOID | "*",
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType LDAPOID,
subjectDN LDAPString,
}
}
Blakley, Byrne, Stokes [Page 15]
Internet-Draft Access Control Model 26 February 1999
The targetDN specifies the initial directory entry in DN
syntax on which the getEffectiveRights control is
performed. request is a set of sequences that state the
whichObject (entry or entry plus subtree) and specifics
of the control request to be performed. One or more
rightsFamily can be be obtained for a given subjectDN ad
dnType. A "*" in the rightsFamily field indicates that
the rights for all rights families defined for the
subjectDN / dnType are to be returned. The scope of the
operation is controlled by the scope set in the
ldap_search operation.
7.2.2 Response Control
This control is 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). 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),
unavailable (52),
unwillingToPerform (53),
other (80)
}
}
The effective rights returned are returned with each
attribute returned by the search result. So, the result
for ldap_search is:
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
Blakley, Byrne, Stokes [Page 16]
Internet-Draft Access Control Model 26 February 1999
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue,
rightFamily LDAPOID,
rightsList ENUMERATED,
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
}
}
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.
7.2.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
Blakley, Byrne, Stokes [Page 17]
Internet-Draft Access Control Model 26 February 1999
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
rightsFamily 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
rightsFamily 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 rightsFamily 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.
Blakley, Byrne, Stokes [Page 18]
Internet-Draft Access Control Model 26 February 1999
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.
7.3 listSubjectRights Control
7.3.1 Request Control
This control is 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:
listSubjectRightsRequest ::= SEQUENCE {
targetDN LDAPDN,
request SEQUENCE OF SEQUENCE {
rightsFamily LDAPOID | "*",
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType LDAPOID | "*",
subjectDN LDAPString | "*",
}
}
The targetDN specifies the initial directory entry in DN
syntax on which the getEffectiveRights control is
performed. request is a set of sequences that state the
whichObject (entry or entry plus subtree) and specifics
of the control request to be performed. One or more
rightsFamily can be be obtained for a given subjectDN ad
dnType. A "*" in the rightsFamily field indicates that
the rights for all rights families defined for the
subjectDN / dnType are to be returned. A "*" in the
dnType field indicates that all dnTypes are processed by
this request. A "*" in the subjectDN field indicates
that all subjectDNs are processed by this request. The
scope of the operation is controlled by the scope set in
Blakley, Byrne, Stokes [Page 19]
Internet-Draft Access Control Model 26 February 1999
the ldap_search operation.
7.3.2 Response Control
This control is 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). The controlValue is an OCTET
STRING, whose value is the BER encoding of a value of the
following SEQUENCE:
listSubjectRightsResponse ::= {
result ENUMERATED {
success (0),
operationsError (1),
unavailableCriticalExtension (12),
noSuchAttribute (16),
undefinedAttributeType (17),
invalidAttributeSyntax (21),
unavailable (52),
unwillingToPerform (53),
other (80)
}
}
The subjects' rights returned are returned with each
attribute returned by the search result. So, the result
for ldap_search is:
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue,
rightsFamily LDAPOID,
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType LDAPOID,
Blakley, Byrne, Stokes [Page 20]
Internet-Draft Access Control Model 26 February 1999
subjectDN LDAPString,
rightsList ENUMERATED
}
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.
7.3.3 Client-Server Interaction
The listSubjectRightsRequest control specifies the rights
that MUST be returned for the scope of the search. The
server that consumes the search operation looks up the
rights for the returned directory information and returns
the result as search information associated with the
scope of that search.
There are six possible scenarios that may occur as a
result of the listSubjectRights 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 specified
rightsFamily and the client specified TRUE for the
control's criticality field, then the server SHOULD
Blakley, Byrne, Stokes [Page 21]
Internet-Draft Access Control Model 26 February 1999
do the following: return
unavailableCriticalExtension as a return code in
the searchResult message and omit the
listSubjectRightsResponse control in the
searchResult message.
4. If the server supports this control but for some
reason such as cannot process specified
rightsFamily 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
listSubjectRightsResponse control in the
searchResult message.
5. If the server supports this control and can return
the rights per the rightsFamily information, then
it should include the listSubjectRightsResponse
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
listSubjectRightsResponse control from the
searchResult message.
The client application is assured that the correct rights
are returned for the scope of the search operation if and
only if the listSubjectRightsResponse control returns the
rights. If the server omits the
listSubjectRightsResponse control from the searchResponse
message, the client SHOULD assume that the control was
ignored by the server.
The listSubjectRightsResponse control, if included by the
server in the searchResponse message, should have the
searchResult set to either success if the rights were
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.
Blakley, Byrne, Stokes [Page 22]
Internet-Draft Access Control Model 26 February 1999
7.4 specifyCredentials Control
7.4.1 Request Control
This control is included in the ldap_bind 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:
specifyCredentialRequest ::= SEQUENCE {
credential LDAPString
}
}
The credential specifies the credential (e.g. groups,
roles, etc) that the client is requesting be associated
with the bind DN for access control determination in
subsequent ldap operations. This provides a 'push' model
for credentials where the client attempts to 'push' the
credential to the server. The server may process at bind
time as follows:
- server may unconditionally ignore
- server may unconditionally accept
- server may define trust model and evaluate of the
trust of each credential
If this control is not used, it is assumed that the
server determines (pulls) the credentials associated with
the bind DN when needed in subsequent ldap operations to
provide access control.
7.4.2 Response Control
This control is included in the ldap_search message as
part of the controls field of the LDAPMessage, as defined
in Section 4.1.12 of [LDAPv3].
Blakley, Byrne, Stokes [Page 23]
Internet-Draft Access Control Model 26 February 1999
The controlType is set to <OID to be assigned>. The
criticality MAY be either TRUE or FALSE (where absent is
also equivalent to FALSE). The controlValue is an OCTET
STRING, whose value is the BER encoding of a value of the
following SEQUENCE:
specifyCredentialsResponse ::= {
result ENUMERATED {
success (0),
operationsError (1),
unavailableCriticalExtension (12),
unavailable (52),
unwillingToPerform (53),
other (80)
}
}
No data is returned; just the result is returned.
Although this extends the bind operation, there are no
incompatibilities between versions. LDAPv2 cannot send a
control. A LDAPv3 client cannot send this request to a
LDAPv2 server. A LDAPv3 server not supporting this
control cannot return the additional data.
7.4.3 Client-Server Interaction
The specifyCredentialsRequest control specifies the
credentials that the client was the server to use for
access control in subsequent ldap operations. The server
that consumes the bind operation may unconditionally
accept, ignore, or evaluate the trust of the specified
credentials at bind time and returns only a success or
failure response (no data returned).
There are six possible scenarios that may occur as a
result of the specifyCredential control being included on
the bind 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 bindResponse message. This behavior is
Blakley, Byrne, Stokes [Page 24]
Internet-Draft Access Control Model 26 February 1999
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 specified credential
(e.g. server decided to evaluate the trust of that
credential and the result is the server not
trusting all the credentials or unconditionally
ignores the credential) 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 bindResult message and omit the
specifyCredentialResponse control in the bindResult
message.
4. If the server supports this control but for some
reason such as cannot process specified credential
(e.g. server decided to evaluate the trust of that
credential and the result is the server not
trusting all the credentials or unconditionally
ignores the credential) and the client specified
FALSE for the control's criticality field, then the
server should process as 'credential ignored' and
include the result Unavailable in the
specifyCredentialResponse control in the bindResult
message.
5. If the server supports this control and evaulates
the trust of that credential and the result is the
server trusting all the credentials, then it should
include the specifyCredentialResponse control in
the bindResult message with a result of success.
6. If the bind request failed for any other reason,
then the server SHOULD omit the
specifyCredentialResponse control from the
bindResult message.
Blakley, Byrne, Stokes [Page 25]
Internet-Draft Access Control Model 26 February 1999
The client application is assured that the correct
credentials are used by the server when specified by the
client for subsequent ldap operations if and only if the
specifyCredentialResponse is successful. If the server
omits the specifyCredentialResponse control from the
searchResponse message, the client SHOULD assume that the
control was ignored by the server.
The specifyCredentialResponse control, if included by the
server in the bindResponse message, should have the
bindResult set to either success if the credentials were
accepted by the server or set to the appropriate error
code as to why the credentials were not accepted.
8. Access Control Extended Operations
Three extended operations (analogous to the controls) are
defined for transmission of access control information.
These operations help with the management of access
control information independent of manipulating other
directory information. The extended operations are:
- LDAP Update Access Operation to manipulate access
control information
- LDAP Get Effective Access to obtain the effective
rights for a given directory entry for a given
subject
- LDAP List Subject Rights to get the access control
information for a given directory entry
8.1 LDAP Update Access Operation
ldapUpdateAccessRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] <OID to be assigned>,
requestValue [1] OCTET STRING }
where
requestValue ::= SEQUENCE {
targetDN LDAPDN,
updates SEQUENCE OF SEQUENCE {
rightsFamily LDAPOID,
Blakley, Byrne, Stokes [Page 26]
Internet-Draft Access Control Model 26 February 1999
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType LDAPOID,
subjectDN LDAPString,
perms SEQUENCE OF SEQUENCE {
operation ENUMERATED {
ACCESS_GRANT (1),
ACCESS_DENY (2),
ACCESS_REPLACE (4),
ACCESS_DELETE (8)
},
rightsList ENUMERATED,
attrs LDAPSTRING
}
}
}
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 result code.
ldapUpdateAccessResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] <OID to be assigned> OPTIONAL,
result [11] OCTET STRING OPTIONAL }
where
result ENUMERATED {
success (0),
operationsError (1),
unavailableCriticalExtension (12),
noSuchAttribute (16),
undefinedAttributeType (17),
invalidAttributeSyntax (21),
unavailable (52),
unwillingToPerform (53),
other (80)
}
Blakley, Byrne, Stokes [Page 27]
Internet-Draft Access Control Model 26 February 1999
If the server does not recognize the request name, it
MUST return only the response fields from LDAPResult,
containing the protocolError result code.
8.2 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 {
rightsFamily LDAPOID,
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType LDAPOID,
subjectDN LDAPString,
}
}
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 {
rightsFamily LDAPOID,
Blakley, Byrne, Stokes [Page 28]
Internet-Draft Access Control Model 26 February 1999
rightsList ENUMERATED,
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
attrs LDAPSTRING
}
If the server does not recognize the request name, it
MUST return only the response fields from LDAPResult,
containing the protocolError result code.
8.3 LDAP List Subject Rights
ldapListSubjectRightsRequest ::= [APPLICATION 23]
SEQUENCE {
requestName [0] <OID to be assigned>,
requestValue [1] OCTET STRING }
where
requestValue ::= SEQUENCE {
targetDN LDAPDN,
updates SEQUENCE OF SEQUENCE {
rightsFamily LDAPOID | "*",
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType LDAPOID | "*",
subjectDN LDAPString | "*",
}
}
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 result code.
ldapListSubjectRightsResponse ::= [APPLICATION 24]
SEQUENCE {
COMPONENTS OF LDAPResult,
Blakley, Byrne, Stokes [Page 29]
Internet-Draft Access Control Model 26 February 1999
responseName [10] <OID to be assigned> OPTIONAL,
subjectRightsList [11] OCTET STRING OPTIONAL }
where
subjectRightsList ::= SEQUENCE OF SEQUENCE {
rightsFamily LDAPOID,
whichObject ENUMERATED {
LDAP_ENTRY (1),
LDAP_SUBTREE (2)
},
dnType LDAPOID,
subjectDN LDAPString,
perms SEQUENCE OF SEQUENCE {
rightsList ENUMERATED,
attrs LDAPSTRING
}
}
}
If the server does not recognize the request name, it
MUST return only the response fields from LDAPResult,
containing the protocolError result code.
9. 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).
We consider five types of actions:
- LDAP Access Control Policy Update actions:
invocations of the LDAP Update Access Extended
Operation or LDAP Update Access Control.
- LDAP Access Control Policy Query operations:
invocations of the LDAP Get Effective Access
Extended Operation, LDAP Get Effective Access
Control, LDAP List Subject Rights Extended
Operation, or LDAP List Subject Rights Control.
Blakley, Byrne, Stokes [Page 30]
Internet-Draft Access Control Model 26 February 1999
- 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...).
- Other operations: anything else, including Datastore
operations which do not change the access policy
enforced by the server.
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 with an access-
denied exception if it requires any right not
Blakley, Byrne, Stokes [Page 31]
Internet-Draft Access Control Model 26 February 1999
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
operation.
- LDAP Update (Deny), LDAP Access Request
The Request will fail with an access-denied
exception 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
Blakley, Byrne, Stokes [Page 32]
Internet-Draft Access Control Model 26 February 1999
granted to the requesting subject by the Update
operation. The Request will fail with an access-
denied exception 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
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 with an access-denied
exception 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 Update, LDAP Query
The result of the Query is not defined.
- LDAP Update (Grant), Datastore Update, LDAP Query
The result of the Query is not defined.
- LDAP Update (Deny), Datastore Update, LDAP Query
The result of the Query is not defined.
- LDAP Update (Replace), Datastore Update, LDAP Access
Request
The result of the Access Request is not defined.
- LDAP Update (Grant), Datastore Update, LDAP Access
Request
The result of the Access Request is not defined.
Blakley, Byrne, Stokes [Page 33]
Internet-Draft Access Control Model 26 February 1999
- LDAP Update (Deny), Datastore Update, LDAP Access
Request
The result of the Access Request is not defined.
10. LDIF Syntax for Access Control Information
In order to provide a LDAP-enabled mechanism for dumping
and reloading the access control information (ACI) within
the directory, a corresponding LDIF representation for
that ACI must be used.
The LDIF format for access control information is an
expansion of the existing LDIF format. Additional
'changetypes' are defined to specify that the following
information is related to the directory security policy.
When specifying multiple changetype operations (as in the
example below) the ACI LDIF works similar to the modify
LDIF.
Most attributes used within the LDIF definition
correspond to a parameter in the protocol API. For
example, the protocol defines a parameter to specify the
type of DN, and therefore so does the LDIF. In these
cases, the intent is to exactly represent the data that
would flow on an updateAcl.
The LDIF breaks the security information into two
distinct halves; a section which controls the ACI and a
section which controls the administrative policy owner.
There are two different changetypes to handle there two
different concepts. The policyOwner is intended to
represent administrator information and can be used to
recognize administrative domains. The ACI information is
intended to represent what DNs have permission to perform
various operations on a particular object.
An additional LDIF attribute not found in the protocol is
'explicitACI' and 'explicitOwner'. These flags, in
conjunction with the ACIScope and ownerScope, are
intended to be used by different implementations to relay
information about possible inheritance structures and
hierarchy.
Blakley, Byrne, Stokes [Page 34]
Internet-Draft Access Control Model 26 February 1999
The intent is that each entry and attribute represented
in LDIF as its ACI specified explicitly. It is assumed
that when the LDIF is used to populate the directory, it
is vendor-defined whether and how the ACI may be
optimized features associated with that given directory
server, e.g. inheritance, sparse ACI model, etc.
10.1 The BNF
< ChangeType> ::= "updateACI" | "updateOwner"
- operation to be performed
< subjectDn > ::= < printable string >
- The DN which is being given / denied permission
< dnType > ::= "access-id" | "role" | "group"
- type of the subject DN
< aCIFamily > ::= < oid >
- Describes the dnTypes and permissions. Following
will be those in the IETF defined family
< aCIScope > ::= "entry" | "subtree"
- whether the ACI applies to this entry, or the
entire tree
< explicitACI > ::= "true" | "false"
- whether this ACI is explicit. The server decided the
semantics of an explicit ACI.
< action > ::= "grant" | "deny" | "add" | "delete"
- what action to take on the ACI
< rights > ::= < permission >*
- The permissions granted or denied
< permission > ::= "a" | "d" | "r" | "s" | "w" | "c"
| "g" | "s" | "m" | "u"
- Permissions allowed
< attrs > ::= [ < attributeString> + [ ","
+ < attributeString > ] * ]
- one or more Attributes Strings using the same set of
permissions
Blakley, Byrne, Stokes [Page 35]
Internet-Draft Access Control Model 26 February 1999
< attributeString > ::= < printable string >
- what is being protected
< policyOwner > ::= < dn >
- the owner for this object
< ownerDnType > ::= "access-id" | "role" | "group"
- type of the owner DN
< explicitOwner > ::= "true" | "false"
- whether this owner DN is explicit. The server decided
the semantics of an explicit owner.
< ownerScope > ::= "entry" | "subtree"
- whether the ACI applies to this entry, or the
entire tree
10.2 An Example
This is an example of ACI for a given entry (DN). It is
formatted for easier reading.
dn: cn=Some Entry, ou=Org, c=Country
changetype: updateOwner
family: IETFFamilyOID
ownerScope: subtree
policyOwner: cn=OwnerDn
ownerDnType: access-id
explicitOwner: TRUE
changetype: updateOwner
family: IETFFamilyOID
ownerScope: subtree
policyOwner: cn=System Owners, o=Company
ownerDnType: group
explicitOwner: TRUE
changetype: updateACI
family: IETFFamilyOID
explicitACI: TRUE
aCIScope: subtree
DnType: group
subjectDN: cn=Anybody
action: grant
rights: rsc
attrs: accessClass1
Blakley, Byrne, Stokes [Page 36]
Internet-Draft Access Control Model 26 February 1999
changetype: updateACI
family: IETFFamilyOID
aCIScope: subtree
explicitACI: TRUE
dnType: role
subjectDN: cn=myAccessGroup,o=Company
action: grant
rights: ad
attrs: object
action: grant
rights: rsc
attrs: attribute1, attribute2
11. Security Considerations
This draft 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.
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-01.txt>, August 1998.
[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.
Blakley, Byrne, Stokes [Page 37]
Internet-Draft Access Control Model 26 February 1999
[Bradner97] Bradner, Scott, "Key Words for use in RFCs to
Indicate Requirement Levels", RFC 2119.
AUTHOR(S) ADDRESS
Bob Blakley Ellen Stokes
IBM IBM
11400 Burnet Rd 11400 Burnet Rd
Austin, TX 78758 Austin, TX 78758
USA USA
mail-to: blakley@us.ibm.com mail-to: stokes@austin.ibm.com
phone: +1 512 838 8133 phone: +1 512 838 3725
fax: +1 512 838 8597 fax: +1 512 838 8597
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 0156
Blakley, Byrne, Stokes [Page 38]
Internet-Draft Access Control Model 26 February 1999
Blakley, Byrne, Stokes [Page 39]
CONTENTS
1. Introduction....................................... 2
2. Overview........................................... 2
3. Terminology........................................ 3
4. The Model.......................................... 5
4.1 Access Control Activity Lifecycle............ 5
4.2 Access Control Information Model............. 5
4.3 Bind and Credentials......................... 7
5. Access Control Information Schema.................. 7
5.1 Attributes................................... 7
5.1.1 Root DSE Attribute for Access Control
Mechanism 7
5.1.2 Subschema Attribute for Access
Control Mechanism 8
5.2 Other Defined Parameters/OIDs................ 8
5.2.1 Rights Families and Rights 8
5.2.2 DN Types 9
6. Access Control Parameters for LDAP Controls &
Extended Operations................................ 9
7. Access Control Information (ACI) Controls.......... 11
7.1 updateAccessControl.......................... 12
7.1.1 Request Control 12
7.1.2 Response Control 13
7.1.3 Client-Server Interaction 13
7.2 getEffectiveRights Control................... 15
7.2.1 Request Control 15
7.2.2 Response Control 16
7.2.3 Client-Server Interaction 17
7.3 listSubjectRights Control.................... 19
7.3.1 Request Control 19
7.3.2 Response Control 20
7.3.3 Client-Server Interaction 21
7.4 specifyCredentials Control................... 23
7.4.1 Request Control 23
7.4.2 Response Control 23
7.4.3 Client-Server Interaction 24
- i -
8. Access Control Extended Operations................. 26
8.1 LDAP Update Access Operation................. 26
8.2 LDAP Get Effective Rights Operation.......... 28
8.3 LDAP List Subject Rights..................... 29
9. Operational Semantics of Access Control
Operations......................................... 30
10. LDIF Syntax for Access Control Information......... 34
10.1 The BNF...................................... 35
10.2 An Example................................... 36
11. Security Considerations............................ 37
12. References......................................... 37
- ii -