HCL Commerce stratégies de contrôle d'accès

Cette section présente brièvement les principales composantes de la structure de contrôle d'accès de HCL Commerce. Elle est fournie de manière à ce que certaines des tâches de programmation liées au contrôle d'accès soient considérées dans le contexte adéquat.

Le modèle de contrôle d'accès de HCL Commerce est basé sur l'application de stratégies de contrôle d'accès. Les stratégies de contrôle d'accès permettent d'externaliser les règles de contrôle d'accès du code de logique commerciale en supprimant la nécessité de coder en dur les instructions de contrôle dans le code. Par exemple, vous n'avez pas besoin d'inclure un code similaire au code suivant :

if (user.isAdministrator())
 then {}

Les stratégies de contrôle d'accès sont mises en application par le gestionnaire de stratégies de contrôle d'accès. En règle générale, lorsqu'un utilisateur tente d'accéder à une ressource protégée, le gestionnaire de stratégies de contrôle d'accès détermine d'abord les stratégies de contrôle d'accès qui s'appliquent à la ressource protégée, puis, en fonction de ces stratégies, si l'utilisateur est autorisé à accéder aux ressources demandées.

Une stratégie de contrôle d'accès est une stratégie à 4 tuples qui est stockée dans la table ACPOLICY. Chaque stratégie de contrôle d'accès se présente sous la forme suivante :

AccessControlPolicy [UserGroup, ActionGroup, ResourceGroup, Relationship]

Les éléments de la stratégie de contrôle d'accès à 4 tuples indiquent qu'un utilisateur appartenant à un groupe d'utilisateurs spécifique est autorisé à exécuter des actions du groupe d'actions spécifié sur des ressources du groupe de ressources spécifié, dans la mesure où cet utilisateur satisfait aux conditions spécifiées dans la relation ou le groupe de relations concernant la ressource concernée. Par exemple, [AllUsers, UpdateDoc, doc, creator] indique que tous les utilisateurs peuvent mettre à jour un document, s'ils l'ont créé.

Le groupe d'utilisateurs est un type spécifique de groupe de membres qui est défini dans la table de base de données MBRGRP. Un groupe d'utilisateurs doit être associé au type de groupe de membres -2. La valeur -2 représente un groupe d'accès et est définie dans la table MBRGRPTYPE. L'association entre le groupe d'utilisateurs et le type de groupe de membres est stockée dans la table MBRGRPUSG.

L'appartenance d'un utilisateur à un groupe d'utilisateurs particulier peut être indiquée explicitement ou implicitement. Une spécification explicite se produit si la table MBRGRPMBR indique que l'utilisateur appartient à un groupe de membres particulier. Une spécification implicite se produit si l'utilisateur satisfait à une condition (par exemple, tous les utilisateurs qui remplissent le rôle de responsable produit) qui est indiquée dans la table MBRGRPCOND. Il peut également y avoir des conditions combinées (par exemple, tous les utilisateurs qui remplissent le rôle de responsable produit et qui remplissent ce rôle depuis au moins 6 mois) ou des exclusions explicites.

La plupart des conditions permettant d'inclure un utilisateur dans un groupe d'utilisateurs sont basées sur le fait que l'utilisateur remplisse un rôle particulier. Par exemple, il peut y avoir une stratégie de contrôle d'accès permettant à tous les utilisateurs qui remplissent le rôle de responsable produit d'effectuer des opérations de gestion de catalogue. Dans ce cas, tout utilisateur auquel le rôle de responsable produit est attribué dans la table MBRROLE est alors implicitement inclus dans le groupe d'utilisateurs.

L'élément ActionGroup provient de la table ACACTGRP. Un groupe d'actions fait référence à un groupe d'actions explicitement spécifié. La liste des actions est stockée dans la table ACACTION et la relation de chaque action avec son groupe (ou ses groupes) d'actions est stockée dans la table ACACTACTGP. Le groupe d'actions "OrderWriteCommands" représente un exemple de groupe d'actions. Ce groupe d'actions inclut les actions suivantes utilisées pour mettre à jour les commandes :

com.ibm.commerce.order.commands.OrderDeleteCmd
com.ibm.commerce.order.commands.OrderCancelCmd
com.ibm.commerce.order.commands.OrderProfileUpdateCmd
com.ibm.commerce.order.commands.OrderUnlockCmd
com.ibm.commerce.order.commands.OrderScheduleCmd
com.ibm.commerce.order.commands.ScheduledOrderCancelCmd
com.ibm.commerce.order.commands.ScheduledOrderProcessCmd
com.ibm.commerce.order.commands.OrderItemAddCmd
com.ibm.commerce.order.commands.OrderItemDeleteCmd
com.ibm.commerce.order.commands.OrderItemUpdateCmd
com.ibm.commerce.order.commands.PayResetPMCmd

Un groupe de ressources est un mécanisme permettant de regrouper certains types de ressources. L'appartenance d'une ressource à un groupe de ressources peut être spécifiée de l'une des deux façons suivantes :

A l'aide de la colonne conditions de la table ACRESGRP
A l'aide de la table ACRESGPRES

