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 ?