[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Implementing object-based access control


>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.

OK, I'll do another round of improvements and make a submission in a few days. So far the changes are limited to 4 files (about 95% in acl.c). It should slip in pretty easily.

> 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


"Yah, what he said."

>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.

Already done both ways, with a #if to choose between the two. Right now it's compiled (on my test server) with discrete rights, due in large part because of 5.2.1.1 and also S13 in draft-ietf-ldapext- acl-reqts-02.txt. It's a simple difference, really. Just <= instead of &.

Personally, I prefer discrete rights, especially since you can emulate right "levels" using a discrete rights implementation, but not the other way around. It's nice to be able to set access to attr=userPassword by self write-compare-not-read and such.

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


I've got a list started already ;-)

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. 

"ooops" ;-)

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.

This relates to the problem of getting entries from the backend. I think being able to get an Entry directly from the backend would make room for lots of improvements, in general.

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.


Implemented, but commented out so it's there for later.

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.

Wouldn't it be better just to use our own OID? The semantics are not different from the draft, it's just that the draft leaves room for interpretation (in some cases intentionally, like for "deny"). In other words, there is no case where I'm saying "the draft is wrong, I'm doing this a different way." There are only cases where I'm saying "the draft does not specify what to do, so I'm doing it this way." (Ummm, other than the discrete rights issue.) There is always the chance that if/when the draft gets more specific, it will contradict the implementation. But won't the OID make the distinction? I'm just asking, I have no idea about the sanctioned way to handle this.

And in any case, it might be better to at least start by using something other than "aci" as the attribute type, as you suggest. I'll change it to "olaci".

Thanks for the tips,

Mark.