I wonder if it needs to be even stronger, perhaps even mentioning that
replication is very likely to break and potentially referrals as well.
-- Alexis
Alexis Bor
Directory Works, Inc.
alexis.bor@directoryworks.com
http://www.directoryworks.com
-----Original Message-----
From: Richard V Huber [mailto:rvh@qsun.mt.att.com]
Sent: Thursday, March 23, 2000 6:54 AM
To: George_Robert_Blakley_III@tivoli.com
Cc: ietf-ldapext@netscape.com; jayhawk@qsun.mt.att.com
Subject: Section 7 of ACL Model draft
We'd like to summarize our understanding of your email and of Section 7
to make sure we understand properly.
We think you are saying that an implementation may provide access
control syntax and semantics beyond those described in the draft. If
they do so, the additional permissions may cause behavior that is
undefined by the LDAP Access Control Model.
In that case, shouldn't section 7 contain a statement along the lines
of:
Implementations MAY implement additional access control mechanisms
beyond those described in this standard. However, implementations
that wish to be completely consistent with the standard for
over-the-wire exchange of access control information MUST avoid use
of mechanisms that cannot be expressed using the model defined in
this document.
Rick Huber
Ryan Moats
>Page 21:
>
>TECHNICAL:
>
>We are not sure we understand the purpose of Section 7. Is it just a
>set of high level examples of sequence of operations?
<bb> Section 7 is necessary because LDAP is only a protocol specification,
not
<bb> an implementation specification. Implementations are free to build
richer
<bb> access control semantics than those specified in the LDAP ACL Model
draft,
<bb> and they are also free to provide "proprietary" administrative
interfaces
<bb> and protocols which can cause - from the viewpoint of LDAP clients -
"silent"
<bb> and even undefined changes in the access control policy.
<bb> Section 7 describes two things:
<bb> (1) The effect of LDAP access control administrative
operations on the
<bb> access decision which will subsequently be made by a server
implementation
<bb> (that is, the semantics of indidividual ldap ACL admin
operations), and
<bb> (2) under what circumstances administrative operations
performed on the
<bb> server implementation but not performed through the LDAP
access control
<bb> administration protocol will result in the semantics of
access control
<bb> policy being undefined from the viewpoint of an LDAP client.
>TECHNICAL:
>
> - 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.
>
>Is this meant to say that the underlying DBMS/filesystem/etc may impose
>policy which overrides the policies expressed by LDAP ACIs? Or is it
>meant to say that non-LDAP means (SQL for an underlying RDBMS
>datastore) may change the data stored in ldapACI attributes? While
>either may be true in general, is it not part of the job of the server
>developer to make sure it doesn't happen? Shouldn't LDAP access
>control be the way that access control policy is expressed for an LDAP
>directory?
<bb> The server is free to support any policy it wants to as long as that
<bb> policy is capable of expressing the semantics defined in the LDAP ACL
<bb> model draft. The server is responsible for enforcing the
policy which
<bb> has been defined. The underlying server's policy *IS* the
LDAP policy;
<bb> this draft merely provides an implementation-independent way of
<bb> administering the subset of that (underlying) policy which
supports the
<bb> LDAP access control semantics. The underlying server
administrator may
<bb> make changes in the policy, without using the LDAP protocol and
<bb> *perhaps* without having any LDAP privileges. The changes
<bb> this administrator makes will be enforced even for LDAP resources.
<bb>
<bb> We've had a long set of discussions in the working group
about whether
all
<bb> LDAP-supporting repositories must support identical policy semantics,
and
<bb> the consensus has been that this is not feasible.