Application du contrôle d'accès

Policy Manager est le composant de contrôle d'accès qui détermine si l'utilisateur actuel est autorisé à exécuter l'action spécifiée sur la ressource indiquée. Les stratégies de contrôle d'accès sont spécifiées au format XML. Lors de la création d'une instance, les stratégies et les groupes de stratégies par défaut sont chargés dans les tables de base de données appropriées. Lorsque HCL Commerce Application Server est démarré, les informations relatives au contrôle d'accès sont placées en mémoire cache afin que le gestionnaire des stratégies de contrôle d'accès puisse vérifier rapidement l'autorisation d'un utilisateur lorsqu'il est invité à le faire. Si les informations relatives au contrôle d'accès sont modifiées dans la base de données via la console d'administration ou le chargement de données de stratégie XML, la mémoire cache du contrôle d'accès doit être mise à jour. Vous pouvez mettre à jour le registre approprié dans la console d'administration. Si les données de stratégie ont changé, mettez à jour le registre des stratégies de contrôle d'accès. Si les données de groupe de stratégies ont changé, mettez à jour le registre des groupes de stratégies de contrôle d'accès. Le redémarrage de HCL Commerce met également à jour le cache.

Lorsqu'un utilisateur tente d'agir une action sur une ressource protégée, une vérification du contrôle d'accès est effectuée pour s'assurer que l'utilisateur possède les autorisations requises. Le gestionnaire des stratégies de contrôle d'accès recherche toutes les stratégies de contrôle d'accès qui s'appliquent à l'organisation propriétaire de la ressource. Puis, il vérifie ces stratégies pour évaluer si l'utilisateur est autorisé à agir sur la ressource cible. S'il existe au moins une stratégie de ce type, le gestionnaire des stratégies de contrôle d'accès accorde l'accès ; sinon, il le refuse.

Niveaux de contrôle d'accès

Il existe deux grands niveaux de contrôle d'accès dans HCL Commerce : niveau de la commande (également appelé niveau basé sur des rôles) et niveau de la ressource (également appelé niveau de l'instance).

Diagramme de niveaux de contrôle d'accès.

Contrôle d'accès au niveau de l'instruction ou basé sur des rôles

Le contrôle d'accès au niveau de l'instruction ou basé sur des rôles est un contrôle d'accès rudimentaire. Il détermine quelles personnes peuvent exécuter quelles activités dans le magasin en cours. Avec un contrôle d'accès basé sur des rôles, vous pouvez indiquer que tous les utilisateurs remplissant un rôle donné peuvent exécuter certaines instructions dans le magasin en cours. Si aucun magasin n'est sélectionné, la vérification du rôle n'est pas circonscrite à un magasin ou à une organisation donnés. Prenons par exemple la stratégie de contrôle d'accès, Les vendeurs peuvent exécuter des instructions de vendeur. Sous cette stratégie, l'une des commandes permise aux vendeurs est la commande CatalogUpdate. Dans la figure précédente, Jack et Tom sont tous deux des vendeurs, de sorte que les deux peuvent exécuter la commande UpdateCatalog. Cependant, ils ne peuvent exécuter cette commande que si le magasin en cours appartient à une organisation où ils jouent le rôle de vendeur.

Le contrôle d'accès basé sur des rôles est utilisé pour les vues et les instructions du contrôleur. Ce type de contrôle d'accès ne s'intéresse qu'au magasin actuel et non pas à d'autres ressources de bas niveau. Il détermine uniquement si l'utilisateur est autorisé à exécuter une vue ou une instruction donnée du contrôleur. Ce niveau de contrôle d'accès est obligatoire et appliqué par l'exécution.

