Stratégie de contrôle d'accès

Une stratégie de contrôle d'accès autorise un groupe d'utilisateurs à exécuter un ensemble d'actions sur un ensemble de ressources au sein de HCL Commerce. A moins qu'une ou plusieurs stratégies de contrôle d'accès ne les y autorisent, les utilisateurs n'ont pas accès à toutes les fonctions du système. Pour appréhender les stratégies de contrôle d'accès, vous devez comprendre quatre concepts principaux : les utilisateurs, les actions, les ressources et les relations. Les utilisateurs sont les personnes qui utilisent le système. Les ressources sont les objets du système qui doivent être protégés. Les actions sont les activités effectuées par les utilisateurs sur les ressources. Les relations sont des conditions facultatives qui existent entre les utilisateurs et les ressources.

Les stratégies permettent aux utilisateurs d'accéder à votre site. A moins qu'une ou plusieurs stratégies de contrôle d'accès ne les autorisent à exercer leurs responsabilités, les utilisateurs n'ont pas accès aux fonctions du site.

Eléments d'une stratégie de contrôle d'accès

Une stratégie de contrôle d'accès se compose de quatre éléments :

Ce diagramme présente les quatre parties d'une stratégie : groupe d'accès, groupe d'actions, groupe de ressources et éventuellement, relation. — Les quatre parties d'une stratégie de contrôle d'accès

Groupe d'accès: Groupe d'utilisateurs auquel s'applique la stratégie.
Groupe d'actions: Groupe d'actions exécutées par l'utilisateur sur les ressources.
Groupe de ressources: Ressources contrôlées par la stratégie. Un groupe de ressources peut inclure des objets métier, tels que des contract ou order, ou un ensemble de commandes associées. Par exemple, toutes les instructions pouvant être exécutées par les utilisateurs auxquels est attribué un rôle donné.
Relation: Facultatif : Chaque classe de ressource peut disposer d'un ensemble de relations qui lui sont associées. Chaque ressource peut comporter un ensemble d'utilisateurs correspondant à chaque relation. Par exemple, une stratégie peut indiquer que seul le créateur d'une commande peut la modifier. Dans ce cas, la relation serait de type creator entre l'utilisateur et la ressource liée à l'instruction.

Ensemble, ces quatre éléments définissent une stratégie dans HCL Commerce en spécifiant les utilisateurs, les actions qu'ils peuvent exécuter, l'objet métier ou l'ensemble d'instructions sur lequel des actions sont effectuées, et éventuellement, la relation entre les utilisateurs et le groupe de ressources.

Les stratégies de contrôle d'accès permettent aux utilisateurs d'accéder à votre site. A moins qu'une ou plusieurs stratégies de contrôle d'accès ne les autorisent à exercer leurs responsabilités, les utilisateurs n'ont pas accès aux fonctions du site.

Chaque stratégie de contrôle d'accès se présente sous la forme suivante :

AccessControlPolicy [AccessGroup,ActionGroup,ResourceGroup,Relationship]

Les éléments de la stratégie de contrôle d'accès indiquent qu'un utilisateur appartenant à un groupe d'accès 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 une relation particulière concernant la ressource. La relation est uniquement spécifiée lorsqu'elle est nécessaire. Par exemple, [AllUsers,UpdateDoc,doc,creator] indique que tous les utilisateurs peuvent mettre à jour un document, s'ils l'ont créé.

Les sections suivantes décrivent les informations conceptuelles et la terminologie associées au contrôle d'accès.

Groupes de membres

Le sous-système membres dans HCL Commerce permet de créer des groupes de membres, c'est-à-dire des groupes d'utilisateurs classés en fonction de différents critères professionnels. Ces regroupements peuvent être utilisés à diverses fins, par exemple pour le contrôle d'accès, pour l'approbation ou pour des objectifs marketing, comme la qualification des promotions et l'affichage des produits. Un groupe de membres de type Access Group (-2) est lié au contrôle d'accès, tandis qu'un groupe de membres de type User Group (-1) est destiné à une utilisation générale. Un groupe de membres est associé aux types de groupe de membres figurant dans la table MBRGRPUSG.

Groupes d'accès

