Re: Implementing object-based access control

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:30 PM 8/17/99 -0400, you wrote:
>I've finished the first cut at adding support for "access control info" (aci)
>attributes to any object.

I look forward to review your ITS submission (hint).  From your
description, it sounds quite useful.  Here are a few comments.

> your schema needs to be changed to ALLOW attributes of type "aci". 
> I did this in my setup via the slapd.oc.conf file, and just added
> the aci attribute to a few object classes (person, groupOfNames, etc.).

Don't do that!  Instead add an auxilary objectclass

	objectclass aciobject
		requires
			objectclass
		allows
			aci

> Eventually this attribute type will need to be made user-mod operational

The draft has "aci" defined as a normal user attribute type.
As such, use of an auxilary object class that allows the attribute
is likely the best approach.

>The format of an aci attribute is taken from
>"draft-ietf-ldapext-acl-model-03.txt".

But I assume you have maintained our existing access semantics
and not:
  5.2.1.1:
       Each of the LDAP access rights are discrete. One
	permission does not imply another permission.

Eventually we probably should implement discrete rights (behind
an #ifdef or config directive)... but that's project for another
day.

>As that document
>states, "It is inappropriate to use Internet-Drafts as reference material."

Early implementation of I-D, in my opinion, is a important part of
the Internet Standard process.  The statement, in my opinion, is
to ward off use of the I-D outside of this process.

I encourage you to provide feedback to the authors of the I-D and/or
to the IETF LDAPext WG.

>           < permission > ::= "r" | "s" | "w" | "c"
>
>Note that in the draft document, the "s" permission is defined as 
>"set", but then
>all the examples define "s" to mean "search". 

This is a bug in the draft.
    < permission > ::= "a" | "d" | "r" | "s" | "w" |
       "c" | "g" | "s" | "m" | "u" | "e">

Note that "s" is listed twice.

Note also that there some permissions apply to attributes,
some to entries, and some to the object to which the directory
entry points.

OpenLDAP, of course, has has one set of permissions to which
it applies to attributes, the "entry", and "children".  Though
you could map some of the draft perms into our model, some
would require modification of the model.  However, some items
do not fit into our existing model.

Example, the draft has "add" entry under this entry, "delete"
this entry, and "edit" this entry's DN.  Our existing model
allows for an entry to be added, deleted, or dn edited only
if one has "write" permissions the parent's "children".
Our model is similiar to POSIX filesystem semantics for adding,
removing, and renaming a subdirectory which I find much cleaner.

Also, we have a perm "auth" which doesn't map well into the
semantics of the draft.  However, I believe it wise to support
"auth" perms in ACIs.

Because of these differences in semantics, I recommend we do
NOT use "aci" as the name of the attribute type to hold the
information.  I suggest we use "acinfo" or "olaci" or such
(Or maybe VendorACI).  Suggest we use a #define to allow
us to easily change it.

We probably should maintain a specification (in I-D form)
that describes implemented semantics.  This will help us
under the differences between our implementation and the
acl-model draft, hopefully bettering both (and convergence).
We'll also likely have to use our own OIDs until the IETF
documents which OIDs to use.  We have an "experimental"
OID arc set aside for such purposes.  (We shall NEVER
release code with "experimental" OIDs).

>The "subtree" and <level> scopes are not currently supported, although I think
>aci inheritance is a very important feature to include.

Small steps.  Implementing "base" is a great start.

>The reason I did not
>implement this in my first go-around is that getting a "raw" entry 
>from a backend
>is not exactly straight-forward.  I'd need to do this in order to walk up (or
>down) the tree.

Well, you need to walk up the tree to prevent you don't entry deadlock.
However, you might have to apply ACIs in the opposite order.

>If anyone has recommendations on how to do this, let me know.
>It would certainly be possible to do this by adding another backend callback,
>which would be useful for other things, but that's beyond the scope of what I'm
>doing here.

We'll have to sort out the best approach for this and other items
once your first set of patches have been integrated and tested.

Kurt