Rôles d'administration et autorisation du service de nommage
WebSphere Application Server étend le contrôle d'accès fondé sur les rôles de la sécurité Java™ EE (Java 2 Platform, Enterprise Edition) afin de protéger les sous-systèmes de nommage et d'administration du produit.
Rôles d'administration
Un certain nombre de rôles d'administration sont définis pour fournir les différents droits requis afin d'exécuter les fonctions d'administration de WebSphere Application Server à partir de la console d'administration ou de l'interface de scriptage de gestion système appelée wsadmin. Les règles d'autorisation s'appliquent uniquement lorsque la sécurité administrative est activée. Le tableau suivant décrit les rôles d'administration :
Rôle | Description |
---|---|
Moniteur | La personne ou le groupe ayant le rôle de Moniteur possède le moins de privilèges. Un moniteur peut effectuer les tâches suivantes :
|
Configurateur | Un individu ou un groupe utilisant le rôle de configurateur bénéficie des
privilèges du moniteur et de la capacité de modifier la configuration WebSphere Application
Server. Le configurateur peut effectuer toutes les tâches de configuration quotidiennes. Par exemple, un configurateur peut accomplir les tâches suivantes :
|
Opérateur | Une personne ou groupe ayant le rôle Opérateur bénéficie des privilèges du moniteur et il peut en plus modifier l'état de l'environnement d'exécution. Par exemple, un opérateur peut accomplir les tâches suivantes :
|
Administrateur | Un individu ou groupe qui utilise le rôle Administrateur dispose des droits de l'opérateur et du configurateur auxquels s'ajoutent des droits supplémentaires propres à l'administrateur. Il peut par exemple effectuer les opérations suivantes :
Remarque :
Un administrateur ne peut pas mapper d'utilisateurs ni de groupes aux rôles d'administration. Pour plus d'informations sur l'affectation de droits de gestion du référentiel fédéré aux utilisateurs auxquels le rôle d'administrateur de WebSphere Application Server n'a pas été attribué, reportez-vous à la rubrique Mapping users and groups to roles for assigning federated repository management rights de la section Providing security. |
AdminSecurityManager | Seuls les utilisateurs auxquels ce rôle a été octroyé peuvent mapper des utilisateurs à des rôles d'administration. De plus, lorsqu'une sécurité administrative à granularité fine est appliquée, seuls les utilisateurs auxquels ce rôle a été octroyé peuvent gérer des groupes d'autorisation. Pour plus d'informations, voir Rôles d'administration. |
Responsable du déploiement | Les utilisateurs auxquels ce rôle a été octroyé peuvent effectuer des actions de configuration et des opérations d'exécution sur des applications. |
Auditeur | Les utilisateurs qui se voient accorder ce rôle peuvent
afficher et modifier les paramètres de configuration du sous-système d'audit de sécurité. Par exemple, un auditeur peut effectuer les tâches suivantes :
|
Rôle | Description |
---|---|
iscadmins | Ce rôle n'est disponible que pour les utilisateurs de la console d'administration, pas pour les utilisateurs wsadmin. Les utilisateurs qui reçoivent ce rôle possèdent des privilèges administrateur pour la gestion des utilisateurs et des groupes dans les référentiels fédérés. Par exemple, un utilisateur possédant le rôle iscadmins peut effectuer les tâches suivantes :
|
Rôle | Description |
---|---|
Responsable du déploiement | Ce rôle n'est disponible que pour les utilisateurs wsadmin, pas pour les utilisateurs de la console d'administration. Les utilisateurs auxquels ce rôle a été octroyé peuvent effectuer des actions de configuration et des opérations d'exécution sur des applications. |
Lorsque la sécurité administrative est activée, le contrôle d'accès basé sur les rôles du sous-système d'administration est appliqué. Le sous-système d'administration inclut le serveur de sécurité, la console d'administration, l'outil de scriptage wsadmin et tous les Mbeans JMX (Java Management Extensions). Lorsque la sécurité administrative est activée, les utilisateurs doivent fournir des données d'authentification dans la console d'administration et l'outil de scriptage. Par ailleurs, la console d'administration est conçue de sorte que les fonctions de contrôle affichées dans l'interface soient modifiées, conformément aux rôles de sécurité de l'utilisateur. Par exemple, un utilisateur possédant uniquement le rôle moniteur ne pourra consulter que les données de configuration non sensibles. S'il possède le rôle opérateur, il peut changer l'état du système.
Lorsque vous utilisez un registre différent (le registre LDAP au lieu d'un registre registre fédéré, par exemple), veillez à supprimer les informations liées au registre précédemment configuré concernant les utilisateurs et les groupes de la console.
Les boîtes de dialogue de personnalisation de la sécurité de WebSphere Application Server
pour z/OS indiquent au sous-système d'administration d'accepter les identités MVS de
toutes les tâches lancées du système WebSphere Application Serve (par exemple,
contrôleurs, processus servants, etc) en tant qu'administrateurs WebSphere et l'identité
d'administrateur configurée. Si un référentiel fédéré, un registre LDAP (Lightweight Directory Access Protocol) autonome ou un registre personnalisé autonome est spécifié, les identités du serveur configuré sont utilisées pour les travaux exécutés par le système plutôt que pour les travaux exécutés par les identités de tâche démarrée.
![[z/OS]](../images/ngzos.gif)
![[z/OS]](../images/ngzos.gif)
- Le code d'exécution du serveur WebSphere Application Server, qui s'exécute sous l'identité du serveur, requiert une autorisation pour certaines opérations d'exécution. Vous pouvez indiquer explicitement l'identité du serveur et le mot de passe, ou l'identité peut être générée automatiquement. Dans le premier cas, l'identité du serveur est un utilisateur valide contenu dans le registre. Dans le deuxième cas, utilisez la fonction internalServerId pour générer automatiquement l'identité du serveur. Le panneau de configuration de chaque registre d'utilisateurs vous permet de faire ce choix. Dans le cas d'une fonction internalServerId, indiquez l'ID administrateur, ou adminID, dans la zone Nom d'utilisateur administratif principal. Cette valeur adminID est un utilisateur valide contenu dans le registre ; le mot de passe associé à cet ID n'est pas obligatoire et il n'est pas sauvegardé dans la configuration. Voir "ID de serveur interne" dans la section ci-dessous.
- Si aucun utilisateur ou groupe explicite n'est affecté aux rôles d'administration, vous pouvez vous connecter à la console d'administration ou à l'outil de scriptage wsadmin à l'aide de l'identité du serveur, ou de l'adminID si vous utilisez la fonction internalServerId, afin d'exécuter les opérations d'administration et d'affecter d'autres utilisateurs ou groupes aux rôles d'administration. Cela est possible car l'identité du serveur (ou l'adminID) est affectée automatiquement au rôle adminsecuritymanager. Seuls les utilisateurs/groupes associés au rôle adminsecuritymanager peuvent mapper les utilisateurs/groupes vers tous les rôles d'administration. Une fois connecté à l'aide de l'identité du serveur (ou adminID), vous pouvez exécuter les opérations suivantes, conformément aux règles de sécurité administrative :
- Changer l'ID et le mot de passe du serveur
- Activer ou désactiver WebSphere Application Server sécurité administrative
- Appliquer la sécurité Java 2 à l'aide de l'option Utiliser la sécurité Java 2 pour limiter l'accès aux applications par les ressources locales,
- Changer le mot de passe LTPA ou générer des clés
- Aucune configuration particulière n'est requise pour activer l'identité du serveur, comme indiqué lors de l'activation de la sécurité administrative à des fins d'administration, car cette identité est automatiquement mappée vers le rôle d'administrateur. Vous pouvez ajouter ou supprimer des utilisateurs et des groupes des rôles d'administration à partir de la console d'administration WebSphere Application Server. Vous devez toutefois redémarrer le serveur pour que les modifications soient prises en compte. La meilleure méthode consiste à mapper un groupe et non plusieurs utilisateurs, vers des rôles d'administration car l'administration est alors simplifiée et plus flexible. En mappant un groupe vers un rôle d'administration, l'ajout d'utilisateurs dans le groupe ou leur suppression du groupe se produit hors de WebSphere Application Server et il n'est pas nécessaire de redémarrer le serveur pour que la modification prenne effet.
Lorsque la sécurité administrative est activée,
les serveurs WebSphere Application Server s'exécutent sous l'identité du serveur défini dans la configuration du registre d'utilisateurs actifs. Même s'il n'apparaît pas
dans la console d'administration et dans d'autres outils, un sujet spécial
Server est mappé vers le rôle administrateur. Le code d'exécution du serveur WebSphere Application
Server, qui s'exécute sous l'identité du serveur, requiert une autorisation pour les opérations d'exécution. Dans le cas contraire, vous recevez des rôles d'administration,
l'un d'eux permettant de se connecter à la console d'administration ou à
l'outil de scriptage wsadmin avec l'identité du serveur pour réaliser des
opérations administratives et affecter d'autres utilisateurs ou groupes à
des rôles d'administration. Sachant que l'identité du serveur est par défaut
attribuée au rôle administrateur, les stratégies de sécurité
administratives requiert ce rôle pour effectuer les opérations suivantes :
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Changer l'ID et le mot de passe du serveur
- Activer ou désactiver WebSphere Application Server sécurité administrative
- Appliquer la sécurité Java 2 à l'aide de l'option Utiliser la sécurité Java 2 pour limiter l'accès aux applications par les ressources locales,
- Changer le mot de passe LTPA ou générer des clés
- Affecter des utilisateurs et des groupes à des rôles d'administration
- Nécessitent un administrateur dont l'identité diffère de celle de l'utilisateur du serveur, afin d'améliorer la capacité d'audit des tâches d'administration. Le nom d'utilisateur indique un utilisateur disposant de privilèges d'administration défini dans le système d'exploitation local.
- Font la distinction entre l'identité du serveur et celle de l'administrateur, afin d'améliorer la capacité d'audit. L'identité de l'utilisateur du serveur permet d'authentifier les communications serveur-serveur.
- L'ID de serveur interne permet la génération automatique de l'identité de l'utilisateur pour l'authentification serveur-serveur. La génération automatique de l'identité du serveur prend en charge la capacité d'audit optimisée des cellules pour les noeuds version 6.1 ou les versions suivantes uniquement. La version 6.1 de WebSphere Application Server permet d'enregistrer l'ID de serveur généré en interne, car le modèle de sécurité WCCM (WebSphere Common Configuration Model) contient une nouvelle balise, internalServerId.
Vous n'avez pas besoin de spécifier un ID utilisateur et un mot de passe de serveur pendant la configuration de la sécurité, sauf sans un environnement à cellules mixtes. Un ID de serveur généré en interne ajoute un niveau de protection supplémentaire à l'environnement serveur car le mot de passe du serveur n'est pas exposé comme dans les versions antérieures à la version 6.1. Toutefois, pour assurer la compatibilité amont, vous devez indiquer l'ID du serveur si vous utilisez des versions antérieures de WebSphere Application Server.
Lorsque vous activez la sécurité, vous pouvez affecter un ou plusieurs utilisateurs/groupes à des rôles de nommage. Pour plus d'informations, voir Affectation d'utilisateurs à des rôles de nommage. Toutefois, avant d'affecter des utilisateurs à des rôles de nommage, configurez le registre d'utilisateurs actif. La validation des utilisateurs et des groupes dépend du registre d'utilisateurs actif. Pour obtenir plus d'informations, reportez-vous à la section Configuration des registres d'utilisateurs.
- Possibilité de mappage d'un sujet spécial vers les rôles d'administration. Un sujet spécial est une généralisation d'une classe particulière d'utilisateurs. Les sujets spéciaux AllAuthenticated et AllAuhenticatedInTrustedRealms (en cas d'interaction entre les domaines) signifient que le refus d'accès du rôle d'administration garantit que l'utilisateur à l'origine de la requête est au moins authentifié. Le sujet spécial Everyone signifie que tous les utilisateurs, authentifiés ou non, peuvent effectuer l'action comme si la sécurité n'était pas activée.
Autorisation du service de nommage
La sécurité CosNaming propose une granularité développée du contrôle de sécurité sur les fonctions CosNaming. Les fonctions CosNaming sont disponibles sur les serveurs CosNaming, tel que WebSphere Application Server. Elles affectent le contenu de l'espace de noms WebSphere Application Server. Il existe généralement deux situations dans lesquelles les programmes client provoquent des appels CosNaming : lors d'un appel JNDI (Java Naming and Directory Interface) ou lorsque des clients CORBA (Common Object Request Broker Architecture) appellent directement des méthodes CosNaming.
- CosNamingRead
- CosNamingWrite
- CosNamingCreate
- CosNamingDelete
- CosNamingRead
- Vous pouvez interroger l'espace de noms WebSphere Application Server à l'aide, par exemple, de la méthode de recherche JNDI. Le sujet spécial, Everyone, constitue la stratégie par défaut de ce rôle.
- CosNamingWrite
- Vous pouvez effectuer des opérations d'écriture, notamment des opérations JNDI bind, rebind, unbind et CosNamingRead. Ce rôle ne peut pas être affecté aux sujets car ces derniers constituent des règles par défaut.
- CosNamingCreate
- Vous pouvez créer des objets dans l'espace de noms par le biais d'opérations JNDI, telles que createSubcontext et CosNamingWrite. La règle par défaut n'affecte pas de sujet à ce rôle.
- CosNamingDelete
- Vous pouvez supprimer des objets dans l'espace de noms, par exemple à l'aide de la méthode JNDI destroySubcontext et des opérations CosNamingCreate. La règle par défaut n'affecte pas de sujet à ce rôle.
Lorsque vous configurez un registre de système d'exploitation local avec WebSphere Application
Server pour z/OS, des facteurs supplémentaires sont à prendre en compte. Pour plus d'informations, voir Sélection d'un registre ou d'un référentiel et
Configuration des registres du système d'exploitation local.
Si vous spécifiez des référentiels fédérés, un registre LDAP autonome ou un registre personnalisé autonome, vous devez supprimer la personnalisation du système d'exploitation local en supprimant du groupe de la console l'identité de l'administrateur et du groupe de configuration WebSphere Application Server préconfiguré et en supprimant les utilisateurs de la console.
Un sujet spécial Server est par défaut attribué aux quatre rôles CosNamingA. Ce sujet permet à un processus WebSphere Application Server, qui s'exécute sous l'identité du serveur, d'accéder à toutes les opérations CosNaming. Il n'est ni affiché ni modifiable dans la console d'administration et les autres outils d'administration.
Aucune configuration particulière n'est requise pour activer l'identité du serveur, comme indiqué lors de l'activation de la sécurité administrative à des fins d'administration, car cette identité est automatiquement mappée vers le rôle d'administrateur.
Les utilisateurs, les groupes ou les sujets
spéciaux AllAuthenticated et Everyone peuvent être ajoutés aux rôles de nommage ou en être
supprimés à partir de la console d'administration WebSphere Application Server à tout moment. Toutefois, le serveur doit être redémarré pour que les modifications prennent
effet.
Aucune configuration n'est requise pour activer l'identité du serveur comme indiqué lors de l'activation de la sécurité administrative à des fins d'administration car l'identité du serveur est automatiquement mappée vers le rôle d'administrateur. Les utilisateurs, les groupes ou les sujets
spéciaux AllAuthenticated et Everyone peuvent être ajoutés aux rôles de nommage ou en être
supprimés à partir de la console d'administration WebSphere Application Server à tout moment. Toutefois, le serveur doit être redémarré pour que les modifications prennent
effet. Lorsque l'autorisation SAF est sélectionnée, il n'est pas nécessaire de
redémarrer le serveur pour autoriser d'autres utilisateurs ou groupes.
La meilleure méthode consiste à mapper des groupes ou un des sujets spéciaux et non plusieurs utilisateurs, vers des rôles de nommage car l'administration est simple à long terme. En mappant un groupe vers un rôle de nommage, l'ajout d'utilisateurs dans le groupe ou leur suppression du groupe se produit hors de WebSphere Application Server et il n'est pas nécessaire de redémarrer le serveur pour que la modification prenne effet.
Les règles d'autorisation CosNaming ne s'appliquent que si la sécurité administrative est activée. Lorsque la sécurité administrative est activée, toute tentative d'exécution d'une opération CosNaming par un utilisateur ne disposant pas du rôle approprié génère une exception org.omg.CORBA.NO_PERMISSION sur le serveur CosNaming.
Chaque fonction CosNaming est attribuée à un seul rôle. C'est pourquoi, les utilisateurs qui disposent
du rôle CosNamingCreate ne peuvent pas interroger l'espace de noms sauf si
le rôle CosNamingRead leur a aussi été attribué. Dans la plupart des cas,
un créateur doit disposer de trois rôles : CosNamingRead, CosNamingWrite
et CosNamingCreate. L'attribution de rôles CosNamingRead et CosNamingWrite
pour l'exemple de créateur a été incluse dans le rôle CosNamingCreate.
Dans la plupart des cas, les administrateurs WebSphere Application
Server n'ont pas besoin de modifier les attributions de rôle pour chaque
utilisateur ou groupe lorsqu'ils passent de cette version à une version
précédente.
Bien qu'il soit possible de réduire de manière considérable l'accès à l'espace de noms en modifiant la règle par défaut, cette opération peut entraîner des exceptions org.omg.CORBA.NO_PERMISSION inattendues lors de l'exécution. Généralement, les applications Java EE accèdent à l'espace de noms et l'identité qu'ils utilisent est celle de l'utilisateur authentifié par WebSphere Application Server lors de l'accès à l'application Java EE. Sauf si le fournisseur d'applications Java EE communique clairement les rôles de nommage attendus, soyez vigilant lors de la modification des règles d'autorisation d'attribution de nom par défaut.