Un groupe de membres de type Access Group (-2) permet de regrouper des utilisateurs à des fins de contrôle d'accès. Un groupe d'accès est un élément d'une stratégie de contrôle d'accès. Les critères pour l'appartenance à un groupe d'accès sont généralement basés sur des rôles, l'organisation à laquelle l'utilisateur appartient et le statut d'enregistrement de l'utilisateur. Par exemple, le groupe d'accès Buyer Administrators est un groupe dans lequel les utilisateurs tiennent le rôle d'administrateurs acheteurs.

HCL Commerce inclut un certain nombre de rôles par défaut et à chacun de ces rôles correspond un groupe d'accès par défaut qui fait référence à ce rôle de manière implicite. Les rôles peuvent être utilisés en tant qu'attributs pour ajouter des utilisateurs à un groupe d'accès en fonction du type d'activité qu'ils exécutent sur le site. Par exemple, il existe par défaut un rôle appelé Administrateur vendeur et un groupe d'accès correspondant intitulé Seller Administrators. Un administrateur de site utilise la Administration Console pour créer, mettre à jour et supprimer des groupes d'accès pour un site. Un administrateur de site, un administrateur acheteur, un administrateur vendeur ou un gestionnaire de canal utilise la Organization Administration Console pour attribuer des rôles à des utilisateurs ou affecter des utilisateurs à des groupes d'accès de façon explicite.

Groupe d'accès implicite

Un groupe d'accès implicite est défini par un ensemble de critères. Toute personne qui satisfait ces critères est membre du groupe. Les critères se fondent généralement sur les rôles d'un utilisateur, une organisation parente ou le statut d'enregistrement. Les conditions implicites qui définissent l'appartenance à un groupe de membres figurent dans la colonne CONDITIONS de la table MBRGRPCOND. L'utilisation de groupes d'accès implicites indiquant les attributs des utilisateurs facilite l'autorisation d'accès à des utilisateurs similaires sans avoir à accorder ou supprimer des affectations à des utilisateurs individuels de façon explicite. Elle évite aussi la mise à jour des membres d'un groupe en cas de modification des attributs d'un utilisateur. De plus, étant donné que plusieurs groupes d'accès peuvent faire référence au même attribut utilisateur, l'affectation d'un attribut à un utilisateur peut inclure de façon implicite cet utilisateur dans plusieurs groupes d'accès. Un critère simple pour un groupe d'accès consiste à inclure tous les utilisateurs auxquels un rôle spécifique a été attribué, quelle que soit l'organisation dans laquelle l'utilisateur tient ce rôle. Un critère plus complexe consisterait à indiquer que seuls les utilisateurs qui tiennent l'un des rôles possibles d'un ensemble pour une organisation donnée pourraient appartenir au groupe d'accès.

Groupe d'accès explicite

Il est possible d'ajouter de façon explicite un membre à un groupe de membres ou de le supprimer. Ces deux spécifications explicites peuvent être effectuées à l'aide de la table MBRGRPMBR. Un groupe d'accès explicite comprend des utilisateurs auxquels des rôles explicites ont été attribués mais qui ne partagent pas nécessairement des attributs communs. Cela vous permet également d'exclure des individus ne satisfaisant pas les conditions d'inclusion à un groupe défini implicitement, mais que vous vouliez exclure de toute façon.

Groupes d'utilisateurs

Un groupe de membres de type User Group (-1) est un ensemble d'utilisateurs défini par le commerçant, qui ont des centres d'intérêt communs. Les groupes d'utilisateurs sont comparables aux adhésions à un club pratiquées par certains grands magasins à l'égard des clients fidèles ou privilégiés. L'appartenance à un groupe d'utilisateurs permet à des clients d'obtenir des promotions et autres avantages en contrepartie de leurs achats. Par exemple, si une étude de marché montre que les personnes du troisième âge achètent régulièrement des guides de voyage et des bagages, vous pouvez affecter ces clients à un groupe de membres intitulé Seniors' Travel Club. De la même manière, vous pouvez créer un groupe d'utilisateurs récompensant les clients les plus fidèles.

Actions

