Tim Murphy wrote:
Turbo Fredriksson wrote:
The mapping means that when you to authenticate yourself with a SASL id (e.g. uid=myname+realm=development), the server can work out what your ldap ID is (e.g. uid=myname,ou=staff,dc=mycompany,dc=com)."Kurt" == Kurt D Zeilenga <Kurt@OpenLDAP.org> writes:
Kurt> This release contains the following major enhancements:
Kurt> * SASL authentication/authorization mapping Kurt> * SASL in-directory storage of authentication secrets
How much of this is finished/working (at all)? And is it what I think
it is? Exactly WHAT is it?
This is very important because if you log in via SASL then you must use a SASL ID. In 2.0.23 it becomes very difficult or impossible to create Access Control Lists for people if all the server knows is the SASL ID. Now the server will know your LDAP ID (called the Distinguished Name) and be able to give you appropriate access permissions to the items in the directory.
The in-directory secret storage is simple: When you log in to openldap using SASL authentication, the server has to check your password against it's own copy. In 2.0.23 the copy was stored in /etc/sasldb but thanks to the new mapping feature, it can now be stored in the LDAP directory itself. This means that you can manage passwords with your LDAP tools alone - no need for separate tools to manipulate a separate password database. e.g. if you delete a user in the directory you won't have to also delete his/her entry in /etc/sasldb as well.