K2 Five – Authorization Framework

Ce billet fait partie d’une série de billets sur les nouveautés des versions Five et Cloud, mises à disposition en octobre 2017.

Il y a un peu plus d’un an la console d’administration de K2 entamait sa mue. Aujourd’hui, si on remarque que le site s’est paré d’une couleur plus claire, les fonctionnalités que vous connaissiez sont toujours là. Cependant, quelques nouveautés font leur apparition et nous allons les aborder dans ce billet.

Un administrateur 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). Il est possible ainsi de restreindre l’usage des concepteurs et des utilisateurs de la plateforme. Par exemple, l’Authorization Framework permet de séparer deux groupes de concepteurs venant de deux services différents.

Les puristes feront la (bonne) remarque qu’il est possible de gérer des permissions sur les smartobject depuis plusieurs années. L’Authorization Framework mérite quand même son article sur notre blog.

Authorization Framework
Les permissions s’appliquent via deux dimensions : Utilisateurs ou Objets

Au sommaire :

  • En théorie
  • En pratique

En théorie

L’Authorization Framework impacte l’usage de l’utilisateur sur les éléments suivants :

  • K2 Management, en particulier la partie Category.
  • K2 Designer, pour catégories, formulaires, vues et smartobjects.
  • K2 Runtime, c’est à dire l’accès aux formulaires (via leurs url, le K2 Workspace et l’application mobile).
  • K2 Service Tester, donc les smartobjects.

Nous n’avons pas encore parlé des Rôles K2 sur enK2besoin, alors pour les décrire simplement, sachez qu’un rôle est un ensemble d’utilisateurs et/ou de groupes provenant des annuaires connectés à la plateforme. Par exemple, le Rôle « Admin K2 » peut contenir 2 utilisateurs de l’AAD et 1 groupe de l’AD.

Par défaut, K2 propose des rôles Security Administrators et Everyone. Le premier permet de définir les super administrateurs qui auront toujours le droit de gérer les permissions. Le deuxième contient tous les utilisateurs de tous les annuaires connectés à K2.

La plateforme permet la gestion de quatre droits :

  • Les deux premiers, concernent les rôles
    • modify pour la modification des membres d’un rôle
    • delete pour la suppression du rôle
  • les deux derniers, s’appliquent aux objets
    • view pour l’affichage et l’usage des Categories, Forms, Views et Smartobjects
    • execute pour l’usage des Forms (uniquement)

Et K2 propose trois permissions :

  • Deny (interdit l’accès),
  • None (accès nul, qui hérite, voir ci-après), attribuée au rôle Everyone,
  • Allow (autorise l’accès). Attribuée au rôle Security Administrators.

Ces permissions sont héritées dans toutes les arborescences Role > Groupe > User et Catégorie > Sous-catégorie > Object K2. Ainsi, tous les membres d’un groupe héritent des permissions du groupe et tous les formulaires, vues et smartobjects héritent des permissions de la catégorie qui les contient.

L’héritage des permissions est précisé par deux permissions supplémentaires :

  • Inherited deny (si le père est deny ou inherited deny)
  • Inherited allow (si le père est allow ou inherited allow)

Evidemment, il est possible de casser cet héritage.

Authorization Framework
Un exemple d’héritage cassé

 Si Deny et Allow sont appliqués au même élément, Deny l’emporte.

Quelques recommandations des équipes EnK2Besoin :

  1. Planifiez avant, configurez après.
  2. Travaillez d’abord en Dev, puis appliquez à la Prod.
  3. Favoriser l’usage des groupes et rôles, plutôt que celui des utilisateurs.
  4. Keep it simple, attribuez des permissions à des catégories plutôt qu’à des objets K2.

En pratique

Prenons le temps de voir ensemble un cas d’usage de l’Authorization Framework dans un contexte pertinent. Deux applications sont respectivement gérées par deux départements d’une entreprise. L’application A présente deux types d’utilisateurs (administrateur A et utilisateur A) et deux catégories principales (application A et administration A) . L’application B présente les mêmes éléments. La configuration doit bloquer l’accès des utilisateurs A et administrateurs A à l’application B (et inversement). Aussi, les utilisateurs ne doivent pas accéder à la catégorie Administration de leur application. Dans les images ci-dessous, nous utilisons les noms enK2besoin et nioseb2Kne.

La première étape est de séparer les objets K2 qui concernent l’administration de ceux qui concerne l’usage de chaque application, depuis le K2 Designer.

AF

La deuxième étape est de créer les rôles depuis le K2 Management.

AF

La dernière étape est de définir la configuration depuis le K2 Management :

  • Pour les catégories, à faire pour A et B :
    1. Sélectionner la catégorie racine A,
    2. Cliquer sur le bouton Break Inheritance,
    3. Ajouter les deux rôles B de manière à leur interdire l’accès :
      1. Utilisateur B : View = deny et Execute = deny
      2. Administrateur B : View = deny et Execute = deny
    4. Puis, sélectionner la sous-catégorie Admin A,
    5. Cliquer sur le bouton Break Inheritance,
    6. Ajouter le rôle A de manière à restreindre l’accès :
      1. Utilisateur A : View = deny et Execute = deny
  • Pour les rôles, à faire pour les deux rôles A et B :
    1. Sélectionner le premier rôle A,
    2. Cliquer sur le bouton Break Inheritance,
    3. Ajouter les deux rôles B de manière à leur interdire l’accès :
      1. Utilisateur B : Modify = deny et Delete= deny
      2. Administrateur B : Modify = deny et Delete= deny

De cette manière, nous avons créer deux silos.

Pour aller plus loin, voici un premier lien vers la documentation pour gérer les rôles et leurs permissions. Et voilà un deuxième lien pour gérer les permissions des catégories.

C’est tout pour cette fois, cheers !

Ce billet fait partie d’une série de billets sur les nouvelles fonctionnalités de K2 Five/Cloud. Les autres articles disponibles sur ce sujet sont :

benjamin

Technical Specialist @t K2 France ----- Twitter : @benjaminbertram ----- LinkedIn : Benjamin Bertram

7 thoughts to “K2 Five – Authorization Framework”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.