RE: SASL, slapd internal searches

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

At 04:46 PM 3/8/2003, Howard Chu wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>
>> At 08:25 AM 3/8/2003, Igor Brezac wrote:
>
>> >> I did not study your changes; however, I think you should ensure
>> >> that authz code does have the necessary auth permissions, such
>> >> that an administrator is given the possibility to control how
>> >> the auth/authz process takes place, and to inhibit some forms of
>> >> it by means of ACL.  I think this is the spirit of the auth
>> >> permission level.
>
>> >It is important that ACLs be applied to the resulting DN of
>> the internal
>> >search. However, saslauthz is more complicated than
>> sasl-regex because
>> >sasl-regex is setup by the administrator; on the other hand
>> saslAuthz*
>> >attribs are normally managed by users.  If a root-privileged
>> operations
>> >are allowed, saslAuthzTo can easily be abused.  I wonder if a special
>> >saslAuthz acl can be implemented?
>
>The docs already recommend that saslAuthzTo only be writable by privileged
>users. The easiest thing to do is "access to attr=saslAuthzTo by * auth" and
>only let the rootDN write it.
>>
>> The internal authentication/authorization searching, as with all
>> other authentication/authorization access, should be done anonymously
>> but require "auth" not "search"/"read".  This allows the administrator
>> have complete control over which values in the directory are to be
>> used for authentication/authorization purposes.
>
>Yes. Where specific values are requested, such as slap_sasl_checkpass, AUTH
>access is explicitly checked. This is not the issue though; the problem is
>that a normal backend search is done in the first place, and this search
>requires anonymous SEARCH access in order to locate any entry.

Yes.  I am suggesting that we change it to only require AUTH access here.

>Additionally,
>when evaluating a search in a sasl-regexp map, test_filter() requires SEARCH
>access to each of the attributes in the filter.

and here as well.

>Since these searches are
>administrative, configured by the admin in the first place, I believe they
>should always be unrestricted.  Otherwise it requires you to set ACLs that
>give anonymous SEARCH access to entries and various attributes.

The problem is that rootdn always has accessing... making it
impossible for the administrator to restrict use of the attributes
for authentication/authorization purposes.

I'm suggesting that we just special case this.  (By adding a flag
in the Operation structure which says "this is an
authentication/authorization operation, treat ACL_SEARCH/READ
as ACL_AUTH").

Kurt