« Utiliser un serveur CAS (SSO) » : différence entre les versions
Aucun résumé des modifications |
mAucun résumé des modifications |
||
(Une version intermédiaire par un autre utilisateur non affichée) | |||
Ligne 1 : | Ligne 1 : | ||
[https://docs.moodle.org/fr/Authentification | [https://docs.moodle.org/fr/Authentification "Retour au sommaire de l'authentification"] | ||
Cette méthode utilise un serveur CAS (Central Authentication Service) pour authentifier les utilisateurs dans un environnement Single Sign On (SSO). Il est aussi possible d'utiliser une simple authentification LDAP. Si le nom d'utilisateur et le mot de passe donnés sont valides suivant le CAS, Moodle crée un nouvel utilisateur dans sa base de données, en héritant si nécessaire des attributs LDAP de l'utilisateur. Lors des connexions ultérieures, seuls le nom d'utilisateur et le mot de passe sont vérifiés. | Cette méthode utilise un serveur CAS (Central Authentication Service) pour authentifier les utilisateurs dans un environnement Single Sign On (SSO). Il est aussi possible d'utiliser une simple authentification LDAP. Si le nom d'utilisateur et le mot de passe donnés sont valides suivant le CAS, Moodle crée un nouvel utilisateur dans sa base de données, en héritant si nécessaire des attributs LDAP de l'utilisateur. Lors des connexions ultérieures, seuls le nom d'utilisateur et le mot de passe sont vérifiés. | ||
Les détails sur le fonctionnement d'un serveur CAS sont [http://www.ja-sig.org/products/cas/overview/cas2_architecture/index.html|largement commentés sur Internet]. Pour résumer, CAS fonctionne en reconfigurant une application Web de sorte à ce qu'elle ne réalise pas l'authentification elle-même, (moodle.example.com), | Les détails sur le fonctionnement d'un serveur CAS sont [http://www.ja-sig.org/products/cas/overview/cas2_architecture/index.html|largement commentés sur Internet]. Pour résumer, CAS fonctionne en reconfigurant une application Web de sorte à ce qu'elle ne réalise pas l'authentification elle-même, (moodle.example.com), mais à ce qu'elle envoie les utilisateurs non authentifiés vers un serveur CAS externe (cas.example.com) pour réaliser l'authentification. Le serveur CAS renvoie un certificat d'authentification à l'application web d'origine (moodle.example.com). Moodle peut alors extraire l'identité de l'utilisateur (username) et utiliser ses procédures internes d'identification (rôles, inscriptions au cours, capacités) pour générer la session et récupérer les informations du compte utilisateur (nom, avatar, etc.). L'avantage de ce procédé est que l'application web (moodle.example.com) n'a jamais à traiter les mots de passe, et qu'après la première identification/authentification, les utilisateurs peuvent transiter vers d'autres applications soumises au CAS sans représenter leur identité. | ||
==Configuration== | ==Configuration== |
Dernière version du 2 décembre 2009 à 12:50
"Retour au sommaire de l'authentification"
Cette méthode utilise un serveur CAS (Central Authentication Service) pour authentifier les utilisateurs dans un environnement Single Sign On (SSO). Il est aussi possible d'utiliser une simple authentification LDAP. Si le nom d'utilisateur et le mot de passe donnés sont valides suivant le CAS, Moodle crée un nouvel utilisateur dans sa base de données, en héritant si nécessaire des attributs LDAP de l'utilisateur. Lors des connexions ultérieures, seuls le nom d'utilisateur et le mot de passe sont vérifiés.
Les détails sur le fonctionnement d'un serveur CAS sont commentés sur Internet. Pour résumer, CAS fonctionne en reconfigurant une application Web de sorte à ce qu'elle ne réalise pas l'authentification elle-même, (moodle.example.com), mais à ce qu'elle envoie les utilisateurs non authentifiés vers un serveur CAS externe (cas.example.com) pour réaliser l'authentification. Le serveur CAS renvoie un certificat d'authentification à l'application web d'origine (moodle.example.com). Moodle peut alors extraire l'identité de l'utilisateur (username) et utiliser ses procédures internes d'identification (rôles, inscriptions au cours, capacités) pour générer la session et récupérer les informations du compte utilisateur (nom, avatar, etc.). L'avantage de ce procédé est que l'application web (moodle.example.com) n'a jamais à traiter les mots de passe, et qu'après la première identification/authentification, les utilisateurs peuvent transiter vers d'autres applications soumises au CAS sans représenter leur identité.
Configuration
A supposer que vous disposiez déjà d'un serveur CAS en état de marche, la configuration de Moodle pour un fonctionnement sous CAS est très simple à partir de l'interface d'administration.
Il existe une précaution à prendre pour les utilisateurs déjà authentifiés par une méthode LDAP simple ou l'une des autres méthodes d'authentification de Moodle :
- Pour tout utilisateur que vous voulez passer sous contrôle CAS, et qui dispose déjà d'un compte Moodle et donc d'une entrée dans la table "user" de Moodle, vous devrez changer la valeur du champ "auth". Si par exemple votre utilisateur était authentifié sous méthode LDAP et que vous voulez transférer cette prise en charge par CAS, et si son identifiant est "foobar", vous devrez éditer les données SQL par une requête ressemblant à ceci :
UPDATE mdl_user SET auth='cas' where auth='ldap' and username='foobar';
Sans cette modification, l'authentification de l'utilisateur échouerait immanquablement, même si leur profil est connu par le serveur CAS.