En général, une action est une opération exécutée sur une ressource. Dans les stratégies basées sur des rôles pour les instructions du contrôleur, l'action est Execute et la ressource est l'instruction en cours d'exécution. Dans les stratégies basées sur des rôles pour les vues, l'action correspond au nom de la vue et la ressource est com.ibm.commerce.commands.ViewCommand. Pour le contrôle d'accès au niveau de la ressource, les actions sont généralement mappées sur les instructions HCL Commerce et la ressource est habituellement l'interface éloignée d'un bean EJB (Enterprise Java Bean) protégé. Par exemple, la commande du contrôleur com.ibm.commerce.order.commands.OrderCancelCmd opère sur la ressource com.ibm.commerce.order.objects.Order. Enfin, dans les stratégies de bean de données, l'action Display permet l'activation de ressources de bean de données.

Un administrateur de site peut utiliser la Administration Console pour associer des actions existantes à des groupes d'actions, mais pas pour créer de nouvelles actions. Vous devez définir les nouvelles actions dans un fichier XML, puis les charger dans la base de données. Les actions sont stockées dans la table ACACTION.

Groupes d'actions

Les groupes d'actions sont des groupes d'actions associées. Le groupe AccountManage est un exemple de groupe d'actions incluant les instructions suivantes :

com.ibm.commerce.account.commands.AccountDeleteCmd
com.ibm.commerce.account.commands.AccountSaveCmd

Seul l'administrateur de site peut créer, mettre à jour et supprimer des groupes d'actions. Ces opérations peuvent être effectuées à partir de la Administration Console et via XML. Les groupes d'actions sont stockés dans la table ACACTGRP. Les actions sont associées à des groupes d'actions dans la table ACACTACTGP.

Catégorie de ressource

Une catégorie de ressource se réfère à une classe de ressources qui doivent être protégées par un contrôle d'accès. Les ressources doivent mettre en oeuvre les informations d'interface protégeables. Les catégories de ressources sont des classes Java telles que order (commande) et RFQ (demande de devis). Les ressources sont les instances de ces classes. Par exemple, Order1 créée par l'administrateur de commandes A est une ressource ; Order2 créée par l'administrateur de commandes B est une autre ressource. Ces deux ressources appartiennent à la catégorie de ressource : order.

Les catégories de ressources sont définies dans la table ACRESCGRY et sont parfois appelées ressources à des fins de simplification. Un administrateur de site peut associer des catégories de ressources existantes à des groupes de ressources, à l'aide de la Administration Console. De nouvelles catégories de ressources peuvent être créées via XML.

Ressources

Les ressources sont tous les objets du système qui doivent être protégés. Par exemple, les demandes de devis, les utilisateurs et les commandes constituent des ressources de HCL Commerce qui doivent être protégées. Chaque ressource a un propriétaire. La propriété de la ressource est utilisée pour déterminer quelles stratégies de contrôle d'accès s'appliquent à cette ressource. Les stratégies de contrôle d'accès ont un propriétaire, qui est une entité organisationnelle. Une stratégie s'applique uniquement aux ressources appartenant à la même entité organisationnelle souscrivant à un groupe de stratégies, qui contient la stratégie. Si l'organisation à laquelle appartient la ressource ne souscrit pas à des groupes de stratégies, les stratégies incluses dans les groupes de stratégies auxquels souscrit l'organisation parente la plus proche seront alors appliquées.

Ressources de l'instruction du contrôleur

Pour le contrôle d'accès basé sur des rôles pour les instructions du contrôleur, la stratégie est structurée de telle sorte que l'action Execute soit exécutée sur la ressource de l'instruction du contrôleur. Ces stratégies visent à limiter l'exécution des instructions du contrôleur aux utilisateurs dotés d'un rôle particulier. Le groupe d'accès pour ces stratégies concerne généralement les utilisateurs disposant d'un seul rôle, par exemple les responsables produit (utilisateurs jouant le rôle de responsable produit). Le groupe de ressources est alors l'ensemble des instructions du contrôleur qu'un responsable produit peut exécuter.

Lors de l'application d'un contrôle d'accès basé sur des rôles à une instruction du contrôleur, le propriétaire de l'instruction doit être déterminé. Pour ce faire, la méthode getOwner() doit être appelée sur l'instruction, si elle a été implémentée. En général, cette méthode n'est pas mise en oeuvre, si bien que l'exécution de HCL Commerce l'évalue en procédant de l'une des façons suivantes :

