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 à 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 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.
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: 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 :
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.
- Le sujet AllAuthenticatedUsers permet à tous les utilisateurs authentifiés d'accéder aux méthodes protégées. Il suffit alors à un utilisateur de s'authentifier pour pouvoir accéder à la ressource protégée.
- Le sujet AllAuthenticatedInTrustedRealms permet à tous les utilisateurs externes (liés à d'autre domaines) authentifiés d'accéder à des méthodes protégées. Il suffit alors à un utilisateur de s'authentifier pour pouvoir accéder à la ressource protégée.
- Le sujet Everyone offre un accès illimité à une ressource protégée. Les utilisateurs n'ont pas besoin de s'authentifier pour pouvoir accéder aux méthodes protégées, car ce sujet spécial permet d'y accéder comme si les ressources n'étaient pas protégées.

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.
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.
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.
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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- 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é.
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.
- 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.
- 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