Il s'agit d'éléments expérimentaux d'authentification pour Dokuwiki.

All of these are compatible with user profile updates and the User Manager plugin, as best make sense (to me).

Note dokuwiki is just a hobby for me. dokuwiki security might be critical to you. If so you should take a good look at and understand the code before letting this stuff loose on the internet, particularly as you've just downloaded it from a random internet site. I monitor the mailing list, and periodically check this page and am very happy to take feedback. Perhaps if you like this stuff it might one day make its way into the core of dokuwiki.

— Grant Gardner 2008/12/16 18:55

I only have PHP5 to test with, but should work with PHP4 (>=4.0.7).

Tested with dokuwiki-2008-05-05

Unpack http://lastweekend.com.au/ggauth.zip into the top level directory of your dokuwiki installation (all files are in DOKU_HOME/inc/auth)

In local.php or local.protected.php set $conf['authtype'] = <your choice of backend>

Refer to the sections below for configuration of the specific backend

Nasty use of cleanID by the plain backend, outside of the object instance will remove “@” symbols from a user id, which is not very nice if you want to used email addresses as userids with either chained or split. (TODO: raise issue, consider security implications of deleting that code, or find some other way to do it without corrupting the global vars). The new active directory backend has some of this too, probably for good reason. Need to find out why.)

auth.php - update profile does not properly separate auth capabilities in that if your backend does not respond to both modMail and modName it will fail because one of them will be empty (TODO: raise issue with patch)

Abstract base class of all backends

It provides a getDefaultUser() method for constructing a user with a default name (the userid) and email address (user@<config value>)

An authentication only backend can be created by extending this class and implementing only the checkPass($user,$pass) method.

Many of the other user contributed backends (radius, ntlm, imap etc..) that extend plain could easily be refactored to extend simple and only provide authentication.

Assumes there is no way to test for existence of a user so every request for a specific user returns a default user. If you can test for existence, then you are likely overriding getUserData() anyway.

 
$conf['defaultgroup'] = 'somegroup'; # every user will be a member of this group
$conf['auth']['maildomain'] = 'localhost'; # default user email will be set to <user>@defaultDomain
$conf['auth']['debug'] = false; # debugging
$conf['auth']['debug_hidden'] = false; #hide debug in html output @see dbg() in infoutils.php
$conf['auth']['debug_to_file'] = false; #also debug to file @see dbglog in infoutils.php

Split authentication/authorisation backend, delegates authentication to one backend (login auth), authorisation to another (groups auth)

Extends: simple

$conf['auth']['split']['login_auth'] = 'ldap'    # the auth backend for authentication
$conf['auth']['split']['groups_auth'] = 'plain'  # the auth backend that supplies groups
$conf['auth']['split']['merge_groups'] = false   # should groups from login auth also be included
$conf['auth']['split']['use_login_auth_for_users'] = false # Should login auth be used for supplying the list of users for usermanager
$conf['auth']['split']['use_login_auth_for_name'] = false # Should login auth supply user name, or only used if groups auth provides an empty name
$conf['auth']['split']['use_login_auth_for_mail'] = false # Should login auth supply email address, or only used if groups auth provides empty email.

If auth login supports the 'external' method and does not implement checkPass then $conf['profileconfirm'] should be false or the password check will fail.

See also configuration of simple

List of users comes from groups auth unless $conf['auth']['split']['use_login_auth_for_users'] = true;

Create/modify/delete are delegated to both backends if they are capable. It is possible to modify a user that exists in only one backend in which case it will be created in the other. Obviously this is not transactional so you may find difficulties if errors occur on one but not the other.

It is also possible that the authoritative backend for password, name, or email does not accept updates but the non-authoritative one does, the updates will be successful but you won't see the result.

Extends: simple

Delegates to the first backend that responds to getUserData() with a non empty user.

Alternatively it can be configured to attempt authentication (user/pass) on each link in the chain until one passes. This is useful in the case of a backend that returns a default user for every request (eg pam, below), but will likely be slow for users that exist in deeper parts of the chain.

The *Profile* option is made available depending on the capabilities of the backend that represents the current user.

One of the backends can be specified as the one to use with the User Manager plugin.

Delegates that only provide the “external” authentication method are not supported as there is no way to test whether such a backend responds to a given user or not.

$conf['auth']['chained']['authtypes'] = # list of authtypes, eg 'ldap,plain'
$conf['auth']['chained']['usermanager_authtype'] = null; # which of the authtypes should be checked for usermanager capabilities
$conf['auth']['chained']['find_auth_by_password'] = false; # Follow the chain in the checkpass method.

Extends: simple

Supports external authentication via PHP_AUTH_USER and PHP_AUTH_PW as supplied via your webserver.

Note that the following config options should be set, as these features don't play nice with external authentication.

$conf['openregister']= 0; 
$conf['resendpasswd']= 0; 

Extends: http

This backend attempts to provide a logoff function for BASIC authentication.

It does not send the WWW:Authenticate headers at login, you need to configure your webserver to do that, eg via .htaccess

 $conf['auth']['httpbasic']['realm'] = 'dokuwiki' # must match the realm used for BASIC auth of your webserver.
 $conf['auth']['httpbasic']['logout'] = '' # custom logout message (may not be displayed in all browsers)

• Logout is not strictly possible with BASIC auth (see apache docs), and this is a very poor user unfriendly alternative
• @TODO try out the techniques mentioned here http://www.eecho.info/Echo/apache/basic-authentication/

