martinlanghoff b36a8fc4f5 Auth/LDAP
Bugfix - value truncation to fit Moodle database
- Added truncate_userinfo() to cleanup data coming from external auth
- Fixed auth_user_create() to truncate user info as appropriate

Auth_ldap_user_sync
- created external script that calls the function
- much faster update strategy on postgres and mysql: auth_sync_users now to uses bulk inserts into a temp table, and then use LEFT JOINs and plain old SELECTs to determine what users it has to insert.
- we now loop over smaller sets of data -- we are still memory-bound, but (a) it'll be easy to use LIMIT to manage that and (b) memory use is much lower now in all cases.
- postgres: phased commits in auth_user_sync() for the batch user upload phase
- Several feature and performance enhancements:
  - if a value is removed from ldap, it will be cleared from moodle
  - no-op updates (where the data does not change) are skipped
  - if a user disappears and then reappears in LDAP in two separate calls to auth_user_sync(),the account will be marked deleted and then be revived. before, the account would have been deleted and created anew.

Multi-source ldap values:

The LDAP auth module now accepts a comma separated set of LDAP field names. When creating or updating a user record, auth/ldap will retrieve all the relevant fields. The right-most values overwrites all the others.

This is particularly useful when updating the user's email address from an LDAP source, which may contain the email address in one of several fields (traditionally: mail, mailForwardingAddress, mailAlternateAddress).

If a value is updated and is set to update external auth and this field is using this multi-source ldap configuration, the auth/ldap module will retrieve the old value, find which field it was sourced from, and update that field in LDAP. If it fails to find the original source of the value, it will log it in error_log.


Log of patchsets applied:
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-131
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-137
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-139
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-172
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-173
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-189
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-190
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-208
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-212
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-216
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-279
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-282
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-287
	arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-294
2004-11-22 07:46:10 +00:00
..
2004-09-12 01:34:24 +00:00
2004-09-12 01:34:24 +00:00
2004-09-12 01:34:24 +00:00
2004-11-22 07:46:10 +00:00
2004-09-12 01:34:24 +00:00
2004-09-12 01:34:24 +00:00
2004-09-12 01:34:24 +00:00
2004-09-24 04:46:11 +00:00
2004-09-12 01:34:24 +00:00
2004-09-24 04:45:19 +00:00

This directory contains authentication modules.

Each of these modules describes a different way to 
check that a user has provided a correct 

   - username, and 
   - password.

Even when external forms of authentication are being
used, Moodle still maintains the internal "user" table 
with all the associated information about that user such
as name, email address and so on.

The active method is set by the admin on the Configuration page.


email - authentication by email  (DEFAULT METHOD)

    - user fills out form with email address
    - email sent to user with link 
    - user clicks on link in email to confirm
    - user account is created
    - user can log in


none  - no authentication at all .. very insecure!!
    
    - user logs in using ANY username and password
    - if the username doesn't already exist then
      a new account is created
    - when user tries to access a course they 
      are forced to set up their account details

manual - internal authentication only

    - user logs in using username and password
    - no way for user to make their own account


ldap  - Uses an external LDAP server

    - user logs in using username and password
    - these are checked against an LDAP server
    - if correct, user is logged in
    - optionally, info is copied from the LDAP
      database to the Moodle user database

    (see the ldap/README for more details on config etc...)


imap  - Uses an external IMAP server

    - user logs in using username and password
    - these are checked against an IMAP server
    - if correct, user is logged in
    - if the username doesn't already exist then
      a new account is created


pop3  - Uses an external POP3 server

    - user logs in using username and password
    - these are checked against a POP3 server
    - if correct, user is logged in
    - if the username doesn't already exist then
      a new account is created


nntp  - Uses an external NNTP server

    - user logs in using username and password
    - these are checked against an NNTP server
    - if correct, user is logged in
    - if the username doesn't already exist then
      a new account is created


db  - Uses an external database to check username/password
    
    - user logs in using username and password
    - these are checked against an external database
    - if correct, user is logged in
    - if the username doesn't already exist then
      a new Moodle account is created


------------------------------------------------------------------------------------

Authentication API

This file describes Moodle interface functions to authentication modules.

Most of functions are from ldap-authentication module and are not implemented (yet?)
on other modules. Please feel free to extend other modules to support same features
or roll your own module.

Some of new function are still tested and are not documented here yet.



AUTHENTICATION
Basic fuctions to authenticate users with external db

Mandatory: 
    
    auth_user_login ($username, $password) 
    
    Authenticate username, password with userdatabase.

    Returns:
    true if the username and password work
    and false if they don't

Optional:
    
    auth_get_userinfo($username)
    
    Query other userinformation from database.

    Returns:
    Userinformation in array ( name => value, .... 
    or false in case of error

COURSE CREATING

    auth_iscreator($username)

    should user have rights to create courses

    Returns:
    True if user have rights to crete cources otherwise false


USER CREATION

Functions that enable usercreation, activation and deactivation
from moodle to external database
  
  
    auth_user_exists ($username) 
   
    Checks if given username exist on external db

    Returns:
    true if given usernname exist or false
 
    auth_user_create ($userobject,$plainpass) 
 
    Creates new user to external db. User should be created
    in inactive stage until confirmed by email.

    Returns:
    True on success otherwise false


    auth_user_activate ($username) 
    
    activate new user after email-address is confirmed

    Returns:
    True on success otherwise false


    auth_user_disable ($username) {
    
    deactivate  user in external db.
    
    Returns:
    True on success otherwise false



USER INFORMATION AND SYNCRONIZATION

    auth_get_userlist () 

    Get list of usernames in external db.

    Returns:
    All usernames in array or false on error.
    

    auth_get_users($filter='*') 
    
    Get ALL USEROBJECTS FROM EXTERNAL DB.

    Returns:
    Array of all users as objects from external db