Utilisation de l'organisation possédant le magasin qui figure dans le contexte de l'instruction.
S'il n'y a aucun magasin dans le contexte de l'instruction, utilisation de l'organisation racine comme propriétaire.

Ressources de beans de données

Tous les beans de données ne doivent pas être protégés. Dans l'application HCL Commerce existante, les beans de données nécessitant une protection implémentent déjà le contrôle d'accès requis. La question des ressources à protéger est soulevée lors de la création de nouveaux beans de données. Le choix des ressources à protéger dépend de votre application. Un bean de données doit être protégé (directement ou indirectement), si les informations à afficher ne sont pas suffisamment protégées par le contrôle d'accès basé sur des rôles exécuté sur la vue, qui correspond à la page JSP (Java Server Page) contenant le bean de données.

Si un bean de données doit être protégé et peut exister seul, il doit être protégé directement. Si l'existence d'un bean de données dépend de l'existence d'un autre bean de données, la protection doit être déléguée à l'autre bean de données. Le bean de données Order constitue un exemple de bean de données à protéger directement. Le bean de données OrderItem constitue un exemple de bean de données à protéger indirectement, car il ne peut pas exister sans le bean de données Order.

Ressources de données

Les ressources de données se rapportent à des objets métier qui peuvent être manipulés tels que des commandes, des demandes de devis et des utilisateurs. Elle sont généralement protégées au niveau du bean enterprise bien qu'il soit possible de protéger n'importe quelle classe pour autant qu'elle implémente l'interface Protectable. Les ressources de données sont protégées à l'aide de vérifications de contrôle d'accès au niveau de la ressource. Pour ce faire, la méthode habituelle consiste à renvoyer les ressources de données dans la méthode getResources() d'une instruction du contrôleur ou d'une instruction d'activité.

Groupes de ressources

Un groupe de ressources permet d'identifier un ensemble de ressources associées. Un groupe de ressources peut comporter des objets métier tels qu'un contrat ou un ensemble d'instructions associées. Au niveau du contrôle d'accès, les groupes de ressources indiquent à quelles ressources les stratégies de contrôle d'accès autorisent l'accès.

Les groupes de ressources sont définis dans la table ACRESGRP. Les administrateurs de site peuvent gérer des groupes de ressources et associer des ressources à des groupes de ressources à l'aide de la Administration Console ou via XML.

Groupes de ressources implicites

Les groupes de ressources implicites définissent les ressources correspondant à un certain ensemble d'attributs. L'un de ces attributs doit être le nom de classe Java. Les autres attributs peuvent inclure le statut, l'ID magasin, le prix, etc. Par exemple, vous pouvez créer un groupe de ressources implicite incluant toutes les commandes en attente (ORDERS.STATUS=P). Les groupes de ressources implicites sont généralement utilisés pour regrouper des ressources qui seront employées dans des stratégies au niveau de la ressource, lorsque les ressources partagent un attribut commun au-delà du nom de classe Java.

Les groupes de ressources implicites sont définis à l'aide de la colonne CONDITIONS de la table ACRESGRP. Des groupes de ressources implicites simples peuvent être créés à l'aide de la Administration Console. Des groupes de plus en plus complexes peuvent être créés via XML.

Groupes de ressources explicites

Des groupes de ressources explicites sont spécifiés en associant une ou plusieurs catégories de ressources à un groupe de ressources. Cette association est effectuée dans la table ACRESGPRES. L'ajout d'une catégorie de ressource à un groupe de ressources explicite, en répertoriant son nom de classe Java, vous permet de regrouper des ressources individuelles qui ne partagent pas nécessairement d'attributs communs.

Relations

