Gestion des droits¶
date: | 18 octobre 2018 |
---|
Quel composant à l’intérieur du Zéphir va gérer les droits ? Quasiment tous les messages de l’API sont impactés.
définition : ACL
Entité contenant les informations permettant de définir une autorisation (interdiction?) d’accès à une ressource.
authorization-manager : micro-service de gestion de droits
Le service authorization-manager a pour mission de fournir une API aux services de l’application Zéphir permettant de vérifier/modifier les droits d’accès des utilisateurs aux différentes ressources de l’application.
Gestion des droits au niveau de l’API-bridge¶
exemple : server.describe
: est-ce qu’on a le droit de décrire le serveur => il faut gérer le droit dans chacune des fonctions de l’API.
L’idée est plutôt de le faire au niveau de l’API-bridge.
L’inconvénient serait que les micro-services en communication interne, il n’y a plus de vérification des droits. Donc les micro-services entre eux ont tous les droits (dans l’architecture gestion des droits au niveau de l’api-bridge).
Gestion des droits en interne¶
Mettre par exemple un micro-service de gestion des groupes d’utilisateurs. Dans le Zéphir actuel il n’y a pas cette fonctionnalité là.
Il n’y a pas de notion de profil dans l’ancien zephir, il y a une grille de droits, et à chaque appel à une méthode RPC il y a une vérification de ces droits.
exemple¶
Pouvoir appairer une machine : donne accès à un groupe de fonction.
- On peut définir des droits en fonction des Sites (qui ne sont pas encore implémentés actuellement).
- notion de groupe
- l’admin peut affecter des droits à des groupes
- l’ACL autre que un profil mais comprenant des doits en lecture/écriture.
- L’abaque peut être définie complètement indépendamment des Sites.
La notion de ServerSelection¶
- sélection dynamique
- sélection statique
En fait au lieu d’ACL on peut affecter des droits à une sélection de serveurs.
Il y a deux notions de groupes
les groupes d’utilisateurs
les groupes de serveurs (comme dans l’ancien zephir, sachant qu’il peut y avoir des groupes temporaires correspondant à une sélection, et des groupes enregistrés
cas de
ServerSelection
- tous les scribe
- les scribe d’un établiessement
Note
Un utilisateur ou un groupe d’utilisateur sur une sélection de serveurs qui a un ensemble de droits
server.describe
sur le serveur 3 : dans la ServerSelection, l’utilisateur a-t-il le droit de faire cette action ?
- quel utilisateur ?
- dans quel groupe ?
- quel ACL est associé à quel groupe ?
La notion de profil, dans cette définition¶
Leycloak gère les profils. Les groupes keycloak seraient les groupes utilisateurs.
profil
un identifiant qui a un profil auquel sont associés des ACLS
groupe utilisateur == profil.
rôle
un rôle donné a telle ou telle permission sur la sélection de serveurs
ACL
tout est interdit par défaut. une ACL est forcément une autorisation.
Le modèle d’ACL¶
A quoi s’applique l’ACL ? L’ACL doit s’appliquer aux messages. Mais il faut qu’on ait des groupes d’ACL :
soit :
- un rôle est associé à plusieurs d’ACL
- une ACL peut être un droit sur un seul message (et alors une notion de groupe d’ACl est nécessaire)
deux solutions, soit :
- ACL multimessages : l’ACL peut être associée à plusieurs messages => pas besoin de notion de groupe d’ACL
- ACL affectée à un seul messages : l’ACL est alors un groupe de messages fonctionnels. Possibilité de créer son propre groupe d’ACLs avec des messages plus fins (c’est déjà présent dans l’ancien zephir). une ACL est alors unitaire (c’est-à-dire affectée à un message), et par dessus une notion de groupe
Note
on ne parle plus de message, une ACL est forcément reliée à un message
La gestion des délégation¶
délégation
rôle avec une durée de vie
A une date t
je peux affecter tous mes rôles à une autre personne, temporairement.
Questions¶
Ne sont pas encore arrêtés les choix suivants :
- Problématique de la répercussion des ACLs dans les messages internes (privés) ?
- Comment on gère les droits sur les sélections ?
Le moteur de règles¶
Server.describe
servername = toto, probe = True (si j’ai le droit d’activer les sondes)
donc il faut un moteur de règles car la granularité est supérieure
- id = 12 -> donc il faut valider si sur ce serveur l’activation des sondes est autorisé
au niveau du create, il faut une règle associée au site, sur les serveurs considérés, et suivant l’action effective associée au message.
qestion : ou est-ce que se fait la validation effective ?
- au niveau de l’api-bridge ?
- au niveau du micro-service des règles ?
Il est envisageable de créer un conteneur / micro-service ServerSelection
qui lui
sera responsable du travail sur les groupes.
Note
le cas server.list
Exécution sur une liste de serveur, l’API-bridge vérifie si on a les droits d’exécution
sur le serveur n°3, ou bien est-ce le micro-service ServerSelection
?