LDAP Authentication Design Notes (obsolete)

From Davical
Revision as of 19:10, 30 November 2006 by AndrewMcMillan (talk) (Imported from MoinMoin)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search


If I was to configure an application tomorrow what LDAP features would I hope to see :

SSL, TLS and Unix socket support all in URI notation

In other words in the configuration file when asked what is your LDAP server (or host and port) your would write ldap://myldapserver, ldaps:// or ldapi:// (the config file for phpldapadmin is a good example). If I am configuring an application on the same LDAP server then I prefer to use ldapi://path/to/socket. It is fast and secure. Unfortunately this is not always possible so I also have port 389 open and listening on the localhost by virtue of stunnel. But why use stunnel? Why not listen directly with slapd on port Because the ONLY way to authenticate against my LDAP server is by using PLAIN authentication and therefore all connections to the directory must be encrypted either TLS or SSL but TLS preferred. Sadly there are some applications that do not do SSL/TLS LDAP authentication that well, Apache is one that comes to mind, there are various differences between Apache 1.3 and 2 and the available Apaches modules that support LDAP authentication. In these cases it is easier to set up stunnel.

LDAP v3 support by default

Some applications default to v2, which I think is just silly these days.

Support for both anonymous and non-anonymous bind

Today I allow anonymous bind to the LDAP server, because it is behind the firewall but in the future I want to make the directory available outside the firewall! Before that can happen all the applications that use the directory need to be able to bind to the directory first with username and password before they start searching for the user id that matches that of the user attempting to authenticate. In other words it is a "security thing".

No dependency at all on the schema that is being used

Thankfully, this has never been a problem, to date no application has tried to force "attribute selection" on me. Instead all applications will ask me which attribute contains the user id or which attribute contains the mail id and so on.

Support for filtered LDAP searches

The default LDAP settings that are pretty much available in every config file are server and port, base dn (aka ldap suffix), bind dn, bind password, ldap search base, ldap search scope, login attribute and timeout value. But sometimes you don't want all the results returned by the default search, you'd like to filter the results by looking for and matching or not matching additional attributes and return a smaller set of results.

== Support for both the native application authentication and LDAP authentication at the same time == This is quite important. Take for example Subversion. Our Subversion server is LDAP enabled, if you have an LDAP id then you have Subversion access, plus access to email and a host of other company resources! What do I do when a contractor is brought in to work on one project, they require access to Subversion only not to everything! The simplest way for me in this scenario is to create a local id in the appropriate Subversion config file, Subversion will authenticate the user id against either LDAP or its local configuration. Sympa does something similar it allows LDAP authentication but at the same time the native authentication method remains available, that way I can support company internal uses and at the same time external uses (like clients) can also have access. When it comes to the "admin" id there is sometimes issues when using multiple authentication sources. Some applications handle the admin id in a particular way. Sometimes the admin id has to be of a particular form like "root" for example for which some admins end up creating a "root" id in their directory (http://gentoo-wiki.com/HOWTO_OpenGroupware.org_with_OpenLDAP#create_an_LDAP_root_account_for_opengroupware --- btw it turns out that there is a way that you can rename the admin id for Opengroupware so that it can be any id in your directory). I think the most elegant solution is to be able to list those id's which have admin rights in the application config file, if they authenticate via LDAP or locally it shouldn't matter. Failing that even when LDAP is configured it should be possible to log in as admin as described in the contents of the config file.