Chaque ressource peut avoir une relation associée et un ensemble de membres correspondant à chaque relation. Ainsi, toutes les ressources ont une relation de owner, qui est détenue par le propriétaire de la ressource. D'autres relations peuvent inclure des destinataires de documents et le créateur d'une instruction. Ces relations de ressources sont importantes lors de la détermination des personnes autorisées à exécuter certaines actions sur l'instance donnée d'une ressource. Par exemple, le créateur d'un document peut ne pas pouvoir le supprimer alors qu'un visiteur le pourra peut-être. De la même façon, un réviseur peut être autorisé à lire et à accepter un document, mais ne pas pouvoir le transmettre ou effectuer d'autres opérations sur ce document.

Les relations sont stockées dans la table ACRELATION et sont éventuellement indiquées dans une stratégie de contrôle d'accès, à l'aide de la colonne ACRELATION_ID de la table ACPOLICY. Lors de l'évaluation d'une stratégie nécessitant une relation entre l'utilisateur et la ressource, la méthode d'exécution (Long Member, String relationship) pour la ressource sera appelée pour l'évaluer. Ces relations sont parfois appelées relations simples par opposition à des groupes de relations.

Groupes de relations

Les stratégies de contrôle d'accès peuvent indiquer qu'un utilisateur doit exécuter une relation particulière par rapport à la ressource accédée ou qu'il doit remplir les conditions spécifiées dans un groupe de relations. Dans la plupart des cas, une relation est suffisante. Toutefois, si des relations plus complexes sont nécessaires, un groupe de relations peut alors être utilisé. Un groupe de relations permet de spécifier plusieurs relations et également une chaîne de relations. Une construction de chaîne de relations est utilisée dans les deux cas. Une chaîne de relations est une construction qui peut exprimer une relation simple (directement entre un utilisateur et la ressource), mais qui peut également être utilisée pour exprimer une série de relations entre l'utilisateur et la ressource. Par exemple, afin d'exprimer le fait qu'un utilisateur doit posséder un rôle dans une organisation disposant d'une relation (autre que la relation de propriétaire) avec la ressource, un groupe de relations doit être utilisé. Dans cet exemple, il existe une relation de rôle entre l'utilisateur et l'organisation, et une relation entre l'organisation et la ressource.

Comparaison de relations et de groupes de relations

Dans la plupart des cas, l'utilisation d'une relation répond aux besoins de votre application en matière de contrôle d'accès étant donné que, conceptuellement, la plupart des relations s'effectuent directement entre un utilisateur et la ressource. Par exemple, la stratégie établit que l'utilisateur doit être le créateur de la ressource. Toutefois, si vous devez spécifier plusieurs relations, un groupe de relations doit alors être utilisé. Par exemple, la stratégie établit que l'utilisateur doit être le créateur ou le demandeur de la ressource.

Des groupes de relations sont également nécessaires pour exprimer une chaîne de relations entre un utilisateur et la ressource. Dans une chaîne de relations, il n'existe pas de relation directe entre l'utilisateur et la ressource. Par exemple, un utilisateur appartient à l'organisation acheteuse spécifiée par une commande. Dans ce cas, l'utilisateur a une relation enfant avec l'organisation, qui a elle-même une relation d'achat avec la commande.

Chaînes de relations

Chaque groupe de relations est composé d'une ou plusieurs conditions ouvertes RELATIONSHIP_CHAIN, regroupées par les éléments andListCondition ou orListCondition. Une chaîne de relations est une série d'une ou plusieurs relations. La longueur d'une chaîne de relations est déterminée par le nombre de relations qui la compose. Pour l'identifier, il convient d'examiner le nombre d'entrées

<parameter name= "X" value="Y"/>

dans la représentation XML de la chaîne de relations. Vous trouverez ci-dessous un exemple de chaîne de relations d'une longueur égale à 1.


<openCondition name="RELATIONSHIP_CHAIN">
<parameter name="RELATIONSHIP"
value="aValue"/>
</openCondition>

Pour les chaînes de relations de longueur égale à 1, l'élément <parameter name="Relationship" value="something"> indique une relation directe entre l'utilisateur et la ressource. L'attribut de valeur est la chaîne représentant la relation entre l'utilisateur et la ressource. Il doit également correspondre au paramètre de relation de la méthode fulfills() sur la ressource protégeable.

