Difference between revisions of "LDAP Authentication Design Notes (obsolete)"

From Davical
Jump to navigationJump to search
(Imported from MoinMoin)
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{TOCright}}
 +
==Status==
  
 +
LDAP authentication is present in the 0.9.x series.  For some clues on configuring DAViCal for LDAP authentication check out [[Configuration/Authentication_Settings/LDAP]].
  
{{TableOfContents}}
+
This is essentially historical now, but could be a useful template for anyone else writing an [[Auth Plugin]] in the future.
  
==Requirements==
+
== Requirements ==
  
 
In a private e-mail, Warren Howard wrote this fairly comprehensive definition of requirements, so I have posted it here wholesale.  
 
In a private e-mail, Warren Howard wrote this fairly comprehensive definition of requirements, so I have posted it here wholesale.  
<ul><li style="list-style-type:none">"If I was to configure an application tomorrow what LDAP features would I hope to see :  
+
:"If I was to configure an application tomorrow what LDAP features would I hope to see :  
</ul>
 
  
===SSL, TLS and Unix socket support all in URI notation===
+
=== 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 127.0.0.1:389?  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.  
 
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 127.0.0.1:389?  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===
+
=== LDAP v3 support by default ===
  
 
Some applications default to v2, which I think is just silly these days.  
 
Some applications default to v2, which I think is just silly these days.  
  
===Support for both anonymous and non-anonymous bind===
+
=== 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".  
 
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===
+
=== 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.  
 
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===
+
=== 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.  
 
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===
+
=== 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 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.  
 
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 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.  
  
==Design Notes==
+
== Design Notes ==
  
 
===SSL, TLS and Unix socket support all in URI notation===
 
===SSL, TLS and Unix socket support all in URI notation===
Line 59: Line 61:
 
The current authentication hook allows for authentication to fall back to the local database, so this should be able to be done relatively easily.  
 
The current authentication hook allows for authentication to fall back to the local database, so this should be able to be done relatively easily.  
  
==Status==
+
[[Category:Completed]]
 
 
Some work on this has been done, and is in progress hopefully releasable along with 0.8.?
 

Latest revision as of 00:29, 9 January 2015

Status

LDAP authentication is present in the 0.9.x series. For some clues on configuring DAViCal for LDAP authentication check out Configuration/Authentication_Settings/LDAP.

This is essentially historical now, but could be a useful template for anyone else writing an Auth Plugin in the future.

Requirements

In a private e-mail, Warren Howard wrote this fairly comprehensive definition of requirements, so I have posted it here wholesale.

"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 127.0.0.1:389? 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.

Design Notes

SSL, TLS and Unix socket support all in URI notation

Supported by PHP since 4.0.4 so this won't be a problem.

LDAP v3 support by default

Supported by PHP.

Support for both anonymous and non-anonymous bind

Supported by PHP.

No dependency at all on the schema that is being used

The configuration details for the LDAP will need to provide a mapping of LDAP data to the RSCDS schema.

Support for filtered LDAP searches

Some configured LDAP searches could be used to populate relationships for the authenticated user.

Support for both the native application authentication and LDAP

The current authentication hook allows for authentication to fall back to the local database, so this should be able to be done relatively easily.