# Bases de données

Authentification | Utilisateurs | Mot-de-passe
--- | --- | ---
✔ | ✔ | ✔

## Présentation

### Drivers

LL::NG peut utiliser de nombreuses bases de données comme backend d'authentification, d'utilisateurs et de mots de passe :

- MySQL
- PostGreSQL
- Oracle
- …

Ainsi, tout driver Perl DBD peut être utilisé.

### Schéma

LL::NG peut utiliser deux tables :

- La table d'authentification : où les logins and et mots-de-passe sont stockés
- La table utilisateurs : où les données utilisateurs sont stockées (mail, nom, etc.)

Les tables d'authentification et utilisateurs peuvent être confondues.

Le mot-de-passe peut être stocké en clair ou encodé avec une méthode SQL standard :

- SHA
- SHA1
- MD5

#### Exemple 1 : deux tables

##### Table d'authentification

id | login | password
--- | --- | ---
0 | coudot | 1f777a6581e478499f4284e54fe2d4a4e513dfff
1 | xguimard | a15a18c8bb17e6f67886a9af1898c018b9f5a072
2 | tchemineau | 1f777a6581e478499f4284e54fe2d4a4e513dfff

##### Table utilisateurs

id | user | nom | mail
--- | --- | --- | ---
0 | coudot | Clément OUDOT | coudot@example.com
1 | tchemineau | Thomas CHEMINEAU | tchemineau@example.com
2 | xguimard | Xavier GUIMARD | xguimard@example.com

#### Example 2: single table

id | user | password | nom | mail
--- | --- | --- | --- | ---
0 | coudot | 1f777a6581e478499f4284e54fe2d4a4e513dfff | Clément OUDOT | coudot@example.com
1 | tchemineau | 1f777a6581e478499f4284e54fe2d4a4e513dfff | Thomas CHEMINEAU | tchemineau@example.com
2 | xguimard | a15a18c8bb17e6f67886a9af1898c018b9f5a072 | Xavier GUIMARD | xguimard@example.com

### SQL

LL::NG exécutera quelques requêtes SQL :

- Authentification : selectionne la ligne de la table d'authentification contenant l'utilisateur et le mot-de-passe
- Recherche de l'utilisateur : selectionne la ligne de la table utilisateurs correspondant à l'utilisateur
- Changement de mot-de-passe : met à jour le champ mot-de-passe de la table d'authentification correspondant à l'utilisateur

## Configuration

Dans le manager, aller dans `Paramètres généraux` > `Modules d'authentification` et choisir "base de données" (DBI) pour les modules authentification, utilisateurs et/ou mots-de-passe.

### Niveau d'authentification

Le niveau d'authentification accordé aux utilisateurs authentifiés par ce module.

Comme DBI est un module de type login/mot-de-passe, le niveau d'authentification peut être :

- augmenté (+1) si le portail est protégé par SSL (HTTPS)
- diminué (-1) si l'autocompletion est autorisée sur le portail (voir Personnalisation du portail)

### Variables exportées

Liste de colonnes à interroger pour trouver la session utilisateur. Voir aussi la configuration des variables exportées.

### Connexion

Les paramètres de connexion peuvent être configurés différemment pour les processus d'authentification et de recherche d'utilisateur. This allows one to use different databases for these process. Par défaut, si les paramètres de processus de connexion utilisateur sont vides , ceux d'authentification seront utilisés.

- Chaîne : chaîne DBI, contenant le nom de driver et le nom de la base de données (par exemple : dbi:mysql:database=lemonldapng;host=localhost).
- Utilisateur : compte de connexion
- Mot-de-passe : mot-de-passe du compte de connexion

### Schéma

- Table d'authentification : nom de la table d'authentification
- Table utilisateurs : nom de la table utilisateurs
- Nom du champ de compte : nom de la colonne de la table d'authentification contenant le login
- Nom du champ mot-de-passe : nom de la colonne de la table d'authentification contenant le mot-de-passe
- Nom du chmap mail : nom de la colonne de la table d'authentification contenant le mail (pour la réinitialisation du mot-de-passe)
- Nom du champ login dans la table utilisateur : nom de la colonne de la table utilisateur contenant le login

### Mot-de-passe

- Schéma de hachage : méthode SQL pour hacher les mots-de-passe. Peut être vide pour le stockage des mots-de-passe en clair.
- Dynamic hash activation: Activate dynamic hashing. With dynamic hashing, the hash scheme is recovered from the user password in the database during authentication.
- Supported non-salted schemes: List of whitespace separated hash schemes. Every hash scheme MUST match a non-salted hash function in the database. LemonLDAP::NG relies on this hashing function for computing user password hashes. These hashes MUST NOT be salted (no random data used in conjunction with the password).
- Supported salted schemes: List of whitespace separated salted hash schemes, of the form “sscheme”, where scheme MUST match a non-salted hash function in the database. LemonLDAP::NG relies on this hashing function for computing user password hashes. Salted and non-salted scheme lists are not necessarily equivalent. (for example: non-salted=“sha256” and salted=“ssha ssha512” is valid)
- Dynamic hash scheme for new passwords: LemonLDAP::NG is able to store new passwords in the database (while modifying or reinitializing the password). You can choose a salted or non salted dynamic hashed password. The value must be an element of “Supported non-salted schemes” or “Supported salted schemes”.

The SQL function MUST have hexadecimal values as input AND output
Here is an example for creating a postgreSQL SHA256 function. 1. Install postgresql-contrib. 2. Activate extension:

    CREATE EXTENSION pgcrypto;

3. Create the hash function:

    CREATE OR REPLACE FUNCTION sha256(varchar) returns text AS $$
    SELECT encode(digest(decode($1, 'hex'), 'sha256'), 'hex')
    $$ LANGUAGE SQL STRICT IMMUTABLE;