Use htaccess formatted password and groups files common to other web applications.

Extends: httpbasic

Finds and reads a ”.htaccess” file then uses the AuthUserFile and AuthGroupFile directives to point to the list of users and groups respectively. A 3rd, non-standard, file “htuser” is used to store the fullname and the email address required by dokuwiki.

 $conf['authtype'] = 'htaccess';   
 #
 # name of .htaccess file, must exist if absolute, if relative will search for this file up to the document root.
 $conf['auth']['htaccess']['htaccess'] = '.htaccess'; 
 #
 # name of file to store names and emails for each user. if relative assumed same directory as "AuthUserFile" directive.
 $conf['auth']['htaccess']['htuser'] = 'htuser';

Also refer to httpbasic configuration.

A typical .htaccess file would live in the dokuwiki root directory or somewhere further up the path and look something like…

AuthName Dokuwiki
AuthUserFile /home/unison/dokuwiki/htpasswd
AuthGroupFile /home/unison/dokuwiki/htgroups

# Use Basic authentication
AuthType Basic
<Limit GET POST>
satisfy all
require valid-user
</Limit>

AuthUserFile must point to an existing (possibly empty) file.

AuthGroupFile is optional, but omitting it will only make sense if you set $conf['defaultgroup'] and set default acl to allow something on that group.

These files must be writable by your webserver user if you want to add new users, allow users to change passwords etc…

Although this backend extends httpbasic and will work effectively behind BASIC authentication, it works best with dokuwiki's normal login page by setting $conf['auth']['htaccess']['htaccess'] to point to a file containing the AuthUserfile and AuthGroupFile directives to point at files that are used for other applications.

You will lose single sign-on capability between applications but things like openregister and resendpasswd will work as dokuwiki intends.

Extends: simple

Refactored version of Pluggable Authentication Module backend to extend simple and implement change password.

The chpass method is experimental and has not been tested successfully because my pam-unix configuration requires the webserver to run as root to change passwords of other users.

$conf['authtype'] = 'pam';
$conf['auth']['pam']['chpass'] = false; #if enabled and module supports chpass, then user will be able to modify their own password

Which backend is right for me? Here are some scenarios to help you out.

Soln: Extend simple, implement checkPassword($user,$pass)

See pam as an example.

Soln: split (radius/plain)

ie, Implement RADIUS auth by extending simple as above, and use that backend for logins, and use plain or mysql to provide the groups.

Many of the user contributed backends (eg Radius, PAM, NTLM, imap) (TODO: links) extend plain and override the password check. They could easily be refactored to work in this fashion, thus allowing the use of mysql or something else to store groups.

Typically your dokuwiki install is in some dingy corner of the corporate and your dokuwiki admin isn't allowed to play with groups in the Corporate LDAP.

Soln: split (ldap / plain) and configured to get names/email addresses from the ldap backend.

eg. You have a large user base in the campus ldap and some additional external users that you want to give access to a subset of your dokuwiki

Soln: chained ( ldap, plain ).

This is getting fun

Soln: split ( chained ( ldap, plain ) / plain )

ie you can use chained as the login delegate for split. Two instances of plain will be created but they both point at the same configuration. Profile updates would be applied twice.

Note that this configuration has not been tested.

This is the configuration we use for our internal Dokuwiki server (since we sometimes want to bring in outside users, and they won't create AD accounts for it. Any AD user will have read abilities, and I configure the groups within Dokuwiki for write permissions*. Here is my config which I placed in local.protected.php:

<?php
/**
 * This is the advanced authorization settings
 */
$conf['authtype'] = 'split';

$conf['auth']['split']['login_auth'] = 'chained';
$conf['auth']['split']['groups_auth'] = 'plain';
$conf['auth']['split']['merge_groups'] = false;
$conf['auth']['split']['use_login_auth_for_users'] = false;
$conf['auth']['split']['use_login_auth_for_name'] = false;
$conf['auth']['split']['use_login_auth_for_mail'] = false;

$conf['auth']['chained']['authtypes'] = 'ldap,plain';
$conf['auth']['chained']['usermanager_authtype'] = null;
$conf['auth']['chained']['find_auth_by_password'] = false;

$conf['auth']['ldap']['server'] = '{AD Server Name}';
$conf['auth']['ldap']['binddn'] = '{AD Server Account}';
$conf['auth']['ldap']['bindpw'] = '{AD Server Password}';
$conf['auth']['ldap']['usertree'] = '{User Tree}'; //cn=something,dc=somethingelse,dc=somethingelse2,etc
$conf['auth']['ldap']['userfilter'] = '(samaccountname=%{user})';
$conf['auth']['ldap']['mapping']['name'] = 'displayname';
$conf['auth']['ldap']['referrals'] = 0;
$conf['auth']['ldap']['version'] = 3;
//$conf['auth']['ldap']['debug'] = 1; //Might come in handy.

* One issue with this is that you cannot use the user manager to create accounts, and assign them to groups. You will need to either change the backend and disassociate it with AD when configuring accounts, or edit the users.auth.php file and manually add the accounts. Once the accounts are added, you can edit them within DW and assign them to groups. I've tested this with both 2008-05-05 and 2009-02-14. — Thomas Hawkins 2009/02/23

Soln: httpbasic

Soln: split ( httpbasic / plain )

Soln: htaccess