Les permissions liées aux user groups sont remplacés par une assignation de permission sets composables directement à des security groups.

Business Central faisait exception dans la gestion des permissions dans l’écosystème de solutions Microsoft. Ces permissions devaient être gérées à l’intérieur de l’ERP par un administrateur dédié.

Le changement d’approche devrait être effectif d’ici la fin d’année 2024 selon eux sur les versions on-prem et online. Les user group seront dès lors obsolètes. On peut encore pour l’instant s’affranchir de cette nouveauté :

On se priverait cependant des avantages de ce nouveau concept introduit, que sont les security group :

  • Inter compatibilité pour être exploitables à travers tout l’environnement Microsoft et ses différentes applications : Business Central, SharepointOnline, CRM Online, Planner, etc …
  • Meilleure gestion des permissions incombant aux utilisateurs. Après paramétrage, l’attribution d’un nouvel utilisateur à un ou plusieurs security group lui donnera les accès et restrictions correspondants à ses fonctions et départements d’application ; la gestion de la sécurité et des droits est désormais délégué à l’administrateur Azure, sur Azure ENTRA ID (anciennement Azure Active directory), en plus de l’être déjà pour les organisations.

Ils fonctionnent de la manière suivante :

Ce changement suggère l’usage des permissions sets qui ont profités d’une refonte lors des précédentes releases ! Ils autorisaient ou interdisaient l’accès à un certain nombre de tables et donc aux actions que l’utilisateur pouvaient effectuer mais seulement avec l’assignation d’un unique permission set standard parmi ceux disponibles sur Business Central.

BC accorde désormais une gestion plus modulable de ces permissions sets. Ils sont catégorisés comme composables, leur potentiel est décuplé.

Ils sont désormais inclusifs, avec des permissions sets qui peuvent, par imbrication, en contenir ou exclure plusieurs autres blocs. Cette vision plus permissive est aussi simultanément présente à la table, où l’on peut restreindre ou exclure certaines. On obtient alors des permissions sets beaucoup plus complets et affinés, grâce à un héritage des permissions en cascade, qui peuvent correspondre à des fonctions utilisateurs.

 

La fiche utilisateur affichera un récapitulatif général des associations à l’utilisateur sélectionné :

  • Permissions sets spécifiques à cet utilisateur
  • Security group(s) attribué(s)
  • Permissions set hérités du/des security group(s)
  • License(s) attribuée(s)

Pour conclure, Microsoft conseille d’attribuer les permissions set (composables ou non) directement aux security groups. Un unique, par rôle organisationnel, englobant toutes les autorisations nécessaires sera préconisé, pour éviter les saisies fastidieuses. Les membres de ces security group auront alors intrinsèquement les autorisations correspondantes. Ce paramétrage est optimisé pour un modèle mono-société. Il remplacerait fidèlement les permissions issues des caduques user group dont Microsoft propose une conversion automatique en  permissions set modulable.

Pour une organisation multi entité, cette saisie est plus laborieuse car elle multiplierait la création de security group avec le nombre de jeux de société d’application différents. Une idée qui casserait la vision de Microsoft serait toujours d’élaborer des permissions set « globaux », mais les associer user par user.

Vous pourrez retrouver une vidéo récapitulative des BC TechDays de l’année dernière qui évoque l’ensemble des évolutions mentionnées dans l’article :