Autorisation basée sur des rôles

Utilisez les informations d'autorisation pour déterminer si un appelant dispose des droits nécessaires pour faire appel à un service.

Le schéma suivant décrit le processus utilisé lors d'une autorisation.

L'accès aux ressources Web depuis un client Web est géré par un collaborateur Web. L'accès aux ressources EJB (Enterprise JavaBeans) depuis un client Java (qu'il s'agisse d'un servlet ou d'un bean enterprise) est géré par un collaborateur EJB. Le collaborateur EJB et le collaborateur Web extraient les données d'identification du client depuis l'objet ORB (object request broker) en cours. Les données d'identification du client sont définies pendant le processus d'authentification comme des informations reçues dans l'objet ORB en cours. La ressource et les informations de connexion reçues sont présentées au gestionnaire d'accès WSAccessManager qui vérifie si l'accès à la ressource demandée est autorisé au client.

L'accès à une ressource Web à partir d'un client Web est traité par un collaborateur Web. L'accès aux ressources EJB (Enterprise JavaBeans) à partir d'un client Java™, qu'il s'agisse d'un bean enterprise ou d'un servlet, est traité par un collaborateur EJB. Le collaborateur EJB et le collaborateur Web extraient les données d'identification du client à partir de l'objet ORB en cours. Les données d'identification du client sont définies lors de la procédure d'authentification comme données d'identification reçues dans l'objet ORB en cours. La ressource et les données d'identification sont présentés au gestionnaire des accès WSAccessManager pour vérifier si le client est autorisé à accéder à la ressource demandée.

Le gestionnaire d'accès se compose de deux modules principaux :
  • Le module Droits d'accès aux ressources, qui détermine les rôles nécessaires pour une ressource donnée. Ce module utilise une table d'affectation des ressources aux rôles générée par le module d'exécution de la sécurité, lors du démarrage de l'application. Pour générer la table de mappage des ressources vers les rôles, l'environnement d'exécution de la sécurité lit le descripteur de déploiement des beans enterprise ou du module Web (fichier ejb-jar.xml ou web.xml).
  • Le module Table d'autorisations, qui consulte une table de mappage des rôles vers les utilisateurs et les groupes pour déterminer si un client dispose des rôles nécessaires. Cette table de mappage, également appelée table d'autorisations est créée par le module d'exécution de la sécurité lors du démarrage de l'application.

    Pour générer la table d'autorisations, l'environnement d'exécution de la sécurité lit le fichier de liaison d'application ibm-application-bnd.xmi ou ibm-application-bnd.xml, le cas échéant.

    [z/OS]La table d'autorisations peut également être générée lors de l'accès aux profils EJBROLE au moment de l'autorisation à l'aide d'un utilitaire d'accès de sécurité (tel que RACF).

    Configurations prises en charge Configurations prises en charge: Pour les fichiers de liaison et d'extension IBM®, l'extension de nom de fichier .xmi ou .xml est différente selon que vous utilisiez un module ou une application antérieure à Java EE 5 ou un module ou une application ultérieure à Java EE 5. Un fichier de liaison ou d'extension IBM porte le nom ibm-*-ext.xmi ou ibm-*-bnd.xmi où * correspond au fichier d'extension ou de liaison, tel app, application, ejb-jar ou web. Les conditions suivantes s'appliquent :
    • Pour une application ou un module qui utilise une version Java EE antérieure à la version 5, l'extension de fichier doit être .xmi.
    • Pour une application ou un module qui utilise Java EE 5 ou version ultérieure, l'extension de fichier doit être .xml. Si des fichiers .xmi sont inclus dans l'application ou le module, le produit les ignore.

    Toutefois, un module Java EE 5 ou version ultérieure peut exister dans une application qui inclut des fichiers antérieurs à Java EE 5 et utilise l'extension de nom de fichier .xmi.

    Les fichiers ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et ibm-portlet-ext.xmi continuent d'utiliser les extensions de fichier .xmi.

    sptcfg

Utilisez les informations d'autorisation pour déterminer si un appelant dispose des droits nécessaires pour faire appel à un service. Vous pouvez stocker ces informations de différentes manières. Par exemple, avec chaque ressource, vous pouvez stocker une liste de contrôle d'accès répertoriant les utilisateurs et les droits d'accès associés. Vous pouvez également associer une liste de ressources et les droits correspondants de chaque utilisateur. Il s'agit d'une liste des droits.

WebSphere Application Server utilise le modèle d'autorisation de la plateforme Java 2 Platform, Enterprise Edition (J2EE). Dans ce modèle, les informations d'autorisation sont organisées de la manière suivante :

Lors de l'assemblage d'une application, le développeur accorde à un ou plusieurs rôles le droit d'appeler des méthodes. Un rôle est un ensemble de droits d'accès. Par exemple, dans une application bancaire, il peut s'agir des rôles de guichetier, de chargé de clientèle, d'employé de bureau, etc. Le rôle de guichetier peut se voir accorder le droit d'exécuter des méthodes en rapport avec les manipulations de sommes d'argent sur un compte courant, telles que les méthodes utilisées pour les retraits et les dépôts (dans l'exemple ci-après, il s'agit respectivement des méthodes withdraw et deposit). Le rôle de guichetier n'est pas autorisé à clôturer les comptes. Ce droit est détenu par le rôle de chargé de clientèle. L'assembleur de l'application définit la liste des droits sur les méthodes accordées à chaque rôle. Cette liste est ensuite stockée dans le descripteur de déploiement de l'application. A partir de Java EE7, un nom de rôle spécial "**" est introduit. Ce rôle indique que l'accès est accordé lorsqu'un utilisateur est authentifié.

