![[z/OS]](../images/ngzos.gif)
Mécanisme d'autorisation SAF (System Authorization Facility) fondé sur les rôles
Vous disposez de trois options lors de l'affectation des rôles : (1) WebSphere Application Server l'autorisation, dans laquelle la gestion des autorisations est exécutée dans l'administration WebSphere Administration en utilisant le rôle Sécurité dans le panneau de mappage d'utilisateur et de groupe de la console d'administration. (2) L'utilitaire SAF, pour une autorisation par rôle (option disponible uniquement dans WebSphere Authorization Facility for z/OS), qui utilise une autorisation SAF pour les rôles J2EE ; (3) Des fournisseurs d'autorisations externes utilisant des interfaces JACC connectables. Lorsque WebSphere Application Server est configuré pour l'utilisation de l'autorisation SAF, la gestion des autorisations est effectuée via les fonctions SAF et l'utilisateur ou le groupe de gestion des rôles J2EE, au sein de l'administration WebSphere, sont ignorés. La classe SAF EJBROLE est utilisée (par exemple, via le profil RACF EJBROLE) pour contrôler les accès d'un client aux rôles Java™ 2 Platform Enterprise Edition (J2EE) dans les applications EJB et Web, y compris l'application de la console d'administration WebSphere Application Server.
- Si l'autorisation SAF est sélectionnée dans la console d'administration, elle a priorité sur tous les autres mécanismes d'autorisation (comme le mécanisme d'autorisation Tivoli Access Manager). Pour plus d'informations, voir Récapitulatif des contrôles.
- Lorsque l'autorisation SAF est activée, quel que soit le niveau, l'autorisation est toujours effectuée par le gestionnaire de sécurité du système d'exploitation (RACF ou produit équivalent). C'est-à-dire que les utilisateurs doivent être authentifiés avec un ID utilisateur de gestionnaire de sécurité (RACF) ou qu'un module de mappage SAF doit être utilisé. Voir Remarque SAF (System Authorization Facility) pour le système d'exploitation et les niveaux d'application pour plus d'informations.
- Lorsque le mécanisme d'autorisation SAF est sélectionné pendant la personnalisation des systèmes, les profils EJBROLE d'administration de tous les rôles d'administration sont définis par les travaux RACF générés à l'aide de la boîte de dialogue de personnalisation, et le mécanisme d'autorisation SAF peut servir de mécanisme d'autorisation pour l'ensemble des registres d'utilisateurs. Voir Contrôle de l'accès aux utilisateurs de la console lorsqu'un registre de système d'exploitation local est utilisé pour plus d'informations.
- Lors de la configuration de l'autorisation SAF, la propriété com.ibm.security.SAF.authorization a true pour valeur et ce sont les profils SAF EJBROLE qui servent à contrôler l'accès aux rôles d'administration. Voir Autorisation de l'accès pour des rôles d'administration pour en savoir davantage sur l'autorisation des accès aux rôles d'administration.
- Lorsque l'autorisation SAF est activée, toute valeur indiquée dans les utilisateurs et les groupes de la console est ignorée. Il en va de même pour le panneau Mapper les rôles de sécurité aux utilisateurs ou groupes de la console d'administration qui est ignoré lui aussi. Pour plus d'informations, voir Rôles d'administration et autorisation du service de nommage.
- Tous les utilisateurs et Tous les utilisateurs authentifiés sont ignorés puisque leur gestion s'effectue dans RACF. Voir Remarque SAF (System Authorization Facility) pour le système d'exploitation et les niveaux d'application ainsi que Mappage rôle de sécurité-utilisateur/groupe pour plus d'informations.
- Lorsque l'autorisation SAF est activée, les profils SAF EJBROLE servent à contrôler l'accès aux fonctions CosNaming. Lors de la configuration du domaine de sécurité dans la boîte de dialogue de personnalisation, les rôles CosNaming sont définis par les travaux de personnalisation. Voir Remarques sur le contrôle d'accès aux rôles de nommage à l'aide du mécanisme d'autorisation SAF pour en savoir plus sur les fonctions CosNaming et l'autorisation SAF, ainsi que sur le référencement Rôles d'administration et autorisation du service de nommage.
- Lorsque le mécanisme d'autorisation SAF est activé, les profils SAF EJBROLE sont utilisés pour autoriser les rôles J2EE. Pour les registres de système d'exploitation non local, le mappage d'identités doit être configuré pour mapper les identités WebSphere Application Server vers les identités SAF. Pour plus d'informations, voir Contrôle de l'accès aux utilisateurs de la console lorsqu'un registre de système d'exploitation local est utilisé
- L'autorisation SAF pour les rôles J2EE est une tâche indépendante du déploiement d'applications. Pour plus d'informations, voir Affectation d'utilisateurs et de groupes à des rôles.
- La classe EJBROLE doit être RACLISTed. Si ce n'est pas le cas, vous devez redémarrer le serveur d'applications afin qu'il prenne en compte les changements apportés aux profils dans la classe EJBROLE.
- La spécification Servlet 3.1 définit le nom de rôle ** qui accorde des droits d'accès pour tous les utilisateurs authentifiés. Par défaut, la décision d'autorisation est prise par SAF.
- La propriété personnalisée com.ibm.websphere.security.delegateStarStarRoleAuthorization détermine si le code de sécurité accorde des droits d'accès à tous les utilisateurs authentifiés lorsque le nom de rôle est **.
- true - Le code de sécurité accorde des droits d'accès sans interagir avec la table d'autorisations enfichable.
- false - Le code de sécurité délègue la décision à la table d'autorisations enfichable. Il s'agit de la valeur par défaut.

