Systèmes d’identification intégrés à OAuthSD

, par B. Degoy

Il s’agit d’identifier une personne, pourquoi alors choisir un masque comme logo de cet article ? C’est parce que la plupart des techniques n’identifient pas une personne avec certitude, sauf quand on utilise des procédés biométriques : de la même manière que l’on peut reconnaître une personne masquée par ses yeux. C’est aussi parce que l’enjeu est de démasquer les intrus.

Les systèmes d’identification intégrés au serveur offrent une sécurité maximale puisqu’ils sont sanctuarisés dans l’espace physique de l’organisation.

Les fenêtres de dialogue nécessaires à l’identification sont produites par le serveur et exécutées dans son environnement : le navigateur de l’utilisateur final a été redirigé vers le domaine du serveur.

OAuthSD offre différentes méthodes d’identification est peut facilement en intégrer de nouvelles grâce à son organisation modulaire.

Identification classique : login/Mot de passe

La méthode se passe de commentaire. Si ce n’est pour dire qu’il faut absolument l’éviter, ainsi que toutes ses semblables exigeant l’entrée au clavier d’un code quelconque, fut-il éphémère !

Goshtkeys : clavier fantôme

Cette méthode affiche une grille dans laquelle l’utilisateur devra cliquer sur des chiffres disposés de façon aléatoire à chaque affichage du formulaire de connexion.
Cette méthode offre de grands avantages de sécurité :
– le mot de passe est matérialisé sous une forme codée et variable, ce qui interdit sa réutilisation en cas d’interception,
– les robots seront éliminés, ce formulaire étant équivalent à un Captcha.

Après l’identification

Après identification, il est possible d’effectuer une Validation en 2 étapes (Two Factor Authentication, 2FA) .

Enfin, le consentement de l’utilisateur pour l’accès de l’application à ses données personnelles est demandé comme nécessaire :

P.-S.

[DR] Implémentation des méthodes d’identification dans le serveur OAuthSD

OAuthSD distingue les fournisseurs d’identité primaire et, si l’identification à deux facteurs (2FA) est activée, les secondaires. Les constantes de configuration IDENTITY_PROVIDER et TFA_PROVIDER permettent de définir quel seront les systèmes utilisés.

Constantes de configuration
Le fichier /commons/configure_oidc.php permet de configurer les méthodes d’identification :

<?php

/** [dnc10]
Que faire si prompt n'est pas défini (ou Null) et que l'utilisateur n'est pas connecté?
*/
define ('REAUTHENTICATE_NO_ROUNDTRIP', true); // True pour que le serveur gère la réauthentification. false est conforme à la norme.

/** Fournisseur d'identité primaire (formulaire de connexion ...).
* Le fournisseur d'identité est la première étape si TFA est activé.
* OAuthSD offre nativement 'ghostkeys', 'password' ...
* [dnc91] Peut être remplacé par le champ identity_provider de la table des clients.
*/
define ('IDENTITY_PROVIDER', 'password');

/** Options de connexion / mot de passe */
define ('PSWD_LENGTH', 9); // longueur exacte du mot de passe
define ('LOGIN_MIN_LENGTH', 5); // login min longueur
define ('FORCE_EMAIL', FALSE); // Si TRUE, la connexion devrait être une adresse électronique. Si FALSE, la connexion peut être un pseudo ou un email.

/** [dnc10] Que faire si une invite == login et que l'utilisateur n'est pas connecté (le jeton d'accès a expiré)?
* Spec a dit que nous devrions retourner au client avec une erreur.
* Il est plus sûr et meilleur (pas d'aller-retour) de gérer la situation sur le serveur.
*/
define ('LOGIN_NO_ROUNDTRIP', true); // True pour que le serveur gère la réauthentification. false est conforme à la norme.

/** En cas de répétition de la connexion au serveur, combien d'essais sont autorisés pour l'utilisateur final? */
define ('ALLOWED_ATTEMPTS', 5);

/** [dnc43] Authentification à deux facteurs (fournisseur d'identité secondaire).
* Un TFA peut être présenté à l'utilisateur final si le champ d'application "tfa" est présent dans la demande d'autorisation.
* Si ce paramètre est défini sur true, le fichier TFA sera toujours présenté à l'utilisateur final après le formulaire de connexion.
*/
define ('LOGIN_WITH_TFA', false);
/** [dnc43] Fournisseur d'identité secondaire. Désigner quel fournisseur sera utilisé pour le TFA.
* Entrez le nom du répertoire dans / oidc / identification / où se trouve le TFA souhaité.
*/
define ('TFA_PROVIDER', 'checkbysms'); // Un parmi 'gangsta', 'checkbysms', ... (rien d'autre pour l'instant).
/** Nom du serveur à passer à getQRCodeGoogleUrl.
* Sera affiché sous le QR-Code.
*/
define ('TFA_VISIBLE_APPNAME', 'Serveur OAuthSD');


/** [dnc9] Si SLI échoue, devons-nous revenir au client?*/
define ('LOGIN_AFTER_SLI_FAILS', true); // le contrôleur authorize est responsable de l'invite à nouveau.

Méthode imposée par l’application
...

Délégation de l’identification, déclaration privées

...