Roles & permissions

[psouquet]

L'accès aux ressources et actions doivent être restreintes dans Cockpit. Notamment pour limiter les diverses administrations (techniques et métier) aux personnes responsables, d'autre part pour protéger les données sensibles (production par exemple). Pour ce faire (et afin de décider quelle implémentation est la plus pertinente) nous allons commencer par lister les différentes permissions à accorder ainsi que les roles qui grouperont ces permissions. Par la suite, les permissions et rôles pourront être associés puis affinés (assemblés, divisés ou modifiés) en un système satisfaisant.

Les permissions ne font pas uniquement références aux fonctionnalités existantes ou spécifiés, mais aussi aux fonctionnalités à venir. Ces dernières sont, de fait, mal définies. Il faudra accepter de prendre des décisions (concernant les rôles et permissions) basés sur l'intention de ces fonctionnalités sans digresser et entrer trop dans le détail.

Il faut noter aussi, qu'à priori les rôles pourront être attribués a un couple (utilisateur + workspace) afin d'offrir une granularité suffisante. Par exemple, les rôles généraux comme administrateur cockpit seraient directement liés à un utilisateur tandis que des rôles contextuels comme administrateur workspace seraient liés à un utilisateur et un workspace. Un même utilisateur pourra donc avoir un même rôle sur différent workspaces et ne pas l'avoir sur d'autres.

Permissions:

liste des permissions

• administration cockpit ajouter supprimer utilisateurs de cockpit. attribution du rôle administrateur cockpit?
• administration workspace ajouter supprimer utilisateurs d'un workspace, attribution de rôle liés au workspace ? edition de description et short description du workspace.
• accès workspace permission de se connecter à (charger) un workspace
• créer un workspace
• attacher/détacher un bus d'un workspace
• attacher/détacher un conteneur d'un bus
• deploy, undeploy d'un artefact jbi + paramètres deploy, undeploy un artefact jbi (Composant, SA, SL). Modification des paramètres des artefacts (à chaud ou au déploiement).
• gestion cycle de vie d'un artefact jbi start, stop, shutdown... un artefact jbi (Composant, SA, SL).
• modification du niveau de log d'un artefact ou d'un container.
• édition de modèle sans considérer la manière dont la fonctionnalité sera intégrée à l'interface: modification d'un modèle logique déjà présent dans cockpit
• déployer un modèle appliquer un modèle logique à une topologie (déploiement physique)
• administration flux le détail de ce qu'est un flux (ou service, flow, process) reste à définir. Cette feature concerne principalement le contrôle et le rejeu de processus métier (spécifiques à des SE type flowable)
• visualisation/recherche des traces monit

remarques

L'accès aux différentes vues d'un workspace (topologie, services, api, modèle?, monitoring?) ne fait pas partie des permissions, il n'est pas limité en soi. Une fois que l'on a accès au workspace on a accès à ces vues. (les actions ou ressources proposés par ces vues peuvent cependant être limités)
Edit: split de la permission cycle de vie jbi en deux permissions ( "deploy/undeploy/permission" et "cycle de vie")

Rôles

liste des rôles

• développeur en charge de développer les SU/SA
• architecte en charge de définir les topologies
• service déploiement ayant en charge le déploiement et l'administration des logiciels 'Petals' (Petals ESB avec SL, BC/SE et SU/SA, Petals-Cockpit, ...)
• service hosting ayant en charge et la supervision technique de l'infrastructure sur laquelle tourne le bus (et produits petals).
• administrateur métier en charge de superviser une partie fonctionnelle de bus
• administrateur workspace (chef de projet)
• administrateur cockpit administrateur technique de cockpit

remarques

Dans un premier temps, les rôles reprennent les utilisateurs cible de cockpit en y ajoutant deux profils d'administration.
Edit: Precision de exploitant/opérateur de production en deux rôles: service déploiement et service hosting.

[psouquet]

Après quelques reflections, créer un workspace et visualiser un workspace ne relèvent pas vraiment de permissions. A moins de changer profondément le fonctionnement actuel de cockpit (ce qui est, bien sûr, envisageable).

• Actuellement: Il faut ajouter un utilisateur à aux membres d'un workspace pour qu'il puisse le visualiser, rendant la permission associée redondante (ou antinomique si on la retire).
• Actuellement: tout le monde à le droit de créer un workspace, les bus étant protégés par le mot de passe du conteneur et la passphrase de la topologie. Protéger la création de workspace revient à créer un rôle uniquement pour cela. Ce qui peut faire sens, mais alourdit probablement le quotidien d'administrateurs cockpits. Quelqu'un qui possède le mot de passe d'un conteneur pourra s'y connecter avec ou sans cockpit...

En prenant cela en considération. Voici un premier jet d'attribution de permissions :

perm/role	admin cpt	admin wksp	dev	archi	deploy	hosting	admin métier
admin globale	✔
admin wksp	✔	✔
att/det bus		✔			✔
att/det cont		✔			✔
lifecycle art		✔	✔		✔	✔
deploy/param art		✔	✔		✔
niveau logs		✔	✔		✔		✔
edit modèle		✔		✔
deploy modèle		✔			✔
admin flux		✔		✔			✔
traces monit		✔	✔		✔		✔

Remarques:

• admin cpt est le seul rôle global il est attribué à un utilisateur, tous les autres rôles sont attribués à un utlisateur sur un workspace uniquement
• la permission d'administrer un wokspace est accordée aux administrateurs cockpit pour TOUS les workspaces existants, mais au administrateurs workspace uniquement sur le workspace sur lequel ils sont admin.
• on considére que l'admin workspace dispose, de base, de toutes les permissions (afin de ne pas avoir à s'attribuer les permissions sytématiquement lors de POCs ou tests).
• Edit pour refléter les changements apportés à lifecycle artifact jbi, et opérateur production