Lorsque le mécanisme d'autorisation SAF est activé, les profils SAF EJBROLE sont utilisés pour autoriser les rôles Java EE. Pour les registres de système d'exploitation non local, le mappage d'identités doit être configuré pour mapper les identités WebSphere Application Server vers les identités SAF.
Pour activer le mécanisme d'autorisation SAF, voir Autorisation SAF (System Authorization Facility) z/OS afin d'obtenir plus d'informations.
La définition des rôles EJBROLES s'effectue au cours du processus de déploiement de l'application. Si l'ID utilisateur possède au moins un droit d'accès en lecture sur le profil EJBROLE défini qui correspond au rôle Java EE défini par l'application, l'ID utilisateur est considéré comme étant "in Role". (Ne vous laissez pas abuser par le nom EJBROLE. Ce dernier est utilisé pour les rôles Java EE dans des applications Web et EJB.)
Lorsqu'un déployeur d'application utilise un rôle dans le descripteur de déploiement du composant, le nom du rôle doit être identique à celui d'un profil EJBROLE. Un administrateur de sécurité définit des profils EJBROLE et autorise les utilisateurs ou groupes SAF à accéder aux profils. Pour qu'un rôle puisse être affecté à un utilisateur, ce dernier doit avoir un accès en lecture au profil EJBROLE ou il doit être connecté à un groupe SAF doté de ce droit d'accès.
La spécification d'un préfixe de profil SAF (ou domaine de sécurité z/OS) affecte les profils EJBROLE spécifiques utilisés par les ressources système WebSphere Application Server pour z/OS lorsque le mécanisme d'autorisation SAF est choisi. Lorsqu'un préfixe SAF est défini, les profils EJBROLE de l'application Java EE d'exécution de WebSphere Application Server pour z/OS ont la valeur de cette propriété comme préfixe. Vous pouvez ainsi déployer la même application dans des cellules différentes du même sysplex, tout en ayant la possibilité de définir des mappages rôle - utilisateur différents.
Par exemple, deux noms de rôle Java EE sont associés à l'application : juniorTellers et seniorTellers. Les noms de ces rôles contiennent à la fois des majuscules et des minuscules. Le registre SAF contient un groupe MVS appelé JTELLER et STELLER et un ID utilisateur MVS appelé BANKADM. Le groupe JTELLER autorise l'accès au rôle juniorTellers et le groupe STELLER au rôle seniorTellers. L'ID utilisateur BANKADM autorise l'accès à ces deux rôles.
Vous disposez de deux cellules, toutes deux configurées pour l'utilisation d'un préfixe de profil SAF. Les préfixes sont, respectivement, PRODCELL et TESTCELL. L'ID utilisateur TEST1 doit avoir accès aux deux rôles, mais uniquement dans l'environnement de test TESTCELL.
Si vous souhaitez déployer la même application dans les deux cellules, vous devez définir des profils distincts à l'aide d'un système RACF (ou d'un sous-système de sécurité équivalent) en procédant comme suit.
/* la classe EJBROLE doit être active ; cette étape est exécutée dans les boîtes de dialogue de personnalisation */ SETROPTS CLASSACT(EJBROLE) /* tout d'abord, définissez les rôles dans RACF */ RDEFINE EJBROLE PRODCELL.juniorTellers UACC(NONE) RDEFINE EJBROLE PRODCELL.seniorTellers UACC(NONE) RDEFINE EJBROLE TESTCELL.juniorTellers UACC(NONE) RDEFINE EJBROLE TESTCELL.seniorTellers UACC(NONE) /* autorisez les utilisateurs et groupes à accéder aux différents rôles */ PERMIT PRODCELL.juniorTellers CLASS(EJBROLE) ID(JTELLER BANKADM) ACCESS(READ) PERMIT PRODCELL.seniorTellers CLASS(EJBROLE) ID(STELLER BANKADM) ACCESS(READ) PERMIT TESTCELL.juniorTellers CLASS(EJBROLE) ID(TEST1) ACCESS(READ) PERMIT TESTCELL.seniorTellers CLASS(EJBROLE) ID(TEST1) ACCESS(READ) /* régénérez la classe EJBROLE dans RACF * SETROPTS RACLIST(EJBROLE) REFRESH"
Regroupement des rôles EJBROLES (GEJBROLE)
L'interface SAF prend également en charge une classe de regroupement pour la classe EJBROLE. Cette classe de regroupement s'appelle GEJBROLE. Elle permet en particulier d'autoriser les mêmes utilisateurs ou groupes à accéder à plusieurs rôles.
- Ajustez les descripteurs de déploiement d'application afin qu'ils soient conformes aux rôles déjà définis dans l'entreprise, tels que les gestionnaires. Ce processus utilise du temps système et génère souvent des erreurs car il nécessite un réajustement du descripteur de déploiement à chaque fois que l'application est modifiée ou réinstallée.
- Définissez les profils EJBROLE pour chacun des rôles requis par l'application. Autorisez ensuite les utilisateurs et les groupes à accéder à ces rôles. Ce processus peut s'avérer complexe pour l'administrateur car les mêmes utilisateurs et groupes peuvent disposer de droits d'accès sur des profils différents ayant des significations similaires.
- Utilisez la classe de regroupement pour éviter les problèmes les plus graves liés aux deux autres options. Vous devez malgré tout définir des profils EJBROLE pour chacun des rôles requis par l'application. Au lieu d'autoriser l'ensemble des utilisateurs et groupes identiques à utiliser les nouveaux profils, créez un profil, tel qu'un superviseur, dans la classe de regroupement et ajoutez à celle-ci l'ensemble des nouveaux profils EJBROLE. Vous pouvez autoriser tous les utilisateurs et groupes à accéder à ces rôles à partir d'un emplacement unique, tel que le profil des superviseurs. Vous pouvez limiter davantage les tâches d'administration en ajoutant le profil EJBROLE (Gestionnaires) au profil de la classe de regroupement (Superviseurs).
- Planifiez les profils de rôle organisationnel dans les profils GEJBROLE de la classe RACF.
- Créez la liste d'accès en autorisant les groupes d'utilisateurs à accéder aux profils GEJBROLE, puis ajoutez les rôles aux profils GEJBROLE.
- Un profil GEJBROLE peut contenir un seul EJBROLE.
- N'utilisez pas une combinaison de profils EJBROLE et GEJBROLE pour autoriser des utilisateurs à accéder aux rôles.
- Dans la mesure du possible, autorisez uniquement les utilisateurs à accéder aux profils GEJBROLE.
- Utilisez GEJBROLE de préférence à EJBROLE.