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 :

Tableau 1. Rôles d'administration disponibles par le biais de la console d'administration et de l'interface wsadmin.

Ce tableau répertorie les rôles d'administration disponibles par le biais de la console d'administration et de wsadmin.

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 :
  • Afficher la configuration de WebSphere Application Server.
  • Afficher l'état actuel du serveur d'applications.
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 :
  • créer une ressource.
  • mapper un serveur d'applications.
  • Installer et désinstaller une application.
  • Déployez une application.
  • affecter des mappages d'utilisateurs et de groupes aux rôles pour des applications.
  • Configurer les droits de sécurité Java 2 pour des applications.
  • Personnaliser les configurations CSIv2 (Common Secure Interoperability Version 2), SAS (Secure Authentication Service) et SSL (Secure Sockets Layer) configurations.
    Important : SAS est pris en charge uniquement sur les serveurs version 6.0.x et antérieure qui ont été fédérés dans une cellule version 6.1.
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 :
  • Arrêter et démarrer le serveur.
  • Surveiller le statut du serveur dans la console d'administration.
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 :
  • Modifier l'ID utilisateur et le mot de passe.
  • Configurer les mécanismes d'authentification et d'autorisation.
  • activer ou désactiver la sécurité administrative,
    Remarque : Dans les éditions précédentes de WebSphere Application Server, l'option Activer la sécurité administrative est désignée sous le nom Activer la sécurité globale.
  • 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,
  • Modifier le mot de passe LTPA (Lightweight Third Party Authentication) et générer des clés.
  • créer, mettre à jour ou supprimer des utilisateurs dans la configuration des référentiels fédérés,
  • créer, mettre à jour ou supprimer des groupes dans la configuration des référentiels fédérés.
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 :
  • Activer et désactiver le sous-système d'audit de sécurité.
  • Sélectionner l'implémentation de fabrique d'événements à utiliser avec le point de connexion de la fabrique d'événements.
  • Sélectionner et configurer le fournisseur de services, l'émetteur ou les deux à utiliser avec le point de connexion du fournisseur de services.
  • Définir la stratégie d'audit décrivant le comportement du serveur d'applications lorsqu'une erreur survient dans le sous-système d'audit de sécurité.
  • Définir les événements de sécurité à auditer.
Le rôle d'auditeur inclut le rôle de moniteur. Cela permet à l'auditeur d'afficher sans modifier le reste de la configuration des paramètres de sécurité.
Tableau 2. Autres rôles d'administration disponibles par le biais de la console d'administration.

Ce tableau répertorie un autre rôle d'administration disponible via la console d'administration.

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 :
  • créer, mettre à jour ou supprimer des utilisateurs dans la configuration des référentiels fédérés,
  • créer, mettre à jour ou supprimer des groupes dans la configuration des référentiels fédérés.
Tableau 3. Autres rôles d'administration disponibles par le biais de l'interface wsadmin.

Ce tableau répertorie un autre rôle d'administration disponible via la console d'administration.

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.

[z/OS]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] La valeur du paramètre com.ibm.security.SAF.authorization détermine si les profils SAF EJBROLE ou les paramètres de la console sont utilisés pour contrôler l'accès aux profils d'administration à la place des utilisateurs de la console. Lorsque la propriétécom.ibm.security.SAF.authorization est définie sur true, l'authentification SAF est sélectionnée ; les profils SAF EJBROLE sont utilisés pour contrôler l'accès aux rôles d'administration.
Remarque : Avec l'authentification SAF (System Authorization Facility), toute valeur indiquée dans les utilisateurs et les groupes de la console est ignorée.
[z/OS] Si l'autorisation WebSphere Application Server est utilisée à la place de l'autorisation SAF pour limiter l'accès aux rôles Java Platform, Enterprise Edition (Java EE), WebSphere Application Server for z/OS associe automatiquement l'identité du serveur définie lors de l'activation de sécurité administrative au rôle d'administration. Lorsque la sécurité administrative est activée, WebSphere Application Server for z/OS s'exécute sous l'identité du serveur défini dans la configuration du registre d'utilisateurs active. 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 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.

[AIX Solaris HP-UX Linux Windows][IBM i]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][IBM i]
  • 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
Les versions 6.1 et plus de WebSphere Application Server :
  • 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.

Quatre rôles de sécurité sont introduits :
  • CosNamingRead
  • CosNamingWrite
  • CosNamingCreate
  • CosNamingDelete
Les rôles présentent les niveaux d'autorité (valeur faible à élevée) suivants :
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.

[z/OS]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.


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_adminconsole
Nom du fichier : csec_adminconsole.html