Lorsqu'une chaîne de relations possède une longueur égale à 2, il s'agit d'une série de deux relations. Le premier élément, <parameter name= "X" value="Y"/>, indique une relation entre un utilisateur et une entité organisationnelle. Le dernier élément, <parameter name= "X" value="Y"/>, indique une relation entre cette entité organisationnelle et la ressource. Vous trouverez ci-dessous un exemple de chaîne de relations d'une longueur égale à 2.

<openCondition name=RELATIONSHIP_CHAIN">
<parameter name="aValue1" value="aValue2"/>
<parameter name="RELATIONSHIP" value="aValue3"/>
</openCondition>

Les aValue1 valeurs possibles sont HIERARCHY et ROLE. HIERARCHY indique qu'il existe une relation hiérarchique entre l'utilisateur et l'entité organisationnelle dans la hiérarchie des membres. ROLE indique que l'utilisateur joue un rôle dans l'entité organisationnelle.

Si la valeur de aValue1 est HIERARCHY, les valeurs possibles incluent child, qui renvoie à l'entité organisationnelle dont l'utilisateur est un enfant direct dans la hiérarchie des membres. Si la valeur de aValue1 est ROLE, les valeurs possibles incluent toutes les entrées valides dans la colonne NAME de la table ROLE, qui renvoient à toutes les entités organisationnelles pour lesquelles l'utilisateur actuel joue ce rôle.

L'entrée aValue3 est une chaîne qui représente la relation entre une ou plusieurs entités organisationnelles extraites à partir de l'évaluation du premier paramètre et de la ressource. Cette valeur correspond au paramètre de relation de la méthode fulfills() sur la ressource protégeable. Si plusieurs entités organisationnelles ont été renvoyées par le paramètre d'évaluation aValue1, cette partie de la chaîne RELATIONSHIP_CHAIN est satisfaite si au moins l'une de ces entités organisationnelles exécute la relation indiquée par le paramètre aValue2.

Remarque : Un groupe de relations composé d'une seule chaîne de relations avec un seul élément de paramètre est fonctionnellement équivalent à une relation simple. Dans ce cas, il est plus facile d'utiliser une relation plutôt qu'un groupe de relations dans la stratégie.

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

Il existe deux types de stratégies de contrôle d'accès :

Stratégies standard groupables (type -2)
Stratégies de modèle groupables (type -3)

Ces deux types de stratégies doivent appartenir à un groupe de stratégies pour pouvoir être appliquées au système. Une stratégie standard groupable est appliquée une fois aux organisations souscrivant à un groupe de stratégies qui contient la stratégie.

Les stratégies de modèle groupables sont dynamiques par nature : elles disposent d'un groupe d'accès sectorisé, lorsque le système est en cours d'exécution, à l'organisation qui possède la ressource. Par exemple, si ce type de stratégie est appliqué à une ressource possédée par l'organisation XYZ, elle vérifie si l'utilisateur a rempli l'un des rôles spécifiés pour cette organisation ou l'une de ses parentes.

Stratégies de contrôle d'accès par défaut spéciales

Les stratégies suivantes nécessitent des explications supplémentaires :

Les administrateurs de site peuvent exécuter toutes les opérations (SiteAdministratorsCanDoEverything)
Le groupe de service clientèle BecomeUser exécute des instructions BecomeUser au nom du client (BecomeUserCustomerServiceGroupExecutesBecomeUserCmdsResourceGroup)

La stratégie SiteAdministratorsCanDoEverything est une stratégie par défaut spéciale qui accorde un accès superutilisateur aux administrateurs disposant du rôle d'administrateur de site. Dans cette stratégie, un administrateur de site peut exécuter n'importe quelle action sur n'importe quelle ressource, même si ces actions ou ressources n'ont pas été définies. Il est important de garder cela à l'esprit lors de l'affectation de ce rôle à des utilisateurs.

La stratégie BecomeUserCustomerServiceGroupExecutesBecomeUserCmdsResourceGroup est une stratégie spéciale qui autorise certains administrateurs à exécuter des instructions données pour le compte d'autres utilisateurs. Cette stratégie est nécessaire, par exemple, lorsqu'un client demande à un représentant du service clientèle de créer une commande en son nom. Dans ce cas, le représentant du service clientèle peut exécuter l'instruction comme si elle avait été lancée par le client lui-même.