Configuration/Authentication Settings

From Davical
< Configuration
Revision as of 21:34, 8 January 2015 by Gorka (talk | contribs) (Using LDAP)
Jump to navigationJump to search

Internal Authentication

No special configuration should be needed for DAViCal's built-in user and group management.

External Authentication

Using LDAP

See LDAP Configuration for some detailed examples of configuring DAViCal to use an LDAP server for an authentication source. Here is a brief example, however:

$c->authenticate_hook['call'] = 'LDAP_check';
$c->authenticate_hook['config'] = array(
    'host' => '',
    'port' => '389',
    'bindDN'=> 'cn=manager,cn=internal,dc=tennaxia,dc=net',
    'passDN'=> 'xxxxxxxx',
    'baseDNUsers'=> 'dc=tennaxia,dc=net', //where to look at valid user
    'filterUsers' => 'objectClass=kolabInetOrgPerson', //filter that must validate an valid user
    'baseDNGroups' => 'ou=divisions,dc=tennaxia,dc=net', //where to look for groups
    'filterGroups' => 'objectClass=posixGroup', //filter with same rules as filterUsers
    'mapping_field' => array('username' => 'uid',
                             'updated' => 'modifyTimestamp',
                             'fullname' => 'cn' ,
                             'email' =>'mail',
                             'active' => ), //used to create the user based on his ldap properties
   'group_mapping_field' => array('username' => 'cn',
                            'updated" => 'modifyTimestamp',
                            'fullname" => 'cn' ,
                            'members" =>'memberUid'
                            ), //used to create the group based on the ldap properties
    'default_value' => array("date_format_type" => "E","locale" => "fr_FR"),
    'format_updated'=> array('Y' => array(0,4),'m' => array(4,2),'d'=> array(6,2),
                             'H' => array(8,2),'M'=>array(10,2),'S' => array(12,2))
    'scope' => 'subtree', // Search scope to use, defaults to subtree 

Explanation of parameters:

host The hostname of the LDAP server
port The port to connect to the LDAP server on
bindDN The DN to bind to
passDN The password for the bind
baseDNUsers The base DN to look in for valid users
filterUsers A filter which must pass for this to be a valid user
baseDNGroups The base DN to look in for valid groups
filterGroups A filter which must pass for this to be a valid group
mapping_field An array of DAViCal field names vs. their LDAP mappings
group_mapping_field An array of DAViCal field names vs. their LDAP mappings
default_value An array of DAViCal field names vs. fixed default values
format_updated An array, keyed on Y, m, d, H, M and S with the values being arrays of (start,length) for substring operations on the DAViCal 'updated' field sourced from LDAP.
scope The search scope for all LDAP searches(users and groups)

NB: it's important to remember to install the LDAP modules for PHP (the php5-ldap package under debian/ubuntu).

Using a different 'AWL' database

The "AWL" library contains the basic database structure for user data which is used by DAViCal, and it is possible to use this data from a different database. This plugin is written more-or-less as an example of how to write an authentication plugin, but may be useful.

Fallback to internal authentication on failure

In some cases it is desirable that you fallback to DAViCal's internal authentication when external authentication fails. You might desire this if you have some locally configured users in addition to the majority who are in the LDAP server.

In such a case you can set:

$c->authenticate_hook['optional'] = true;

in your configuration file. This doesn't make authentication optional: everyone will still need a username and password! It just means that for someone who is not present in the external authentication system their credentials will then be checked against the internal system and they'll be allowed in if that matches then.

When the Webserver does the authentication

It is quite common that the webserver can do the authentication for you, and you just want DAViCal to trust the username that the webserver will pass through.

In this case you can set something like:

$c->authenticate_hook['server_auth_type'] = 'Basic';

to match the types of authentication which your server is providing to PHP as "$_SERVER['AUTH_TYPE']". DAViCal will then trust the value received as $_SERVER['REMOTE_USER'] (or, beginning with 1.1.2, $_SERVER['REDIRECT_REMOTE_USER']) to be correct.

The above will make the HTTP Basic Authentication from the webserver be used and trusted for authentication within both, the administration websites and CalDAV (i.e. caldav.php). Note: It seems that the "include_once('AuthPlugins.php');" is not necessary if this should only apply to the administration websites but not to CalDAV (i.e. caldav.php).

One could also set an array to accept different types, e.g.:

$c->authenticate_hook['server_auth_type'] = array('Negotiate','Basic');

but of course, these types must exist (it seems Negotiate does not).

This does not work together with the ldap_driver (at least in davical 1.0.2). You may get it working with the $c->authenticate_hook['config']['i_use_mode_kerberos'] = "i_know_what_i_am_doing" though.

When PHP is used as CGI/FastCGI with Apache and mod_ssl, then currently AUTH_TYPE remains unset, even when HTTP Basic Authentication (respectively mod_ssl fakeBasicAuth) was done by the server. This is a bug in Apache and/or limitation in the CGI specification. One workaround is an intermediate CGI wrapper, which sets AUTH_TYPE unconditionally to e.g. "Basic" (currently (see [1] and [2]) this is case-sensitive in contrast to the CGI spec).