Interactions de contrôle d'accès

La structure de la stratégie de contrôle d'accès contrôle le fonctionnement du contrôle d'accès dans HCL Commerce.

Le diagramme de syntaxe suivant montre les interactions de la stratégie de contrôle d'accès. Les détails sont décrits sous le diagramme.

Le diagramme précédent montre les actions effectuées par le policy manager du contrôle d'accès. Le gestionnaire de stratégie de contrôle d'accès 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. Il détermine l'accès en fouillant les stratégies dans les groupes auxquels le propriétaire de la ressource souscrit. Si le propriétaire de la ressource ne souscrit à aucun groupe de stratégies, il recherche les stratégies dans les groupes auxquels l'ancêtre le plus proche du propriétaire de la ressource souscrit. Si au moins une police accorde l'accès, l'autorisation est accordée.

La liste suivante décrit les actions du diagramme d'interaction précédent. Elles sont commandées du haut du diagramme vers le bas.

isGeneric()

Détermine si un utilisateur générique doit être converti en utilisateur invité. Si l'utilisateur actuel est générique, la conversion en utilisateur invité a lieu avant de faire appel à l'une des méthodes restantes.

setRequestProperties()

Transmet les paramètres de requête à la commande. Les paramètres de requête peuvent être utilisés dans les appels de contrôle d'accès ultérieurs (par exemple en renvoyant des données spécifiques aux paramètres de requête de getOwner() ou getResources()).

isAllowed() [niveau de commande]

Les composants runtime déterminent si l'utilisateur dispose d'un accès au niveau de la commande pour la commande de contrôleur ou la vue.

Remarque : Les paramètres d'une commande de contrôleur sont fixés sur l'ID de l'utilisateur actuel, la chaîne d'action Execute et la classe de ressources. La classe de ressources est la classe d'implémentation entièrement qualifiée pour la commande de contrôleur.

getOwner() [niveau de commande]

Le gestionnaire de stratégies de contrôle d'accès détermine le propriétaire de la ressource au niveau de la commande. L'implémentation par défaut renvoie l'identificateur de membre (memberId) du propriétaire du magasin (storeId) qui se trouve dans le contexte de la commande. S'il n'y a aucun identificateur de magasin dans le contexte de la commande, l'organisation racine (-2001) est renvoyée. Vous pouvez renvoyer d'autres valeurs qui ont du sens du point de vue de la propriété dans le contrôle d'accès au niveau de la commande de votre commande.

getAndApplyApplicablePolicies() [niveau de commande]

Le gestionnaire de stratégies de contrôle d'accès recherche et traite les stratégies applicables en fonction de l'utilisateur, de l'action, de la ressource et du magasin en cours spécifiés. Si une stratégie implique un rôle et que vous spécifiez un magasin, le gestionnaire de stratégies évalue si l'utilisateur en cours a le rôle spécifié dans l'organisation du magasin spécifié. Lorsqu'une stratégie implique un rôle et que vous ne spécifiez pas de magasin, le gestionnaire de stratégies évalue si l'utilisateur en cours a le rôle spécifié dans une organisation. Si au moins une stratégie applicable accorde l'accès, la vérification d'accès au niveau de la commande est passée et le gestionnaire de stratégies poursuit à l'étape suivante pour commencer à vérifier l'autorisation au niveau de la ressource. Inversement, si aucune des politiques applicables n'accorde l'accès au niveau de la commande, le gestionnaire de stratégies renvoie et refuse l'accès.

validateParameters()

Vérifie et résout les paramètres initiaux.

Remarque : Puisque cette méthode est utilisée après le contrôle d'accès au niveau de la commande, mais avant l'appel getResources(), la logique de validateParameters() peut être utilisée pour résoudre les données utilisées dans getResources().

getResources()

Renvoie un vecteur d'accès qui est un vecteur de paires ressource-action.

Si rien n'est renvoyé, la vérification du contrôle d'accès au niveau de la ressource n'est pas effectuée. S'il existe des ressources qui doivent être protégées, un vecteur d'accès (composé de paires ressource-action) doit être renvoyé.

Chaque resource est une instance d'un objet protégeable (objet qui implémente l'interface com.ibm.commerce.security.Protectable). Dans de nombreux cas, la ressource est un bean d'accès.

Un bean d'accès ne peut pas implémenter l'interface com.ibm.commerce.security.Protectable. Cependant, la vérification de contrôle d'accès peut toujours se produire si le bean d'entreprise correspondant est protégé, conformément aux informations incluses dans la rubrique Mise en œuvre du contrôle d'accès dans les beans d'entreprise.

L'action est une chaîne qui représente l'opération à effectuer sur la ressource. Dans la plupart des cas, l'action est le nom d'interface de l'instruction, qui est supposé si aucune action n'est spécifiée lors de l'ajout de ressources au vecteur.

isAllowed() [niveau de ressource]

Les composants runtime déterminent si l'utilisateur a accès au niveau de la ressource à toutes les paires ressource-action spécifiées par getResources().

getOwner() [niveau de ressource]

La ressource renvoie le memberId de son propriétaire. Le memberID détermine quelles stratégies s'appliquent.

getAndApplyApplicablePolicies() [niveau de ressource]

Le gestionnaire de stratégies de contrôle d'accès recherche les stratégies applicables, puis les applique. Si au moins une stratégie par paire ressource-action qui accorde à l'utilisateur l'autorisation d'accéder à la ressource est trouvée, l'accès est accordé. Sinon, l'accès est refusé.

fullfils()

Si une stratégie applicable a une relation ou un groupe de relations spécifié, une vérification est effectuée sur la ressource pour voir si le membre satisfait à la relation spécifiée en ce qui concerne la ressource.

performExecute()

Logique commerciale de l'instruction.

isRetriable()

Vérifie si la commande peut faire l'objet d'une nouvelle tentative au cas où une ECSystemException est émise par l'appel de performExecute().