GateKeeper est une application owncloud dont l’objet est d’autoriser ou interdire d’accès des utilisateurs en fonction de leurs groupes.
OwnCloud permet d’associer un utilisateur à un ou plusieurs groupes. GateKeeper permet d’associer ces groupes à des listes de groupes, sortes de groupe de groupes d’utilisateurs. GateKeeper évalue l’accès d’un utilisateur en comparant ses groupes à ses listes de groupes.
Les principales listes de groupes sont la liste blanche
et la liste noire
.
-
Une liste blanche contient les groupes dont les utilisateurs peuvent utiliser les services de Owncloud.
-
Une liste noire contient les groupes dont les utilisateurs ne peuvent pas utiliser les services de Owncloud.
L’utilisation de ces listes de groupes est modulée par l’orientation, appelée mode, utilisée
-
En mode liste blanche, il suffit d’avoir un groupe dans la liste blanche pour être autorisé
-
En mode liste noire, il suffit d’avoir un groupe dans la liste noire pour être interdit
A noter que les deux listes ne sont pas utilisées en même temps , mais selon le mode sélectionné.
En effet, le besoin originel de GateKeeper est de permettre une mise en place d’un service OwnCloud en deux phases
-
phase pilote, où un nombre restreint d’utilisateurs accèdent au service, souvent avant la mise en production
-
phase de production, où un nombre restreint d’utilisateurs, pour des cas particuliers, se voient interdit l’accès au service.
Pour compléter le fonctionnement et répondre au besoin d’une exclusion nécessaire de certains utilisateurs, que ce soit en mode liste noire ou liste blanche, il existe une troisième liste de groupes, la liste d’exclusion
, que l’on peut assimiler à une liste noire qui sera toujours appliquée
De plus, du point de vue gestion des utilisateurs, les trois listes répondent à des objectifs différents
-
La liste blanche et la liste noire sont des autorisations ou interdictions simples, liées à l’offre d’un service (ouverture du service à des types d’utilisateurs, des services ou des clients)
-
la liste d’exclusion est une gestion des interdictions plus radicale et parfois irrévocable (usurpation d’identité, violation des CGU, etc…)
Cela vous permet de moduler votre gestion car ces listes sont des listes de groupes. Vous pouvez donner une signification à vos groupes pour vous assister dans votre gestion.
Voici un exemple de composition
-
Liste blanche
-
groupe "utilisateurs recette"
-
groupe "utilisateurs test"
-
groupe "site pilote 1"
-
groupe "site pilote 2"
-
-
Liste noire
-
groupe "En attente de validation"
-
groupe "en cours de provisionning"
-
-
Liste d’exclusion
-
groupe "usurpation d’identité"
-
groupe "violation des CGU"
-
groupe "activités illégales"
-
GateKeeper peut alors fonctionner selon trois [mode]s principaux
-
mode liste blanche,
-
mode liste noire,
-
mode minimal,
-
mode porte ouverte.
-
Si un groupe de l’utilisateur appartient à la liste d’exclusions alors l’accès est refusé
-
Si au moins un groupe de l’utilisateur appartient à la liste blanche alors l’accès est accordé
-
Sinon l’accès est refusé
-
Si un groupe de l’utilisateur appartient à la liste d’exclusions alors l’accès est refusé
-
Si au moins un groupe de l’utilisateur appartient à la liste noire alors l’accès est refusé
-
Sinon l’accès est accordé
-
Si un groupe de l’utilisateur appartient à la liste d’exclusions alors l’accès est refusé
-
Sinon l’accès est accordé
GateKeeper repose sur
-
Un service
OCA\GateKeeper\Service\GateKeeperService
en charge de la logique générale -
Un intercepteur
OCA\GateKeeper\AppInfo\Interceptor
qui intercepte toute requête et et demande au service d’évaluer la situation -
de hooks
OCA\GateKeeper\Hook\gateKeeperHooks
qui prend en charge le balisage, à travers des flags, de l’évaluation de la situation
Les principales méthodes de ce service sont
. GateKeeperService::checkUserAllowances(OC\User\User $user)
. GateKeeperService::isUserAllowed(OC\User\User $user)
La logique de checkUserAllowances
est la suivante
-
vérifier dans la session si il y a lieu de procéder à une évaluation avec
isUserAllowed
-
si oui
-
évaluer la situation
-
stocker en session le résultat
-
-
si non
-
returner le résultat de la précédente évaluation
-
Le flag de session est positionné par les méthodes
-
startCycle($uid)
-
endCycle()
La méthode isUserAllowed
procède de la façon suivante
-
Elle parcourt la liste des groupes d’un utilisateur
-
si il existe un groupe marqué liste blanche et que GateKeeper est en mode liste blanche, alors l’accès est accordé
-
si il existe un groupe marqué liste noire et que GateKeeper est en mode liste noire, alors l’accès est refusé
-
si finalement aucun groupe n’est marqué, et que gateKeeper est en mode liste noire, alors l’accès est refusé
-
sinon il est accordé
Dans le cas des accès des clients de synchronisation, les ré-évaluations sont espacées en utilisant un timer ( cf. hasToRefresh)
La méthode hasToRefresh
évalue si il y a lieu de procéder à une évaluation de la situation en appelant isUserAllowed
-
Elle positionne un timer
-
en deça d’un certain délai (variable delay) elle estime que la précédente évaluation est encore valable
-
au dessus, elle réinitialise le timer et estime qu’une nouvelle évaluation est nécessaire.
La logique de l’intercepteur est très simple :
-
Pour chaque requête HTTP
-
Si l’utilisateur est identifé et connecté OU si il s’agit d’une requête d’un client de synchronisation (mode remote.php )
-
Demander au GateKeeperService une évaluation de l’utilisateur
-
Si l’évaluation est négative
-
Déconnecter de force l’utilisateur (logout)
-
Afficher un message en mode Web OU envoyer une exception en mode remote
-
Les Hooks font appels aux méthodes de balisage de GateKeeperService à certains évènements
-
sur preLogin, appele startCycle($uid)
-
sur logout, appele endCycle()
L’administration des autorisations se fait en trois étapes
Dans l’écran d’administration, choisir un mode
Pour plus de détails, cf Détail des évaluations selon les modes
Au bout du delai indiqué en seconde, toute nouvelle requête donne lieu à une réévaluation.
Une valeur nulle, 0 ou négative signifie à la prochaine authentification.
Il est possible d’historiser les refus.
Trois possibilités :
Dans l’écran d’administration, cliquer sur l’onglet du mode sélectionné
Entrer le nom d’un groupe (il n’y a pas de vérification de l’existence du groupe) et ajouter
Nous recommandons par conventions de créer au moins trois groupes d’utilisateurs
-
interdits qui sera le groupe des utilisateurs interdits d’accès
-
autorisés qui sera le groupe des utilisateurs autorisés
-
exclus qui sera le groupe des utilisateurs exclus
Ensuite ajouter ces groupes dans les listes de groupes idoines . interdits dans liste noire . autorisés dans liste blanche . exclus dans liste d’exclusion
-
Passer en mode liste blanche
-
Ajouter le groupe testeurs à la liste blanche
-
Ajouter dans l’écran de gestion des utilisateurs tous les utilisateurs autorisé à testeurs
-
Passer en mode liste noire
-
Ajouter le groupe attente_feu_vert_dircom à la liste noire
-
Ajouter dans l’écran de gestion des utilisateurs tous les utilisateurs bloqués à attente_feu_vert_dircom
Dans certains cas, il est plus facile de gérer des classes d’utilisateurs que des utilisateurs individuelles.
-
Faite en sorte que cette classe soit associée à un groupe ( utilisation d’applications de provisionning.[1] )
-
Associez le groupe à une liste (blanche ou noire)
-
Passez dans le mode recherché
Un utilisateur doit être bloqué
Si le cas est une étape de vos procédures (adhésion, attente validation)
-
En mode liste blanche, retirez le de tous les groupes autorisés
-
En mode liste noire, ajoutez le dans le groupe attente_feu_vert_dircom
Si le cas est un cas plus exceptionnel (vol de portable, défaillance, usurpation, …)
-
Quelque soit le mode (sauf mode ouvert) ajoutez le à un groupe de la liste d’exclusion