$pgservice_core="ged"; $pgservice_freedom="ged";; $freedom_context="default"; $dbpsql=$pgservice_core; $freedom_authtype = 'html'; $freedom_authtypeparams = array( 'html' => array ( 'cookie' => 'freedom_auth', 'authurl' => 'guest.php?sole=A&app=AUTHENT&action=LOGINFORM', 'username' => 'auth_user', 'password' => 'auth_pass', ), 'open' => array(), 'basic' => array( 'realm' => 'freedom', ), ); $freedom_authprovider = 'freedom'; $freedom_providers = array( 'freedom' => array( 'connection' => 'service='.$pgservice_core, ), 'file' => array( 'authfile' => '/var/www/ged/.freedompwd', ), );
$freedom_authtype | Le mode de l'interface utilisateur d'authentification. Le paramètre peut prendre les valaurs : apache, basic, html ou open. |
$freedom_authprovider | Ce paramètre spécifie le, ou les, backend d'authentification à utiliser pour valider les mot de passes. Par défaut Dynacase-platform est livré avec les backend suivants : freedom, ldap et file. |
Ce paramètre permet de spécifier quelle interface d'authentification est utilisé pour demander les informations de connexion à l'utilisateur (login/password la plupart du temps) et lui transmettre le résultat de l'authentification.
Ce mode spécifie que toute la mécanique d'authentification est délégué à Apache en mode HTTP Basic. Dynacase-platform ne s'occupe pas d'authentifier les utilisateurs, et Apache lui fournit les utilisateurs qui viennent de se connecter via la variable PHP $_SERVER['PHP_AUTH_USER'].
Dans ce mode, le paramètre $freedom_authprovider n'est pas utilisé puisque c'est Apache qui gère toute l'authentification.
Le mode basic permet à Dynacase-platform de fournir un mécanisme d'authentification HTTP Basic.
Dans ce mode, Dynacase-platform gère l'authentification au format HTTP Basic et l'utilisateur rentre son login et son mot de passe dans la boite de dialogue affiché par le navigateur.
Paramètres :
realm | Le realm de l'authentification HTTP Basic. |
Le mode html présente un formulaire HTML pour demander le login et le mot de passe de l'utilisateur. Une fois le login et le mot de passe validé auprès du freedom_authprovider, une session par cookie est ouverte afin de valider les accès suivants.
Paramètres :
cookie | Le nom du cookie contenant la clef associé à la session de l'utilisateur. |
authurl | L'URI d'accès au formulaire de login. |
username | L'id du champ input HTML contenant le nom d'utilisateur. |
password | L'id du champ input HTML contenant le mot de passe de l'utilisateur. |
Le mode open ne présente aucune interface pour la saisie du login et du mot de passe, mais se base sur un jeton présent dans l'URI.
Dans ce mode, le paramètre $freedom_authprovider n'est pas utilisé.
Le jeton est contenu dans la variable `privateid'.
Exemple d'URI avec authentification `open' et jeton :
L'action `BAR' de l'application `FOO' doit être déclarée `openaccess=Y' pour pouvoir être accessible avec cette authentification par jetons.
Le jeton doit êtres présent dans la table `usertoken' qui stocke les jetons, avec l'utilisateur associé au jeton et une date d'expiration du jeton.
Voir Class.UserToken.php.
Le paramètre $freedom_authprovider permet de spécifier le sous-mécanisme utilisé pour la validation du login et du mot de passe.
Ces providers prennent en entrée un login et un mot de passe, et retourne s'ils sont valide ou non.
Chaque provider contient un ensemble de paramètres de configuration qui lui sont propre.
Le provider freedom est le mécanisme historique de Dynacase-platform qui utilise la base Postgres et la table user pour la validation des login et mots de passe.
On parlera dans ce cas d'authentification « interne », puisqu'elle ne se base sur aucun élément externe à Dynacase-platform.
Paramètres :
connection | Contient la chaîne de connexion à la base de donnée Postgresql contenant la table user. Exemple : service=freedom |
Le provider ldap permet de valider le login et le mot de passe auprès d'un serveur LDAP, ou d'un serveur Active Directory, en effectuant un « bind LDAP » auprès de celui-ci.
Ce provider supporte une création basique d'utilisateurs « à la volé ». Dans ce cas, si l'authentification du est validé auprès du LDAP mais qu'il n'y a pas de compte utilisateur Dynacase-platform correspondant a ce login, alors le provider peut créer un compte utilisateur Dynacase-platform (IUSER) avec ce login. Cela permet de pouvoir « peupler » dynamiquement la base des comptes utilisateurs Dynacase-platform au fur et à mesure que les personnes se connectent. Le paramètre `dGroup' permet de spécifier le nom logique, ou l'id, du groupe Dynacase-platform (IGROUP) dans lequel seront créé ces nouveaux utilisateurs Dynacase-platform.
Paramètres :
host | Le nom, ou l'adresse IP, du serveur LDAP. |
port | Le port du serveur LDAP. |
ssl | y pour utiliser une connexion SSL au serveur LDAP, n pour ne pas utiliser de connexion SSL. |
options | Options de la librairie OpenLDAP pour la connexion au serveur LDAP. |
dn | Le DN de connexion utilisé pour valider le mot de passe de l'utilisateur. La chaine %s est remplacé par le login, et le mot de passe fournit par l'utilisateur est utilisé pour effectué un bind avec le DN ainsi construit. |
dGroup | Le nom logique du groupe Dynacase-platform sous lequel seront créés les utilisateurs. Voir |
allowAutoFreedomUserCreation | yes pour activer la création des comptes utilisateurs par le provider, no dans le cas contraire (par défaut no). |
Le provider file permet de valider un couple de login/mot de passe auprès d'un fichier à plat au format htpasswd Basic d'Apache.
Ce provider ne supporte pas la création d'utilisateurs « à la volé ».
Paramètres :
authfile | Le chemin d'accès au fichier à plat de mot de passe au format htpasswd. |
Le provider freedomNu est fourni par l'application `freedom-networkuser', et permet de valider le login et le mot de passe auprès d'un serveur LDAP ou d'un serveur Active Directory.
Ce provider supporte la création d'utilisateurs « à la volé ». Dans ce cas, si l'authentification est validé auprès du LDAP mais qu'il n'y a pas de compte utilisateur Dynacase-platform correspondant a ce login, alors le provider peut créer un compte utilisateur Dynacase-platform (LDAPUSER) avec ce login. Cela permet de pouvoir « peupler » dynamiquement la base des comptes utilisateurs Dynacase-platform au fur et à mesure que les personnes se connectent.
Paramètres :
Voir documentation paramètres de networkuser
Les paramètres de connexion au LDAP/AD sont pris dans les paramètres applicatifs de l'application Dynacase-platform `NU' (voir documentation configuration Dynacase-platform de networkuser).
Un provider doit implémenter les méthodes définies dans la classe WHAT/Class.Provider.php
Les méthodes à implémenter obligatoirement sont :
abstract function validateCredential($username, $password)abstract function validateAuthorization($opt)Les méthodes optionnelles sont :
public function __construct($authprovider, $parms)public function initializeUser($username)Cette méthode prend en entrée deux arguments qui sont :
$username : le login entré par l'utilisateur$password : le mot de passe entré par l'utilisateur.La méthode doit retourner :
true si le couple login/mot de passe est correctfalse si le couple login/mot de passe est incorrect.Une fois le couple login/password est validé, cette méthode permet de contrôler si l'utilisateur est autorisé à se connecter.
Cette méthode prend entrée un argument :
$opt : une structure contenant le nom de l'utilisateur.$opt = array( 'username' => $username );
La méthode retourne :
true si l'utilisateur est autorisé à se connecterfalse dans le cas contraire.C'est le constructeur du Provider que l'on peut étendre si celui-ci nécessite une initialisation particulière.
Cette méthode prend en entrée deux arguments qui sont :
$authprovider :$parms :Si le compte de l'utilisateur n'existe pas dans Dynacase-platform, cette méthode est utilisé pour créer le compte de l'utilisateur dans Dynacase-platform.
Cette méthode prend en entrée le login de l'utilisateur :
$username : le login de l'utilisateur.La méthode retourne :
”” : une chaîne vide s'il n'y a pas eu d'erreur à la création du compte.“Error message …” : une chaîne non vide contenant le message d'erreur rencontré.Cette méthode spécifique implémente la recherche des informations de l'utilisateur à partir du login sur le système d'authentification utilisé, et la création du compte utilisateur Dynacase-platform avec les informations obtenus.
Dans l'exemple ci-dessous, nous allons écrire un provider pour valider les mots de passe des utilisateurs auprès d'un service PAM à l'aide de la commande checkpassword-pam. Ce module ne supportera pas la création d'utilisateurs à la volée.
On va déclarer dans le `dbaccess.php' que l'on utilise en premier notre provider `pam', et ensuite le provider `freedom' si l'utilisateur n'est pas reconnu par `pam'.
Notre provider `pam' aura un paramètre nommé ”service” qui contiendra le nom du service PAM auprès duquel seront validé les login et mot de passe (c'est le nom du fichier situé dans `/etc/pam.d').
[...] $freedom_authprovider = 'pam,freedom'; $freedom_providers = array( [...] 'pam' => array( 'service' => 'freedom' ) ); [...]
Notre provider est donc décrit dans le fichier `Class.pamProvider.php' situé dans le sous-répertoire `WHAT/providers' de l'installation Dynacase-platform.
Celui-ci fournit une classe `pamProvider' qui étend la classe `Provider', et nous allons décrire nos méthodes spécifiques `validateCredential()' et `validateAuthorization()'.
Dans `validateCredential() nous allons récupérer le paramètre `service' de notre provider, et utiliser la commande `checkpassword-pam' pour valider le username et le password reçu.
Pour simplifier l'exemple, la méthode `validateAuthorization()' retournera `true' systématiquement (on supposera que l'autorisation du compte est établi dans la phase de validation du mot de passe).
<?php include_once('WHAT/Class.Provider.php'); Class pamProvider extends Provider { public function validateCredential($username, $password) { $service = 'freedom'; if( array_key_exists('service', $this->parms) ) { $service = $this->parms{'service'}; } return $this->checkpassword_pam($username, $password, $service); } public function validateAuthorization($opt) { $username = $opt{'username'}; return true; } public function checkpassword_pam($username, $password, $service) { $cmd = sprintf("checkpassword-pam --service %s --no-chdir-home --noenv", escapeshellarg($service) ); $proc = proc_open($cmd, array(3=>array('pipe', 'r')), $pipes); if( ! is_resource($proc) ) { error_log(__CLASS__."::".__FUNCTION__." ". sprintf("Error running checkpassword-pam") ); return false; } fwrite($pipes[3], sprintf("%s\0%s\0timestamp\0", $username, $password )); fclose($pipes[3]); $ret = proc_close($proc); if( $ret === 0 ) { return true; } error_log(__CLASS__."::".__FUNCTION__." ". sprintf("Authentication failed for user '%s' and service '%s'.", $username, $service ) ); return false; } } ?>
Pour finir, le fichier associé au paramètre ”service” de notre provider. Celui-ci contiendra les règles que l'on souhaite voir appliqué pour la validation des comptes. Dans cet exemple, on utilisera une authentification des comptes sur la base locale des utilisateurs Unix du serveur.
# auth sufficient pam_securityserver.so # uncomment for OS X auth sufficient pam_unix.so auth required pam_deny.so account required pam_permit.so session required pam_permit.so