[Date Prev][Date Next]
Re: SASL bind: no authcid->DN conversion - group ACLs do not work (ITS#891)
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
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", 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?
I'm glad to see people are starting to think about how SASL authz works in
LDAP and what features are needed.