Méthodes d'authentification

Vue d'ensemble du processus d'authentification de Moodle

Le cas d'usage qui passe par l'authentification d'un utilisateur Moodle commence lorsque ce dernier clique sur le lien "connexion" sur l'interface utilisateur. La procédure suivante est ensuite déroulée (à l'exception de quelques détails mineurs ou de scénarios plus rares) :

1. Dans le cas général, la page de présentation de login "par défaut", /login/index.php est produite. Celle-ci demande le "vecteur d'identité" de l'utilisateur. Si l'administrateur technique de Moodle a défini explicitement une page alternative de login dans les paramètres généraux d'authentification du menu Administration, l'utilisateur est directement rerouté sur cette page.
2. L'utilisateur entre ses données d'identification.
3. Le code de la page /login/index.php est exécuté :
   1. La liste des plugins d'authentification actifs est obtenue.
   2. La fonction loginpage_hook() est exécutée sur chaque plugin, permettant à chacun d'entre eux de capturer la demande d'authentification.
   3. Une vérification est faite pour s'assurer que l'identifiant remplit les critères de Moodle (alphanumerique, autorisant les points, tirets et arobaces).
   4. La fonction authenticate_user_login() de /lib/moodlelib.php est appelée, laquelle renvoie un objet $user. (Des détails sur la procédure suivent.)
   5. L'objet $user est testé pour vérifier si l'authentification/identification est correcte (l'objet $user doit être valide) et, dans la négative, renvoie l'utilisateur à la page d'entrée avec un message d'erreur. Autrement (authentification réussie), elle détermine l'endroit où l'utilisateur désirait aller à l'origine (avant l'authentification) et l'y conduit, à moins qu'une situaiton particulière ne soit détectée, comme par exemple la nécessité de changer le mot de passe (première connexion).

Voici le scénario général, mais l'exécution de la fonction authenticate_user_login() passe par un certain nombre d'étapes qui peuvent avoir un certain intérêt :

1. Elle récupère la liste des plugins actifs.
2. Elle recherche l'identifiant dans le champ "username" de la table mdl_user pour vérifier l'existance d'un compte à ce "nom", et récupère le mode d'authentification (et donc l'identité du plugin qui la gère, notamment au moment de la première connexion).
3. Elle crée un objet $user, qui contient les données trouvées dans l'enregistrement correspondant de la table mdl_user si l'identifiant est connu ; Si ce dernier n'est pas trouvé, l'objet sera vide.
4. Sur la base du plugin d'authentification identifié pour cet utilisateur, (notez que si l'utilisateur n'est pas connu dans la table locale, Moodle essayera les étapes suivantes avec tous les plugins actifs et dans l'ordre de la pile, jusqu'à ce qu'une réponse positive soit obtenue, ou que tous les plugins possibles aient été testés) :
   1. Elle appelle la méthode user_login() proposée par le plugin, qui renvoie un booléen indiquant que l'authentification est réussie ou non. Si le résultat est négatif, (pas d'authentification), elle saute ce qui suit et essaie le plugin suivant.
   2. Si le plugin authentifie l'utilisateur par le biais d'une requête externe (tout sauf à partir de la base de données de Moodle), la méthode update_user_record() est appelée pour récupérer toutes les données utiles possible sur l'utilisateur (son nom, ses informations de contact, etc.)
   3. Elle crée l'enregistrement d'utilisateur Moodle s'il n'existe pas déjà.
   4. Elle appelle la méthode sync_roles() du plugin permettant d'appliquer une politique particulière d'attribution de rôles si les informations suffisantes sont disponibles.
   5. Notifie tous les plugins actifs que l'utilisateur a bien été authentifié, en appellant la méthode user_authenticated_hook() sur chacun d'eux.
5. Si tout s'est bien passé, l'objet $user est retourné. Dans le cas contraire un objet null (false) est retourné.

Creating and enabling an authentication plugin

To create and register an authentication plugin, do the following:

1. Choose a name for your plugin. We'll use 'sentry' as an example below; change it to whatever name you have chosen.
2. Under your Moodle installation root, create the directory /auth/sentry. It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc.
3. Create the file /auth/sentry/auth.php. Within the file, create a class auth_plugin_sentry that extends auth_plugin_base from /lib/authlib.php. (You will need to require_once the authlib file.)
4. Implement the user_login() function in your auth.php file, and create or override additional functions based on your plugin's requirements.
5. Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication". You will see your plugin in the list, appearing as [[auth_sentrytitle]]. You can enable it and move it up and down in the order. At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.
6. If you don't like seeing [[auth_sentrytitle]] as the name of your plugin in the Moodle UI, you'll need to create language files for your plugin. Do this by creating the directory /auth/sentry/lang, and under it, a directory for each language that your installation needs to support. (Example: /auth/sentry/lang/en_us_utf8.) Within each of these language directories, create a file called auth_sentry.php. That file should set the desired value for $string['auth_sentrytitle'] for that language. You can also set the plugin description by setting $string['auth_sentrydescription'], and you can also assign other translatable strings that your plugin uses, in these files.
7. If you want to configure your plugin through the Moodle UI, implement config_form() and process_config() in the plugin class. You might find it convenient to use the 'db' plugin as a model for this. The plugin's config settings can then be managed through the Manage authentication page by clicking on the Settings link for that plugin, and the values will be stored in the mdl_config_pluginstable in the database.

Voir aussi

• Le forum Overview of entire authentication code flow (en anglais) contient un grand nombre de discussions à propose de l'authentification.