Re: Fwd: Comments on the ACL Model draft

[George_Robert_Blakley_III@tivoli.com]

All

--bob

Bob Blakley
Chief Scientist
Tivoli SecureWay Business Unit


>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
and
<bb> protocols which can cause - from the viewpoint of LDAP clients - "silent"
and
<bb> 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
policy
<bb> 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 policy
is capable of
<bb> expressing the semantics defined in the LDAP ACL model draft.  The server
is responsible
<bb> for enforcing the policy which has been defined.  The underlying server's
policy *IS* the
<bb> LDAP policy; this draft merely provides an implementation-independent way
of
<bb> administering the subset of that (underlying) policy which supports the
LDAP access control
<bb> semantics.  The underlying server administrator may make changes in the
policy, without
<bb> using the LDAP protocol and *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
LDAP-supporting
<bb> repositories must support identical policy semantics, and the consensus has
been that this
<bb> is not feasible.