Re: SASL bind: no authcid->DN conversion - group ACLs do not work (ITS#891)

[Kurt@OpenLDAP.org]

At 04:40 PM 11/15/00 +0000, adamson@andrew.cmu.edu wrote:

>gombasg had said:
>
>  I'm using GSSAPI/Kerberos5. So I must teach each application which want
>  to bind to the LDAP server to search for the current Kerberos credential
>  cache, extract the actual Kerberos principal the user is authenticated
>  as, and construct a bind DN? This would defeat the main idea between
>  SASL, namely that user applications need not to know about the
>  underlying authentication mechanism at all.
>
>
>
>OK, I thought this was for Joe User running ldapsearch or somesuch. It is
>an interesting problem, telling each client how to obtain the SASL name
>and map it to a DN. The SASL name can be had from sasl_getprop(), but that
>will not be available at the time of first calling the bind, only
>afterwards. 
>
>What you want, and it sure sounds dandy, is to be able to send a SASL
>authorize request with the bind, saying authorize to something like
>"cn=self,cn=authz",

NO!  The client should leave the authorization identity emtpy to
get self!  Otherwise it must provide the authorization identity
which is implied by the authentication identity.  This may be
very hard to determine.

>and have the server use it's SASL regexp code to
>generate the user's DN based on the SASL name it has. That way, the
>rules for converting usernames to DN's is stored on the server, and each
>client need not be taught the rules.
>
>Is that about what you want, and does anyone else see a glaring problem? 

Let's take this to devel.

>I'm glad to see people are starting to think about how SASL authz works in
>LDAP and what features are needed.
>
>
>  -Mark Adamson
>   Carnegie Mellon