Relations entre stratégies basées rôles et stratégies basées niveau de ressources

Compréhension de la relation entre des stratégies basées sur des rôles et des stratégies au niveau de la ressource

Dans HCL Commerce, à chaque action pouvant être effectuée par un utilisateur sont affectés un ou plusieurs rôles à l'aide des stratégies basées sur des rôles, en procédant de la façon suivante :

• A chaque rôle par défaut correspond un groupe d'accès. Par exemple, le groupe d'accès pour le rôle Vendeur est Sellers.
• A chaque groupe d'accès basé rôles sont généralement associées deux stratégies basées rôles :
  • Une stratégie qui définit les instructions de contrôleur que le rôle est autorisé à exécuter.
  • Une stratégie qui définit les actions de visualisation que le rôle est autorisé à exécuter. Les actions de visualisation correspondent à des vues dans les fichiers de configuration Struts. Par exemple, OperationalReportsHomeRHSView affiche une page Web contenant la liste des rapports d'exploitation auxquels le vendeur à accès.

Certaines instructions de contrôleur ne disposent que d'une stratégie basée sur des rôles, mais d'aucune stratégie au niveau de la ressource. C'est le cas si l'instruction ne fonctionne sur aucune ressource protégeable. Par exemple, l'instruction SetCurrencyPreferenceCmd n'a pas besoin d'une stratégie au niveau de la ressource, car elle peut uniquement modifier la préférence concernant la devise pour l'utilisateur exécutant l'instruction. Si elle a pu modifier la préférence concernant la devise d'un autre utilisateur, l'objet utilisateur doit alors être protégé et une stratégie au niveau de la ressource s'avère nécessaire.

Les stratégies au niveau de la ressource pour les instructions de contrôleur sont directement associées à certaines stratégies basées sur des rôles pour les instructions de contrôleur. Dans la stratégie au niveau de la ressource, l'instruction de contrôleur fait partie du groupe d'actions, tandis que dans la stratégie basée sur des rôles, l'instruction de contrôleur fait partie du groupe de ressources. La figure suivante illustre cette relation. La stratégie au niveau de la ressource inclut les rôles A et B dans son groupe d'accès, ce qui met en jeu les stratégies basées sur des rôles pour les rôles A et B. Pendant que la stratégie au niveau de la ressource accorde l'autorisation aux utilisateurs dotés des rôles A ou B d'effectuer certaines actions sur un ensemble de ressources spécifique, les stratégies associées basées sur des rôles accordent l'autorisation aux utilisateurs dotés des rôles A et B d'exécuter ces actions en général.

Relation entre une stratégie au niveau de la ressource et les stratégies associées basées rôles

Ce diagramme illustre un exemple de stratégie au niveau de la ressource qui autorise les utilisateurs du groupe d'accès People à lire ou étudier certaines ressources - livres, magazines et journaux. Cette stratégie est correctement formulée car les stratégies basées sur les rôles child et adult les autorisent également à lire ou étudier des livres, des magazines et des journaux.

Stratégie au niveau de la ressource et stratégies basées rôles qui l'affectent

Notez que dans les stratégies basées sur des rôles pour les instructions de contrôleur :

• Le groupe d'actions contient une seule action : Execute.
• Le groupe de ressources contient l'instruction de contrôleur qui peut être exécutée.

De même, dans les stratégies basées sur des rôles pour les vues :

• Le groupe d'actions contient les vues qui peuvent être exécutées.
• Le groupe de ressources contient une seule ressource : com.ibm.commerce.command.ViewCommand.

D'autre part, dans les stratégies au niveau de la ressource :

• Le groupe d'actions contient l'ensemble des actions qui peuvent être exécutées sur les ressources dans le groupe de ressources.
• Le groupe de ressources contient une liste des ressources commerciales réelles sur lesquelles vous pouvez agir.

Une stratégie au niveau de la ressource peut uniquement autoriser des utilisateurs jouant un rôle particulier à effectuer des actions déjà autorisées par la stratégie basée sur des rôles correspondante. Par exemple, dans l'exemple précédent, le rôle child est autorisé à exécuter les actions suivantes :

• Etudier
• Lire
• Lire

Supposons que la stratégie au niveau de la ressource soit maintenant modifiée pour inclure une nouvelle action appelée work. Les utilisateurs disposant du rôle adult pourront exécuter l'action work. Toutefois, les utilisateurs ayant le rôle child ne pourront pas. La raison à cela paraît évidente lorsque vous vérifiez les stratégies basées sur des rôles pour les deux rôles. La stratégie pour le rôle adult répertorie l'action work dans son groupe de ressources. La stratégie pour le rôle child ne le fait pas. Même si les rôles child et adult disposent des autorisations appropriées de la part de la stratégie au niveau de la ressource, la stratégie basée sur des rôles pour le rôle child n'autorise pas l'action work.

Les stratégies au niveau de la ressource étant liées aux stratégies basées sur des rôles, la meilleure façon de localiser toutes les stratégies affectées par un changement donné consiste à travailler en amont à partir de la stratégie au niveau de la ressource. La première étape consiste à examiner le groupe d'accès de la stratégie au niveau de la ressource et à déterminer s'il contient des rôles. Vous pouvez visualiser la liste complète des rôles par défaut en sélectionnant Gestion des accès > Rôles à partir de la console d'administration de l'organisation.

Si le groupe d'accès de la stratégie au niveau de la ressource inclut des rôles, consultez leurs stratégies basées sur des rôles pour voir s'ils doivent être changés. Si vous ajoutez une action au groupe d'actions d'une stratégie au niveau de la ressource, vous devez vous assurer que les stratégies pertinentes basées sur des rôles autorisent également la nouvelle action. Si vous supprimez une action dans une stratégie au niveau de la ressource et qu'aucune autre stratégie au niveau de la ressource ne fait référence à cette action, il est préférable de retirer la ressource correspondante des stratégies basées sur des rôles associées.

Compréhension du modèle de stratégie

Pour qu'un utilisateur puisse exécuter une action, une stratégie doit définir les autorisations. Toutefois, HCL Commerce permet aux utilisateurs d'effectuer une action si n'importe quelle stratégie fournit l'autorisation nécessaire. Ainsi, si vous définissez une nouvelle stratégie plus restrictive que la stratégie par défaut, vous devez supprimer ou modifier la stratégie par défaut plus globale pour éviter qu'elle ne supplante votre nouvelle stratégie.

Par exemple, supposons qu'une stratégie par défaut A autorise tous les utilisateurs enregistrés à soumettre des offres pour des enchères. Vous voulez modifier cette stratégie pour que les offres pour la vente aux enchères soient limitées aux utilisateurs dotés du rôle d'acheteurs. Si vous définissez simplement une nouvelle stratégie qui autorise les acheteurs à créer des offres pour la vente aux enchères, votre nouvelle stratégie n'aura aucun effet. La stratégie par défaut A permettra toujours à tous les utilisateurs enregistrés de faire des offres. Pour que votre nouvelle stratégie prenne effet, vous devez supprimer la stratégie par défaut globale.

Le tableau suivant récapitule les modifications supplémentaires que vous devez effectuer lorsque vous créez, supprimez ou modifiez une stratégie au niveau de la ressource.