Re: attribute for 'access to filter=...'

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>At 03:04 AM 4/16/2005, Hallvard B Furuseth wrote:
>> I wonder if OpenLDAP should define an operational attribute intended
>> to be used for 'filter=' and 'set=' access controls?  Maybe just with
>> string syntax, more or less free-form contents chosen by the admin.

[Rearranging the answer]

>> Our LDAP project is about to define an attribute for filter= and I've
>> seen others need it, but since its functionality is implementation-
>> specific it doesn't quite seem to belong in an organization's or LDAP
>> project's schema.
>
> Though specification of ACLs are certainly implementation
> specific, this attribute doesn't appear to be implementation
> specific itself.

Yes, wrong word.  It's the ability to use it which is implementation
specific.  I was thinking that if one switches implementation, then
one must likely replace the attribute with some other arrangement.

> What's the operational semantics of the attribute?

All I imagined was "whatever slapd.conf says", plus a textual
description: Only use it for access statements, and maybe describe a
recommended or mandatory format.  Or a format which is "mandatory"
only in the sense that OpenLDAP might someday be hard-coded to know
about this attribute and optimize some uses of it.

attributeType ( <oid> NAME 'OpenLDAPobjectAccess'
        DESC 'Admin-specified filter/set access control information'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ;; Directory String
        USAGE directoryOperation )

or Case Ignore List (Postal Address) syntax, but that can be less useful
since it has no ORDERING rule, and maybe the syntax and substring
matching rule is more confusing to people than the above.

It might safer, and more flexible for future extensions (if anyone can
come up with any), to use OpenLDAP-specific syntax or matching rules
even if they work just like the ones above.  That seems like overkill
to me though.

-- 
Hallvard