Dans la plupart des cas, il suffit d'utiliser la table ACRESGPRES pour associer des ressources à des groupes de ressources. Avec cette méthode, les ressources sont définies dans la table ACRESCGRY à l'aide de leur nom de classe Java. Ensuite, ces ressources sont associées aux groupes de ressources appropriés (table ACRESGRP) à l'aide de la table d'association ACRESGPRES. Dans les cas où le nom de classe Java seul n'est pas suffisant pour définir les membres d'un groupe de ressources (par exemple si vous devez restreindre davantage les objets de cette classe en fonction d'un attribut de la ressource), le groupe de ressources peut être défini entièrement à l'aide de la colonne conditions de la table ACRESGRP. Notez que pour effectuer ce regroupement de ressources sur la base d'un attribut, la ressource doit également implémenter l'interface Groupable.

Le diagramme suivant montre un exemple de spécification de regroupement de ressources. Dans cet exemple, le groupe de ressources 10023 inclut toutes les ressources qui y sont associées dans la table ACRESGPRES. Le groupe de ressources 10070 est défini à l'aide de la colonne du champ conditions de la table ACRESGRP. Ce groupe de ressources inclut des instances de l'interface distante Order, qui ont également le statut ="Z" (spécifiant une liste de demandes partagée).

Ce diagramme montre une exemple de spécification de regroupement de ressources.

La colonne MEMBER_ID des tables ACACTGRP, ACRESGRP et ACRELGRP doit avoir une valeur de -2001 (organisation racine).

La stratégie de contrôle d'accès peut éventuellement inclure un élément Relationship ou RelationshipGroup comme quatrième élément.

Si votre stratégie de contrôle d'accès utilise un élément Relationship, il provient de la table ACRELATION. Si elle inclut un élément RelationshipGroup, il provient de la table ACRELGRP. Notez que ni l'un ni l'autre n'ont besoin d'être inclus, mais si vous en incluez un, vous ne pouvez pas inclure l'autre. Une spécification RelationshipGroup de la table ACRELGRP est prioritaire par rapport aux informations de relation de la table ACRELATION.

La table ACRELATION spécifie les types de relations qui existent entre les utilisateurs et les ressources. Parmi les types de relations, on retrouve le créateur, le contributeur et le propriétaire. L'élément de relation est par exemple utilisé pour s'assurer que le créateur d'une commande peut toujours mettre à jour la commande.

La table ACRELGRP spécifie les types de groupes de relations qui peuvent être associés à des ressources particulières. Un groupe de relations est un groupe d'une ou plusieurs chaînes relations. Une chaîne de relations est une série d'une ou plusieurs relations. Un groupe de relations peut par exemple spécifier qu'un utilisateur doit être le créateur de la ressource et appartenir également à l'entité organisationnelle d'achat référencée dans la ressource.

La spécification du groupe de relations (ou de la relation) est une partie facultative de la stratégie de contrôle d'accès. Elle est couramment utilisée si vous avez créé vos propres instructions et que ces instructions ne sont pas limitées à certains rôles. Dans ce cas, vous pouvez appliquer une relation entre l'utilisateur et la ressource. En règle générale, si les instructions doivent être limitées à certains rôles, cela a lieu par l'intermédiaire de l'élément UserGroup de la stratégie de contrôle d'accès plutôt qu'à l'aide de l'élément Relationship.

Autre concept important lié aux stratégies de contrôle de l'accès : le concept de groupes de stratégies de contrôle d'accès. Chaque modèle métier dispose de son propre ensemble de stratégies de contrôle d'accès. Des groupes de stratégies sont utilisés pour regrouper les groupes de stratégies au sein des modèles. Les stratégies sont explicitement affectées aux groupes de stratégies appropriés et les entreprises peuvent alors souscrire à un ou plusieurs de ces groupes de stratégies. Dans les versions précédentes de HCL Commerce, une stratégie s'appliquait à toutes les ressources appartenant aux enfants de l'entreprise propriétaire de cette stratégie.

Dans HCL Commerce, si une organisation souscrit à un ou plusieurs groupes de stratégies, seules les stratégies de ces groupes de stratégies s'appliquent aux ressources de cette organisation. Si une ressource appartient à une organisation qui ne souscrit à aucun groupe de stratégies, le gestionnaire de stratégies de contrôle d'accès fouille la hiérarchie de l'organisation jusqu'à ce qu'il rencontre l'organisation ancêtre la plus proche qui souscrit à au moins un groupe de stratégies ; après l'avoir trouvée, il applique les stratégies appartenant à ces groupes de stratégies.

Pour toutes les ressources détenues par l'organisation du vendeur, les stratégies du groupe de stratégies de l'organisation du vendeur et celles du groupe de stratégies de l'organisation racine s'appliquent. Ces stratégies sont applicables parce que l'organisation du vendeur souscrit explicitement à ces deux groupes de stratégies (les flèches pointillées montrent l'abonnement). Au total, trois stratégies s'appliquent à cette organisation. Dans cet exemple, l'organisation qui possédait la ressource souscrit explicitement à des groupes de stratégies. Le diagramme montre également un exemple dans lequel l'organisation ne souscrit pas explicitement à des groupes de stratégies, de sorte que la structure de contrôle d'accès doit regarder plus haut dans la hiérarchie. Pour les ressources qui appartiennent à l'organisation par défaut, il faut remonter dans la hiérarchie jusqu'à l'organisation racine. L'organisation racine ne souscrit qu'à un seul groupe de stratégies, de sorte que ce sont les seules stratégies (stratégies 1 et 2) qui s'appliquent aux ressources de l'organisation par défaut.