Savez vous qu’un administrateur K2 peut contrôler l’accès à des objets K2 (catégorie, formulaire, vue et smartobject) et des entités (utilisateur, groupe et rôle) en configurant des permissions (Allow et Deny) sur des droits (voir, exécuter, modifier et supprimer) ❓
Eh bien, Authorization Framework est une fonctionnalité des nouvelles versions K2 Five et Cloud, qui permet de faire cela. D’où l’object de notre article.
1- Briefing sur K2 Authorization Framework
L’ authorisation Framework se résume à la gestion des Rôles , la gestion des accès aux Objects K2, l’audit de sécurité:
- Un Rôle peut contenir des utilisateurs et des groupes d’utilisateur: Par défaut dans le K2 management on a 3 rôles système créer durant l’installation de K2. Ils ne peuvent pas être supprimés. Vous pouvez ajouter un rôle selon vos besoins. Dans le management -> Rôle -> Security, vous pouvez décider qui peut supprimer ou Modifier un rôle.
- La gestion des droits d’accès sur les objets K2 détermine qui peut voir, exécuter, modifier ou supprimer un objet K2 (catégorie, formulaire, vue et smartobject).
- L’audit de sécurité se fait grâce au SmartObject Security Audit: II permet à un membre du rôle Security Administrators d’exécuter le SmartObject et de générer un journal d’audit de tous les changements de sécurité dans votre environnement K2.
Pour plus de détails sur Authorization Framework, cliquer sur ce lien
2- Cas Pratique
Dans une entreprise par exemple on a plusieurs applications k2 classés par catégorie/département . On aimerait créer des rôles (en fonction des départements de l’entreprise: IT , RH …). Afin que chaque utilisateur n’a le droit d’accéder qu’à la catégorie de son département, ceci uniquement en lecture/exécution. Ensuite, un Rôle Admin par département qui aura tous les droits sur la catégorie du département (voir, exécuter, modifier et supprimer).
2-1- Création des rôles
Aller dans K2 management -> Users -> Roles -> New -> entrer le Nom du Rôle -> Ajouter des Users /Groupes -> Valider votre choix -> Ok
Note: En bas de Find users vous avez les différents critères de recherches
Faites de même pour tout les rôles à créer y compris les Rôles Admin des différents départements.
Les rôles étant créés vous pouvez modifier la sécurité: Qui peut supprimer ou Modifier les rôles ou encore donner la permission à un autre utilisateur d’attribuer les droits sur ce rôle (Voir point 4 -> Security).
Pour modifier les droits: Sélectionner le Rôle -> Security comme indiquer sur l’image ci dessous. Click sur Everyone -> Break Inheritance qui se changera en Inherit Permissions. Supprimer le rôle Everyone, ou bien mettre tout ses permissions à None (ça n’apparaitra plus plu tard) : Afin d’empêcher les droits à n’importe quel utilisateur sur le Rôle IT.
Donc , pour l’instant seul les membres du rôle Security Administrators ont touts les droits sur ce rôle.
Ensuite cliquer sur Add (+) pour vous ajouter afin de vous attribuer les droits.
Note: En cas d’imbrication des permissions, le Deny remporte c’est pourquoi, pour le rôle Everyone, on met à none ou on le supprime. Pareil pour le gestion des permissions sur les catégories. Mais ceci n’est pas le cas pour le groupe système Security Administrators : ils ont toujours toutes les permissions et pas moyen de les attribuer ou modifier une permission.
Exemple d’imbrication de permission: On fait des configurations suivantes :
- Everyone (l’utilisateur Eric est dans le groupe) => Modify : Deny
- Ajout de l’utilisateur Eric => Modify : Allow
Résultat : Eric n’aura pas accès en modification
2-2- Assignation des droits sur les catégories
1- Présentation
Les configurations sont les suivantes:
- Rôle IT -> Accès Catégorie IT (voir, exécuter)
- Rôle RH -> Accès Catégorie RH (voir, exécuter)
- Rôle IT Admin -> Accès Catégorie IT (voir, exécuter, modifier et supprimer)
- Rôle RH Admin -> Accès Catégorie IT (voir, exécuter, modifier et supprimer)
La suite des configurations, va se faire uniquement avec les Rôle IT, IT Admin sur la catégorie IT, et pour les autres, vous aller faire pareil.
2- Assignations des permissions sur la catégorie IT
Aller dans K2 Management -> Catégorie -> IT -> Security -> Everyone -> Break Inheritance -> supprimer le rôle Everyone (Afin d’empêcher n’importe quel utilisateur d’accéder à la catégorie IT)
Note: On clique sur Break Inheritance afin d’interdire à la catégorie hériter des permissions de la catégorie parent.
Ajout des Permissions du Rôle IT: Rechercher et ajouter le rôle IT
Les membres du rôle IT ont juste les permissions de voir et d’exécuter.
Ajouter les permissions du Rôle IT Admin (voir, exécuter, modifier et supprimer) comme dans cet image:
Note: Security permet de décider si voulez autoriser un user/Group/Rôle à attribuer les droits sur cette catégorie.
Et bien les configurations sont terminées nous allons tester.
2-3- Tests
Ici, il est question de tester l’accès à la catégorie IT et à ses sous éléments. Pour cela, nous avons prévu trois utilisateurs pour les différents rôles
- Amélie => IT Admin
- Yannick => IT
- Durant = > RH
A présent se connecter avec les trois users tour à tour et essayer d’accéder à la catégorie IT (et ses sous éléments) via Designer, Runtime,Management et Workspace (Dans cet article, les formulaires de nos applications de test ne sont pas intégrer dans le workspace, donc on ne fera pas ce test. Par ailleur la customisation du Workspace fera l’objet d’un prochain article de blog). Comme résultat on a :
- Amélie a touts les droits: (voir, exécuter, modifier et supprimer)
- Yannick a le droit de lecture et d’exécution uniquement
- Durant: n’a accès à rien et la catégorie IT ne s’affiche pas dans sa session
C’est tout pour cet article j’espère que vous êtes à présent prêt à sécuriser son application K2 🙂 .
A plus 😉
Lien consultés pour réaliser cet article :
- https://help.nintex.com/en-US/k2cloud/userguide/Update_14/content/AuthorizationFramework/Authorization-Framework-Overview.htm#Rights
- https://help.nintex.com/en-US/k2five/userguide/5.0/default.htm#K2_Management_Site/User_Management/Roles.htm
- https://www.enk2besoin.com/2017/11/07/k2-five/
- https://www.enk2besoin.com/2017/12/12/k2-five-authorization-framework/