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

Re: OpenLDAP enhancements



This wouldn't be a backend... it just be a frontend handler
for that request (like how "cn=schema" is handled).  The existing
handlers only implement SEARCH, but you could implement MODIFY
handler.


Ah, yes, I see that now.  Thanks for the redirect.

This raises a question (for me) about the dn's being of the form "<suffix>, cn=config" vs. "cn=monitor, <suffix>". In private e-mail, it has been suggested that using the former method is limiting, especially when you want to have different configs for separate back-ends (or dir subtrees, I suppose). I think you touch on this in your mail, but I'm new to some of this jargon.

>In other words, schema and acl info would be
>accessed through backend.c, as real objects in the directory, stored
>wherever the (now minimal) conf file specified.  This would require
>mods to existing code, but would be more flexible than writing a
>"slapd.conf" backend.  (One benefit, for example, is that you could
>have a schema/acl server for a bunch of distributed LDAP servers, and
>you'd only have to maintain one "master" schema/acl by using the ldap
>backend as the source for your schema/acl).

This gets quite involved quite fast.  I would suggest small
steps.  That is, implement an extension to the static ACL system
that used dynamic ACI information.

 access *
	by aci=aci dynamic[none|auth|compare|search|read|write]

if entry has "aci" attribute, grant access based upon access control information located in the entries ACI attribute. Access granted
cannot exceed level specified.

>If the schema and acls are to be part of an LDAP directory, then
>where would they go?

I would suggest per-entry ACIs instead of per-backend-ACLs.  Hence
the ACI would be stored as the value an attribute type.  (The attribute
type could be defined as user-modifiable, operational attribute
so that it could be added to any existing entry without changing
the entry's objectclass definition... or as a normal attribute type
which would be allowed by an auxilary object class).

ACIs are nice, in that they are very fine-grained. This is something I'd like to see, too. However, how would you apply (change) access controls for a definable set of entries? Like:

    access to dn=".*, o=Company, c=XX" by * read

So you'd still want to be able to change the acls, even if you add per-object acis.

>How would you manage global vs. backend-specific acls?

This is already implemented.  Backend-specific ACLs are checked
before global ACLs.

I guess what I meant was, how would an acl's DN reflect its global/backend scope? One way is to have global acls look like "something, cn=ACL", and backend acls look like "something, cn=ACL, o=Company, c=XX" (putting aside other issues for the moment). Essentially, when I watch for these changes being made through LDAP, I need to know where to apply them (to global_acl or some be->be_acl).

>Would you maintain the order in which acls
>are applied, or change the rules from first-match to a big OR of all
>acls?

I would add per-entry ACIs to the mix and not change
basic ACL processing.

If acls are modifiable, though, then I have to preserver their "conf order" in order to keep the current behavior. That's fine, but how does this affect their DNs, attributes, etc.? One approach is to store all the acls in one big acl object/attribute. This is the simplest approach, but gets resource-intesive as the acl data grows. Maybe the assumption is that acls don't grow too large, and acis are where you do most fine-tuning.

Another approach is to have every ACL entry in a separate object (or separate attribute of the same object). In this case, there needs to be some way to maintain the order of the acls, either by an ordered cn convention, or a separate attribute, or one of a zillion other ways.

Storing all acls in one big object/attribute gets rid of a lot of issues, for sure, and does suggest a starting point for implementation. However, I think having an object for each acl has its advantages. Perhaps the ordering issues make this more trouble than it is worth.

Mark.