Trois sujets spéciaux ne sont pas définis par le modèle J2EE : AllAuthenticatedUsers, AllAuthenticatedInTrustedRealms et Everyone. Un sujet spécial est une entité définie par le produit en dehors du registre des utilisateurs. Il permet de représenter de façon générique une classe d'utilisateurs ou de groupes dans le registre.

Eviter les incidents Eviter les incidents: Lorsque WebSphere Application Server est configuré à l'aide de SAF, les sujets spéciaux sont ignorés. Ces fonctions sont disponibles dans SAF. Les fonctions sont simulées par la définition de l'ID utilisateur non authentifié dans RACF avec la propriété RESTRICTED. Si un profil EJBROLE est créé avec l'UACC READ, tous les utilisateurs authentifiés disposent de droits d'accès à l'exception de l'ID utilisateur non authentifié.gotcha

Lors du déploiement d'une application, les utilisateurs ou groupes d'utilisateurs réels sont affectés aux rôles définis. Lorsqu'un utilisateur est affecté à un rôle, il reçoit automatiquement tous les droits sur les méthodes qui ont été accordés à ce rôle.

[z/OS]Selon votre environnement, il peut exister certaines restrictions : Par exemple, si vous utilisez SAF, les vérifications sont toujours effectuées par rapport à la base de données SAF. Si aucune authentification n'est effectuée avant une vérification d'accès par rapport à un rôle donné, la vérification est réalisée à l'aide d'une identité SAF par défaut. L'accès n'est pas autorisé sauf si un ID utilisateur par défaut est configuré dans la propriété com.ibm.SAF.authorization.

[AIX Solaris HP-UX Linux Windows][IBM i]La personne chargée du déploiement de l'application (que l'on appellera le déployeur) n'a pas besoin de connaître les méthodes individuelles de l'application ni de comprendre leur fonctionnement. L'assembleur de l'application a simplifié son travail en définissant les liens entre rôles et méthodes. Au lieu de travailler directement sur un ensemble de méthodes, le déployeur manipule des rôles prédéfinis qui représentent des regroupements sémantiques de ces méthodes.

[z/OS]L'administrateur est responsable de la gestion de ces rôles.

Vous pouvez attribuer plusieurs rôles aux utilisateurs. Les droits accordés à un utilisateur correspondent à l'ensemble des droits accordés à chaque rôle. De plus, si le mécanisme d'authentification admet la constitution de groupes d'utilisateurs, ces groupes peuvent être affectés aux rôles définis. L'affectation d'un groupe à un rôle a le même effet que l'affectation d'un utilisateur individuel à un rôle.

[AIX Solaris HP-UX Linux Windows][IBM i]Lors du déploiement, il est recommandé d'affecter des groupes plutôt que des utilisateurs isolés, car cette procédure présente certains avantages :
  • Amélioration des performances lors de la vérification d'autorisation. Il existe généralement beaucoup moins de groupes que d'utilisateurs.
  • Flexibilité accrue en utilisant à l'appartenance à un groupe pour contrôler l'accès aux ressources.
  • Ajout et suppression d'utilisateurs appartenant à des groupes hors de l'environnement du logiciel. Il est recommandé d'exécuter cette action au lieu d'ajouter et de supprimer les utilisateurs affectés aux rôles WebSphere Application Server. Arrêtez et relancez l'application d'entreprise pour valider les modifications. Dans un environnement de production, cette action peut interrompre durablement votre activité.

[z/OS]Lors du déploiement, il est recommandé d'affecter des groupes plutôt que des utilisateurs isolés. Si vous utilisez des liaisons au lieu d'utiliser des rôles EJBROLES SAF pour les autorisations et que vous devez modifier la valeur de la liaison, vous devez redémarrer le serveur pour récupérer les nouvelles valeurs. Si vous utilisez des rôles EJBROLES SAF, le serveur d'applications détecte automatiquement les modifications. Pour plus d'informations, voir System Authorization Facility for role-based authorization

Au moment de l'exécution, WebSphere Application Server autorise ou non l'exécution d'une demande entrante d'après les informations d'identification de l'utilisateur demandeur et le ou les rôles auxquels cet utilisateur est affecté. Si l'utilisateur est affecté à l'un des rôles qui possèdent le droit d'exécuter la méthode demandée, la demande est autorisée et satisfaite. Dans le cas contraire, elle est rejetée.

L'approche J2EE correspond à une approche déclarative de l'autorisation mais elle reconnaît également que toutes les situations ne peuvent pas être traitées de cette manière. Dans de telles situations, des méthodes sont fournies pour définir par programme les informations sur les utilisateurs et les rôles. Dans le cas des beans EJB (enterprise beans), les deux méthodes suivantes sont supportées par WebSphere Application Server :
  • getCallerPrincipal : Cette méthode extrait les données d'identification de l'utilisateur.
  • isCallerInRole : Cette méthode vérifie les données d'identification de l'utilisateur par rapport à un rôle spécifique.
Dans le cas des servlets, les méthodes suivantes sont supportées par WebSphere Application Server :
  • getRemoteUser
  • isUserInRole
  • getUserPrincipal

Dans leur finalité, ces méthodes correspondent aux méthodes des beans enterprise.

Pour plus d'informations sur le modèle d'autorisation de la sécurité J2EE, reportez-vous au site Web : http://java.sun.com


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_rolebased
Nom du fichier : csec_rolebased.html