Sécurité fondée sur les rôles avec le programme Tivoli Access Manager intégré

Le Java™ Platform, Enterprise Edition ( Java EE ) le modèle d'autorisation basé sur les rôles utilise les concepts de rôles et de ressources. Un exemple est fourni ici.

Tableau 1. Les rôles .

Ce tableau est un exemple de sécurité basée sur les rôles avec Tivoli Access Manager intégré.
Rôles getBalance deposit closeAccount
Guichetier accordé accordé  
Caissier accordé    
Superviseur     accordé

Dans l'exemple d'application bancaire présenté dans le tableau ci-dessus, trois rôles sont définis : le guichetier, le caissier et le superviseur. Les droits d'accès nécessaires pour utiliser les méthode getBalance, deposit, closeAccount de l'application sont mappés à ces rôles. Dans cet exemple, vous pouvez constater que les utilisateurs dotés du rôle Superviseur peuvent exécuter la méthode closeAccount alors que les deux autres rôles ne peuvent pas exécuter cette méthode.

Le terme, principal, dans WebSphere® La sécurité d'Application Server fait référence à une personne ou à un processus qui exécute des activités. Les groupes sont des ensembles logiques de principaux configurés dans WebSphere Application Server pour faciliter la mise en oeuvre des mécanismes de sécurité. Les rôles peuvent être mappées à des principaux et/ou des groupes.

Tableau 2. Méthodes de rôles . L'entrée appelée dans le tableau ci-après indique que le principal ou le groupe peut appeler n'importe quelle méthode associée à ce rôle.
Principal/Groupe Guichetier Caissier Superviseur
TellerGroup Appel    
CashierGroup   Appel  
SupervisorGroup      
Franck : un principal qui n'est membre d'aucun des groupes précédents   Appel Appel
Dans l'exemple précédent, le principal Frank peut appeler les méthodes getBalance et closeAccount mais ne peut pas appeler la méthode deposit car celle-ci n'est pas associée au rôle Caissier ou Superviseur.

Au moment du déploiement de l'application, le fournisseur JACC (Java Authorization Contract for Container) de Tivoli Access Manager remplit l'espace objet protégé par Tivoli Access Manager avec toutes les informations de stratégie de sécurité contenues dans le descripteur de déploiement d'application et/ou les annotations. Ces informations de sécurité sont utilisées pour déterminer si l'accès doit être accordé lorsque la ressource WebSphere Application Server est demandée.

Par défaut, le contrôle d'accès de Tivoli Access Manager est effectué à l'aide du nom du rôle, du nom de la cellule, du nom de l'application et du nom du module.

Les listes de contrôle des accès de Tivoli Access Manager (ACL) déterminent les rôles d'application affectés à un principal. Les listes ACL sont connectées à l'application dans l'espace d'objets protégé par Tivoli Access Manager lors du déploiement de l'application.

Les mappages entre le principal et le rôle sont gérés à partir de la console d'administration de WebSphere Application Server et ne sont jamais modifiés avec Tivoli Access Manager. Les mises à jour directes des listes ACL sont effectuées uniquement par les utilisateurs chargés de la sécurité et de l'administration.

La série d'événements suivante se produit :
  1. Lors du déploiement de l'application, les informations relatives aux règles sont envoyées au fournisseur JACC de Tivoli Access Manager. Les informations contiennent les mappages effectués entre les droits d'accès et les rôles, les rôles et les principaux et les rôles et les groupes.
  2. Le fournisseur JACC de Tivoli Access Manager convertit les informations dans le format approprié et les transmet au serveur de règles de Tivoli Access Manager.
  3. Le serveur de règles ajoute les entrées à l'espace d'objets de Tivoli Access Manager pour représenter les rôles définis pour l'application et les mappages entre les droits d'accès et les rôles. Un droit d'accès est représenté sous la forme d'un objet protégé par Tivoli Access Manager et le rôle affecté à cet objet est associé sous forme d'attribut étendu.