Contrôle d'accès au niveau de l'instruction pour les instructions de contrôleur: Lorsque vous exécutez une instruction de contrôleur, une stratégie de contrôle d'accès doit permettre aux utilisateurs d'effectuer l'action Execute sur la ressource de l'instruction. La ressource est le nom d'interface de l'instruction de contrôleur. Le groupe d'accès est généralement adapté à un seul rôle. Par exemple, vous pouvez spécifier que les utilisateurs disposant du rôle Représentant de compte peuvent exécuter n'importe quelle instruction dans le groupe de ressources AccountRepresentativesCmdResourceGroup.
Contrôle d'accès au niveau de l'instruction pour les vues: Lorsqu'une vue est appelée directement à partir de l'URL, ou est le résultat d'un réacheminement à partir d'une instruction, elle doit posséder une stratégie de contrôle d'accès. Dans une stratégie de ce type, viewname doit être indiqué sous forme d'action, dans la table ACACTION. Cette action doit ensuite être associée à un groupe d'actions, à l'aide de la table ACACTACTGP. Ce groupe d'actions doit alors être référencé dans la stratégie au niveau de l'instruction appropriée, dans la table ACPOLICY.

Contrôle d'accès au niveau de l'instance ou de la ressource

Les stratégies de contrôle d'accès au niveau de l'instance ou de la ressource offrent un contrôle d'accès granulaire, qui détermine qui est habilité à exécuter quelle instruction et sur quelles ressources du magasin en cours. Les vendeurs peuvent modifier des objets appartenant à l'organisation où ils remplissent le rôle approprié. Par exemple, l'utilisateur A a le rôle de vendeur pour l'organisation vendeuse 1. L'utilisateur B remplit le même rôle pour l'organisation vendeuse 2. L'utilisateur A crée une catégorie de meubles dans le magasin de meubles. L'utilisateur B crée une catégorie de chemises dans le magasin de chemises. L'utilisateur A peut modifier la catégorie de meubles, mais pas celle des chemises. L'utilisateur B peut modifier la catégorie de chemises, mais pas celle des meubles.

En résumé, le système commence par effectuer une vérification d'accès au niveau de l'instruction. Si l'utilisateur est autorisé à exécuter une instruction, une stratégie de contrôle d'accès au niveau de la ressource détermine ensuite s'il peut accéder à la ressource en question.

Le contrôle d'accès au niveau de la ressource s'applique aux instructions et aux beans de données.

Contrôle d'accès au niveau de la ressource pour les instructions

Une fois la vérification de contrôle d'accès au niveau de l'instruction terminée, si l'accès est accordé, la vérification au niveau de la ressource est effectuée dans l'un des deux cas suivants :

L'instruction implémente getResources() - cette méthode indique les instances de ressources qui doivent être vérifiées par rapport à l'action en cours ; l'instruction est désormais l'action. L'exécution de HCL Commerce implique obligatoirement que l'utilisateur actuel ait accès à toutes les ressources indiquées par getResources(). Par défaut, getResources() renvoie la valeur Null, c'est-à-dire qu'il ne vérifie pas l'accès de niveau ressource.
L'instruction appelle checkIsAllowed(Object Resource, String Action) - dans les cas où l'auteur de l'instruction ne sait pas quelles ressources doivent être vérifiées au moment de l'appel de getResources() par l'exécution ; l'instruction peut alors appeler cette méthode checkIsAllowed(), si nécessaire, pour déterminer si la paire actuelle action-ressource est autorisée. L'action est généralement le nom d'interface de l'instruction en cours. Lorsque cette méthode est appelée, si l'accès est refusé, une exception est renvoyée : ECApplicationException( ECMessage._ERR_USER_AUTHORITY, ..)

Contrôle d'accès au niveau de la ressource pour les beans de données: Les vues sont protégées par des stratégies au niveau de l'instruction, qui sont généralement basées sur des rôles. Par exemple, la stratégie au niveau de l'instruction peut indiquer qu'un administrateur vendeur a accès à une vue spécifique. Il est souvent nécessaire de vérifier ensuite que les beans de données sur la page JSP sont tous associés à l'organisation dans laquelle l'utilisateur joue le rôle d'administrateur vendeur. Pour ce faire, tous les beans de données nécessitant une protection (directe ou indirecte) implémentent l'interface Delegator. Ces beans de données délèguent à un bean de données primaire (indépendant) qui implémente à son tour l'interface Protectable. Un bean de données primaire délègue à lui-même et met en œuvre les deux interfaces. Lorsqu'un bean de données est appelé à l'aide de la méthode activate() du gestionnaire de bean de données, l'exécution de HCL Commerce s'assure qu'une stratégie accorde à l'utilisateur en cours le droit d'exécuter l'action Display sur la ressource de bean de données primaire.