Domaines de sécurité multiples

Les domaines de sécurité WebSphere (WSD) apportent une flexibilité dans l'utilisation de différentes configurations de sécurité dans WebSphere Application Server. WSD est également connu comme domaines de sécurité multiples, ou simplement comme domaines de sécurité. Vous pouvez configurer différents attributs de sécurité, tels que UserRegistry, pour différentes applications.

Remarque : Le support des domaines de sécurité multiples a été introduit dans WebSphere Application Server version 7.0. Vous pouvez créer différentes configurations de sécurité et les attribuer à diverses applications dans les processus WebSphere Application Server. En créant plusieurs domaines de sécurité, vous pouvez configurer différents attributs de sécurité pour à la fois les applications d'administration et d'utilisateur d'un environnement de cellules. Vous pouvez configurer diverses applications de façon qu'elles utilisent des configurations de sécurité différentes en attribuant les serveurs, clusters ou bus d'intégration de services hébergeant ces applications aux domaines de sécurité. Seuls les utilisateurs affectés au rôle de l'administrateur peuvent configurer des domaines de sécurité multiples.

Pourquoi les domaines de sécurité sont utiles

Les domaines de sécurité WebSphere présentent deux avantages principaux :

  • Les applications d'administration WebSphere Application Server peuvent être configurées avec un ensemble de configurations de sécurité différentes de celles des applications utilisateur.
  • Elles permettent aux ensembles d'applications de ne pas tous avoir le même ensemble de configurations de sécurité.

    [z/OS]Par exemple, l'administration de WebSphere Application Server peut être configurée pour un registre d'utilisateurs RACF alors que les applications peuvent être configurées pour un registre d'utilisateurs LDAP.

    [AIX Solaris HP-UX Linux Windows][IBM i]Par exemple, l'administration de WebSphere Application Server peut être configurée pour un registre d'utilisateurs du type référentiel fédéré alors que les applications peuvent être configurées pour un registre d'utilisateurs LDAP.

Dans les versions précédentes de WebSphere Application Server, toutes les applications d'administration et utilisateur partagent la plupart des attributs de sécurité. Toutes les applications d'administration et utilisateur de WebSphere Application Server utilisent par défaut les attributs de sécurité globaux. Par exemple, un registre d'utilisateurs défini dans la sécurité globale est utilisé pour authentifier un utilisateur pour chaque application de la cellule.

Dans cette version de WebSphere Application Server, cependant, vous pouvez utilisez plusieurs attributs de sécurité, autres que les attributs globaux, pour les applications utilisateur, vous pouvez créer un domaine de sécurité pour ces attributs différents, et les associer aux serveurs et clusters qui hébergent ces applications utilisateur. Vous pouvez également associer un domaine de sécurité à la cellule. Toutes les applications utilisateur de la cellule utilisent ce domaine de sécurité si elles ne sont pas déjà associées à un autre domaine. Cependant, les attributs de sécurité globale sont toujours requis pour les applications d'administration telles que la console d'administration, les ressources de dénomination et les MBeans.

Si vous avez utilisé la sécurité au niveau du serveur dans les versions précédentes de WebSphere Application Server, vous pouvez désormais utiliser plusieurs domaines de sécurité, étant donné que leur configuration est plus flexible et plus simple.

La sécurité au niveau du serveur est déconseillée dans cette version. Pour plus d'informations, voir Relations entre la sécurité globale et les domaines de sécurité.

Relations entre la sécurité globale et les domaines de sécurité

La sécurité globale s'applique à toutes les fonctions d'administration et à la configuration de sécurité par défaut des applications utilisateur. Les domaines de sécurité peuvent servir à définir une configuration personnalisée pour les applications utilisateur.

Une configuration de sécurité globale doit être définie pour que vous puissiez créer des domaines de sécurité. La configuration de sécurité globale est utilisée par toutes les applications d'administration, telles que la console d'administration, les ressources de dénomination et les Mbeans. Si aucun domaine de sécurité n'est configuré, toutes les applications fonctionnent avec la configuration de sécurité globale. Les applications utilisateur telles que Enterprise JavaBeans (EJB), les servlets et les applications d'administration utilisent la même configuration de sécurité.

Lorsque vous créez un domaine de sécurité et que vous l'associez à une portée, seules les applications utilisateur de cette portée utilisent les attributs de sécurité définis dans le domaine de sécurité. Les applications d'administration ainsi que les opérations de dénomination situées dans cette portée utilisent la configuration de sécurité globale. Définissez les attributs de sécurité de niveau du domaine qui doivent être différents de ceux de niveau global. Si l'information est commune aux deux niveaux, il n'est pas nécessaire qu'elle soit dupliquée dans le domaine de sécurité. Tous les attributs manquants dans le domaine sont obtenus à partir de la configuration globale. Les données de la configuration de sécurité globale sont stockées dans le fichier security.xml, situé dans le répertoire $WAS_HOME/profiles/$ProfileName/cells/$CellName.

L'illustration suivante montre l'exemple d'un domaine de sécurité multiple où la cellule, un serveur et un cluster sont associés à différents domaines de sécurité. Comme indiqué par l'illustration, les applications utilisateur du serveur S1.1 et le cluster utilisent les attributs de sécurité définis dans Domaine2 et Domaine3 respectivement (puisque ces portées sont associées à ces domaines). Le serveur S2.2 n'est associé à aucun domaine. Par conséquent, l'application utilisateur de S2.2 utilise par défaut le domaine associé à la cellule (Domaine1). Les attributs de sécurité manquants au niveau du domaine sont obtenus à partir de la configuration globale.

Figure 1. Portées pouvant être associées à un domaine de sécuritéExemple de domaine de sécurité multiple où la cellule, un serveur et un cluster sont associés à différents domaines de sécurité. Dans l'illustration, les applications utilisateur du serveur S1.1 et le cluster utilisent respectivement les attributs de sécurité définis dans Domaine2 et Domaine3 (puisque ces portées sont associées à ces domaines). Le serveur S2.2 n'est associé à aucun domaine. Il en découle que l'application utilisateur de S2.2 utilise le domaine associé à la cellule par défaut (Domaine1). Les attributs de sécurité manquants au niveau du domaine sont obtenus à partir de la configuration globale.

L'illustration suivante montre les différents attributs de sécurité haute qui peuvent être définis par la configuration de sécurité globale et ceux qui peuvent être outrepassés au niveau du domaine.

Figure 2. Attributs de sécurité pouvant être configurés au niveau du domaine de sécuritéAttributs de sécurité élevée pouvant être définis au niveau de la configuration de sécurité globale et attributs pouvant être substitués au niveau du domaine

Contenu d'un domaine de sécurité

Un domaine de sécurité est représenté par deux fichiers de configuration. L'un contient la liste des attributs configurés dans le domaine de sécurité et l'autre, les portées utilisant le domaine de sécurité. Les informations du domaine de sécurité sont stockées dans le répertoire $WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomainName. Pour chaque domaine de sécurité configuré, un répertoire $SecurityDomainName contenant deux fichiers est créé : le fichier security-domain.xml contient la liste des attributs configurés pour le domaine de sécurité et le fichier security-domain-map.xml contient les portées qui utilisent le domaine de sécurité.

L'illustration suivante indique l'emplacement des fichiers associés au domaine de sécurité principal et leur contenu.

Figure 3. Emplacement et contenu des fichiers associés au domaine de sécurité principalEmplacement des fichiers liés au domaine de sécurité principal avec leurs contenus
Remarque : Vous ne devez pas modifier ces fichiers manuellement. A la place, utilisez les tâches ou les commandes de script dans la console d'administration. Pour consulter la liste complète des tâches et des commandes de script d'administration, voir les liens dans "Tâches connexes" à la fin de ce document.

Création de domaines de sécurité

Utilisez les tâches ou les commandes de script dans la console d'administration pour créer des domaines de sécurité. Dans la console d'administration, vous pouvez accéder aux domaines de sécurité en cliquant sur Sécurité > Domaines de sécurité. Une aide est disponible pour chaque panneau de la console d'administration.

Pour consulter la liste complète des tâches et des commandes de script de la console d'administration, voir les liens dans "Tâches connexes" à la fin de ce document.

Lorsque vous créez un domaine de sécurité, vous devez fournir un nom unique, les attributs de sécurité que vous voulez configurer et les portées qui doivent l'utiliser. Une fois configurés, les serveurs qui utilisent le domaine de sécurité doivent être redémarrés. Les applications utilisateur de ces portées utilisent ensuite les attributs définis dans le domaine de sécurité. Tous les attributs qui ne sont pas configurés au niveau du domaine sont obtenus à partir de la configuration de sécurité globale. Les applications d'administration et les opérations de dénomination dans les portées utilisent toujours les attributs de sécurité à partir de la configuration de sécurité globale. Vous devez gérer ces attributs.

Tous les nouveaux attributs du domaine de sécurité doivent être compatibles avec ces attributs de sécurité globale qui sont hérités par les applications utilisateur attribuées au domaine.

Excepté les propriétés JAAS et personnalisées, une fois que les attributs globaux sont personnalisés pour un domaine, ils ne sont plus utilisés par les applications utilisateur.

Le panneau des domaines de sécurité dans la console d'administration vous permet d'attribuer à votre domaine des ressources et de sélectionner les attributs de sécurité appropriés. Le panneau affiche les attributs de sécurité des clés dans la configuration globale ; vous pouvez décider de les outrepasser au niveau du domaine, si nécessaire. Une fois que vous avez configuré et sauvegardé les attributs au niveau du domaine, la valeur du sommaire qui s'affiche sur le panneau indique la valeur personnalisée du domaine (accompagnée du mot "personnalisé" en noir).

Une portée (un serveur, un cluster, un bus d'intégration de services ou une cellule) peut être associée à un seul domaine. Par exemple, vous ne pouvez pas définir deux domaines ayant une portée au niveau de la cellule. Cependant, vous pouvez définir plusieurs portées dans le même domaine de sécurité. Par exemple, un domaine peut être sectorisé au Serveur1 et au Serveur2 seulement au sein de la cellule.

La section de portée attribuée au panneau du domaine de sécurité affiche deux vues : la première vous permet de sélectionner et d'attribuer des portées au domaine, la seconde vous permet d'afficher la liste des portées actuellement attribuées. Pour votre confort, il vous est possible de copier tous les attributs de sécurité à partir d'un domaine de sécurité existant ou de la configuration globale à destination d'un nouveau domaine de sécurité, puis de modifier seulement les attributs qui doivent être différents des autres. Vous devez quand même associer les portées à ces domaines copiés.

Les commandes de script vous permettent également de créer, de copier et de modifier les domaines de sécurité. Lorsque vous créez un domaine, vous devez exécuter les commandes appropriées pour lui associer les attributs de sécurité et les portées.

Configuration d'attributs pour les domaines de sécurité

Les attributs de sécurité qui peuvent être configurés au niveau du domaine dans WebSphere Application Server Version 9.0 sont :

  • Sécurité applicative
  • Sécurité Java™ 2
  • Utilisateur de domaine (registre)
  • Relation de confiance
  • Authentification Web SPNEGO (Simple and Protected GSS-API Negotiation)
  • Sécurité RMI/IIOP (CSIv2)
  • Connexions JAAS (application, système et données d'authentification J2C)
  • Authentification Java SPI
  • Attributs du mécanisme d'authentification
  • Fournisseur d'autorisation
  • Registres fédérés
  • [z/OS]Propriétés z/OS
  • Propriétés personnalisées.

Les panneaux des domaines de sécurité dans la console d'administration affichent tous ces attributs de sécurité.

Certains des autres attributs connus que vous ne pouvez pas remplacer au niveau du domaine sont Kerberos, Audit, SSO (Web Single Sign-on) et TAM (Tivoli Access Manager. L'attribut SSL (Secure Socket Layer) prend déjà en charge différentes portées, mais ne fait pas partie de la configuration du domaine. Pour tous les attributs qui ne sont pas pris en charge au niveau du domaine, les applications utilisateur d'un domaine partagent leur configuration de niveau global.

Tous les nouveaux attributs du domaine de sécurité doivent être compatibles avec les attributs de sécurité globale qui sont hérités par les applications utilisateur assignées au domaine. Vous devez gérer ces attributs. Par exemple, si vous personnalisez seulement une configuration JAAS au niveau du domaine, vous devez vous assurer qu'il fonctionne quand le registre d'utilisateurs est configuré au niveau global (si ce dernier n'est pas personnalisé au niveau du domaine).

Excepté les propriétés JAAS et personnalisées, une fois que les attributs globaux sont personnalisés pour un domaine, ils ne sont plus utilisés par les applications utilisateur.

L'environnement d'exécution client Tivoli Access Manager permet l'authentification (utilisée par TrustAssociationInterceptor et PDLoginModule) et l'autorisation (utilisée pour JACC) en contactant les serveurs TAM. Il existe un seul environnement d'exécution Tivoli Access Manager partagé par tous les serveurs d'une cellule. Pour plus d'informations, consultez la rubrique relative à la configuration du fournisseur JACC Tivoli Access Manager.

Vous ne pouvez pas avoir une configuration Tivoli Access Manager différente au niveau du domaine de sécurité dans le but de remplacer la configuration au niveau cellule. Vous pouvez toutefois dans une certaine mesure spécifier la configuration TAI ( Trust Association Interceptor (TAI) et JACC au niveau du domaine de sécurité. Vous pouvez, par exemple, utiliser un autre intercepteur TAI ou un autre fournisseur d'autorisation. Etant donné que la connectivité de serveur TAM peut uniquement être définie au niveau global, vous pouvez avoir plusieurs intercepteurs TAI définis et configurés au niveau du domaine de sécurité. Certains de ces intercepteurs TAI peuvent ne pas utiliser le référentiel d'utilisateurs TAM. Les intercepteurs TAI qui n'ont pas besoin de se connecter à TAM se connecteront également au serveur TAM globalement défini. De la même façon, pour l'autorisation, vous pouvez avoir plusieurs fournisseurs d'autorisation externes configurés au niveau du domaine. Toutefois, si un de ces fournisseurs d'autorisations externes a besoin d'une connexion à TAM, il utilise finalement le serveur TAM globalement configuré.

Association de portées à des domaines de sécurité

Dans WebSphere Application Server Version 9.0, vous pouvez associer un domaine de sécurité au niveau de la cellule, du serveur, du cluster et du bus d'intégration de services.
Remarque : Pour plus d'informations sur les bus d'intégration de services et la sécurité des bus dans plusieurs domaines de sécurité pour WebSphere Application Server Version 9.0, voir Sécurité de la messagerie et plusieurs domaines de sécurité.

Lorsqu'un domaine de sécurité est associé à un serveur qui ne fait pas partie du cluster, toutes les applications utilisateur de ce serveur utilisent les attributs du domaine de sécurité. Tous les attributs de sécurité manquants sont obtenus à partir de la configuration de sécurité globale. Si le serveur fait partie d'un cluster, vous pouvez associer le domaine de sécurité à celui-ci, mais pas aux membres individuels de ce cluster. Le comportement de sécurité reste ensuite cohérent au sein de tous les membres du cluster.

Si un serveur doit faire partie d'un cluster, créez en d'abord un, puis associez-y le domaine de sécurité. Vous devez associer un domaine à un serveur avant que celui-ci ne soit membre d'un cluster. Si c'est bien le cas, le code de sécurité de l'environnement d'exécution néglige le domaine, même si celui-ci est associé directement au serveur. Lorsqu'un serveur est membre d'un cluster, l'environnement d'exécution de sécurité néglige tous les domaines de sécurité associés directement au serveur. A la place, supprimez la portée du serveur du domaine de sécurité et associez-y la portée du cluster.

Un domaine de sécurité peut également être associé à la cellule. C'est souvent le cas lorsque vous voulez associer toutes les applications utilisateur de WebSphere Application Server Application Server à un domaine de sécurité. Dans ce scénario, toutes les applications d'administration et les opérations de dénomination utilisent la configuration de sécurité globale alors que toutes les applications utilisateur utilisent la configuration au niveau du domaine. C'est tout ce qu'il faut si vous voulez diviser les informations sur la configuration de sécurité pour les applications d'administration et utilisateur.

Si vous avez, ou prévoyez d'avoir, un environnement de version mixte, et que vous voulez associer des domaines de sécurité au niveau de la cellule, voir Domaines de sécurité dans un environnement multiversion pour plus d'informations.

Si vous êtes sur un serveur de profil de base qui a son propre domaine de sécurité, qui est ensuite fédéré à un gestionnaire de déploiement, associez la portée du serveur au domaine de sécurité et non pas à la portée de la cellule. Lorsque vous fédérez ce noeud, les informations du domaine de sécurité sont transmises au gestionnaire de déploiement. Si la portée de la cellule y est associée, la configuration de déploiement du réseau utilise cette configuration de sécurité, ce qui peut avoir un impact sur les applications existantes. Pendant le processus de fédération, la portée de la cellule est modifiée pour être la même que celle du serveur qui est fédéré. Si la portée du serveur est associée au domaine de sécurité, seul ce serveur utilise le domaine de sécurité après le processus de fédération. Les applications des autres serveurs et clusters ne sont pas concernées. Cependant, si ce serveur de profil de base est enregistré dans le processus de l'agent d'administration, vous pouvez associer la portée de la cellule au domaine de sécurité si vous voulez que tous les serveurs du profil de base utilisent le même domaine de sécurité pour toutes leurs applications utilisateur. Voir Fédération d'un noeud avec des domaines de sécurité pour plus d'informations.

Vous pouvez avoir un domaine de sécurité associé au niveau de la cellule et d'autres domaines de sécurité associés à divers clusters ou serveurs individuels (ceux qui ne font partie d'aucun cluster). Dans ce cas, l'environnement d'exécution de sécurité vérifie d'abord si des domaines de sécurité sont associés au serveur ou à un cluster. Si c'est le cas, les attributs de sécurité définis dans le domaine sont utilisés pour toutes les applications du serveur ou du cluster. Tous les attributs de sécurité manquant dans ce domaine de serveur ou de cluster sont obtenus à partir de la configuration de sécurité globale, et non pas à partir de la configuration de domaine associée à la cellule.

Si le serveur ou le cluster n'a pas un domaine défini qui lui est propre, le code de sécurité de l'environnement d'exécution utilise les attributs de sécurité à partir du domaine associé à la cellule (s'il y en a un de défini). Tous les attributs de sécurité manquant dans le domaine de la cellule sont hérités à partir de la configuration de sécurité globale.

Relations entre la sécurité au niveau de l'ancien serveur et les nouveaux domaines de sécurité

Dans les versions précédentes de WebSphere Application Server, vous pouvez associer un petit ensemble d'attributs de sécurité au niveau d'un serveur. Ces attributs étaient utilisés par toutes les applications au niveau du serveur. La technique précédente de configuration des attributs de sécurité a été dépréciée dans WebSphere Application Server 7.0 et sera supprimée dans une version ultérieure.

Nous vous conseillons d'utiliser le nouveau support des domaines de sécurité introduit dans WebSphere Application Server 7.0, étant donné que ces domaines de sécurité sont plus simples à gérer et beaucoup plus flexibles. Par exemple, dans les versions précédentes de WebSphere Application Server, vous devez associer manuellement la même configuration de sécurité à tous les membres du cluster en configurant les mêmes attributs de sécurité pour tous les serveurs d'un cluster.

L'outil de migration fait migrer les informations de la configuration de sécurité existante au niveau du serveur vers la nouvelle configuration du domaine de sécurité lorsque le mode de compatibilité des scripts est false (-scriptCompatibility="false"). Un nouveau domaine de sécurité est créé pour chaque configuration de sécurité de serveur s'il ne fait pas partie d'un cluster. S'il fait partie d'un cluster, le domaine de sécurité est associé à ce cluster au lieu d'être associé à tous les serveurs de ce cluster. Dans les deux cas, tous les attributs de sécurité qui étaient configurés au niveau du serveur dans les versions précédentes sont migrés vers la nouvelle configuration de domaine de sécurité, et la portée appropriée est attribuée aux domaines de sécurité.

Si le mode de compatibilité des scripts a la valeur true, la configuration de sécurité au niveau du serveur n'est pas migrée vers la nouvelle configuration des domaines de sécurité. L'ancienne configuration de sécurité du serveur est migrée sans modifications. L'environnement d'exécution de sécurité détecte que l'ancienne configuration de sécurité existe et utilise ces informations, même si un domaine de sécurité est associé au serveur directement ou indirectement. Si le mode de compatibilité des scripts a la valeur true, supprimez la configuration de sécurité au niveau du serveur, puis créez un domaine de sécurité avec le même ensemble d'attributs de sécurité.

Utilisation des attributs de sécurité au niveau du domaine par le module d'exécution de sécurité et les applications

Cette section décrit comment sont utilisés les attributs individuels au niveau du domaine par l'environnement d'exécution de sécurité et quel en est l'impact sur la sécurité de l'application utilisateur. Etant donné que tous ces attributs de sécurité sont également définis au niveau global, vous pouvez trouver plus d'informations ailleurs. Dans cette section, l'accent est mis sur le comportement au niveau du domaine.

  1. Sécurité de l'application :

    Sélectionnez Activer la sécurité des applications pour activer ou désactiver la sécurité des applications utilisateur. Lorsque cette sélection est désactivée, tous les EJB et les applications Web du domaine de sécurité ne sont plus protégés. L'accès à ces ressources est autorisé sans authentification de l'utilisateur. Lorsque vous activez cette sélection, la sécurité J2EE est appliquée pour tous les EJB et applications Web dans le domaine de sécurité. La sécurité J2EE est activée uniquement lorsque l'option Sécurité globale est activée dans la configuration de sécurité globale (ce qui signifie que vous ne pouvez pas activer la sécurité des applications sans activer d'abord Sécurité globale au niveau global).

  2. Sécurité Java 2 :

    Sélectionnez Utiliser la sécurité Java 2 pour activer ou désactiver la sécurité Java 2 au niveau du domaine ou pour affecter ou ajouter des propriétés liées à la sécurité Java 2. Cette option active ou désactive la sécurité Java 2 au niveau du processus (JVM) pour que toutes les applications (d'administration et utilisateur) puissent activer ou désactiver la sécurité Java 2.

  3. Domaine d'utilisateur (Registre d'utilisateurs) :

    Cette section permet de configurer le registre d'utilisateurs pour le domaine de sécurité. Vous pouvez configurer séparément tout registre utilisé au niveau du domaine. Voir Configuration d'attributs pour les domaines de sécurité pour plus d'informations.

    Lors de la configuration d'un registre au niveau du domaine, vous pouvez choisir de définir votre propre nom de domaine pour ce registre. Le nom de domaine permet de distinguer un registre d'utilisateurs d'un autre. Le nom de domaine est utilisé à plusieurs endroits : dans le panneau de connexion client Java pour identifier l'utilisateur, dans le cache d'authentification et lors de l'utilisation de l'autorisation native.

    Au niveau de la configuration globale, le système crée le domaine pour le registre d'utilisateurs. Dans les versions précédentes de WebSphere Application Server, un seul registre d'utilisateurs est configuré dans le système. Lorsque vous possédez des domaines de sécurité multiples, vous pouvez configurer plusieurs registres dans le système. Pour les domaines uniques, configurez votre propre nom de domaine pour un domaine de sécurité. Vous pouvez également choisir le système permettant de créer un nom de domaine unique, si vous êtes sûr qu'il sera unique. Dans ce dernier cas, le nom de domaine est basé sur le registre utilisé.

    Pour les registres LDAP, le port d'hôte du serveur LDAP est le nom de domaine généré par le système. Pour localOS, le nom de la machine localOS est le nom de domaine. Pour les registres d'utilisateurs personnalisés, le domaine est celui qui est renvoyé par la méthode getRealm ( ) de l'implémentation de registre personnalisé.

    Si les noms de domaines générés par le système sont uniques, vous pouvez choisir l'option pour que le système génère le nom de domaine. Sinon, choisissez un nom de domaine unique pour chaque domaine de sécurité où le registre d'utilisateurs est configuré. Si le référentiel utilisateur sous-jacent est le même, utilisez le même nom de domaine. Dans une perspective d'exécution de la sécurité, les mêmes noms de domaine ont le même ensemble d'informations sur les utilisateurs et les groupes. Par exemple, lorsque des informations concernant des utilisateurs et des groupes sont requises dans un domaine, le premier référentiel utilisateur qui correspond au domaine est utilisé.

    Si un registre localOS non centralisé est configuré pour un domaine quelconque et que ce domaine est associé à des serveurs ou des clusters hébergés sur des noeuds d'un autre système que le gestionnaire de déploiement, le nom de domaine doit être fourni. Le nom de domaine doit être identique à celui qui aurait été généré sur le noeud. Pour obtenir ce nom de domaine, appelez la méthode getRealm() sur le bean SecurityAdmin MBean de ce noeud. Habituellement, le nom de domaine pour les registres localOS est le nom d'hôte de l'ordinateur. Dans ce cas, vous ne devez pas laisser le système générer le nom de domaine mais plutôt obtenir le nom de domaine utilisé par les processus du noeud.

    Si vous laissez le système générer le nom de domaine pour le registre localOS au moment de la configuration du registre des utilisateurs, le système choisit le registre localOS utilisé par le gestionnaire de déploiement. Si le domaine configuré ne correspond pas à celui qui est utilisé par les serveurs, vous rencontrerez des problèmes d'autorisation. Notez aussi que, dans ce cas, le domaine qui utilise le registre local ne peut être associé qu'à des serveurs et clusters appartenant à des noeuds du même ordinateur.

    Dans WebSphere Application Server version 7.0, le registre d'utilisateurs "référentiels fédérés" peut être configuré uniquement au niveau global et disposer d'une instance unique par cellule, mais tous les domaines peuvent l'utiliser en le configurant comme registre actif. Dans WebSphere Application Server version 8.0, vous pouvez configurer une instance unique d'un référentiel fédéré au niveau domaine dans un environnement à plusieurs domaines de sécurité.

    Lorsqu'un domaine de sécurité est copié à partir du niveau global, les utilisateurs et les groupes définis au niveau global sont également copiés dans le domaine de sécurité. Cette règle s'applique également lorsque la copie a lieu à partir d'un domaine existant. Dans le cas d'un nouveau domaine de sécurité utilisant le référentiel VMM à base de fichier, l'utilisateur doit peupler ce référentiel avec des utilisateurs et des groupes.

    Dans cette édition de WebSphere Application Server, une nouvelle case à cocher de la page de la console d'administration des paramètres de configuration de domaine (Use global schema for model) définit l'option de schéma global du modèle de données dans un environnement à domaines de sécurité multiples. Le schéma global se rapporte au schéma du domaine admin.

    Lorsque plusieurs registres font partie d'un processus, la recherche de nom qui utilise “UserRegistry” renvoie le registre d'utilisateurs utilisé par les applications utilisateur. Le registre d'utilisateurs utilisé par les applications d'administration est lié par le nom de recherche “AdminUserRegistry”.

    Comme décrit dans Communication entre domaines, lorsque l'application d'un domaine communique avec l'application d'un autre domaine utilisant les jetons LTPA, les domaines doivent être sécurisés. La relation sécurisée peut être établie en utilisant le lien entrant Domaines d'authentification sécurisés – dans le panneau du registre d'utilisateurs ou en utilisant la commande addTrustedRealms. Vous pouvez établir la sécurité entre différents domaines. Un utilisateur connecté à un domaine peut accéder aux ressources d'un autre domaine. Si aucune sécurité n'est établie entre les deux domaines, la validation du jeton LTPA échouera.

    Remarque : Le nom de domaine utilisé dans le fichier web.xml n'est pas lié au domaine du registre des utilisateurs.
  4. Relation de confiance :

    Lorsque vous configurez l'intercepteur TAI au niveau d'un domaine, les intercepteurs configurés au niveau global sont copiés au niveau du domaine par souci de commodité. Vous pouvez modifier la liste des intercepteurs au niveau du domaine selon vos besoins. Configurez uniquement les intercepteurs devant être utilisés au niveau du domaine.

    Les intercepteurs de relations de confiance Tivoli Access Manager peuvent être configurés uniquement au niveau global. La configuration de domaine peut également les utiliser, mais elle ne peut pas être de version différente de celle de l'intercepteur de relations de confiance. Il ne peut exister qu'une seule instance des intercepteurs de relation de confiance de Tivoli Access Manager dans la cellule.

  5. Authentification Web SPNEGO :

    L'authentification Web SPNEGO, qui permet de configurer SPNEGO pour l'authentification des ressources Web, peut être configurée au niveau du domaine.

    Remarque : A compter de la version 6.1, WebSphere Application Server s'est enrichi d'un intercepteur TAI utilisant le mécanisme SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) pour négocier en toute sécurité et authentifier les demandes HTTP portant sur des ressources sécurisées. Toutefois, cette fonction a été dépréciée dans WebSphere Application Server version 7.0. Elle a été remplacée par l'authentification Web SPNEGO, qui fournit un rechargement dynamique des filtres SPNEGO et autorise un repli sur la méthode d'ouverture de session de l'application.
  6. Sécurité RMI/IIOP (CSIv2) :

    L'attribut Sécurité RMI/IIOP se réfère aux propriétés du protocole CSIv2 (Common Secure Interoperability version 2). Lorsque vous configurez ces attributs au niveau du domaine, la configuration de sécurité RMI/IIOP au niveau global est copiée par souci de commodité.

    Vous pouvez modifier au niveau du domaine les attributs qui doivent être différents Les paramètres de la couche de transport pour les communications CSIv2 entrantes doivent être les mêmes pour le niveau global et celui du domaine. S'ils diffèrent, les attributs au niveau du domaine sont appliqués à toutes les applications du processus.

    Lorsqu'un processus communique avec un autre processus ayant un domaine différent, les jetons d'authentification et de propagation LTPA ne sont pas propagés vers le serveur en aval à moins que ce serveur ne soit répertorié dans la liste des domaines sécurisés sortants. Cette opération peut s'effectuer via le lien sortant Domaines d'authentification sécurisés – sur le panneau des communications sortantes CSIv2 ou en utilisant la tâche de commande addTrustedRealms. Voir Communication entre domaines pour plus d'informations.

  7. JAAS (Java Authentication and Authorization Service) :

    Les alias des connexions des applications JAAS, des connexions système JAAS et des données d'authentification J2C JAAS peuvent tous être configurés au niveau du domaine. Par défaut, toutes les applications dans le système ont accès aux connexions JAAS configurées au niveau global. L'exécution de la sécurité vérifie en premier lieu la présence des connexions JAAS au niveau du domaine. S'il ne les trouve pas, il les recherche ensuite dans la configuration de sécurité globale. Configurez l'une de ces connexions JAAS au niveau d'un domaine uniquement lorsque vous devez spécifier une connexion utilisée exclusivement par les applications du domaine de sécurité.

    Une fois que les attributs globaux sont personnalisés pour un domaine (pour le service JAAS et les propriétés personnalisées uniquement), ils peuvent toujours être utilisés par les applications utilisateurs.

  8. Authentification Java Authentication SPI (JASPI)

    Spécifie les paramètres de configuration d'un fournisseur d'authentification Java Authentication SPI (JASPI) et des modules d'authentification associés à appliquer au niveau du domaine.

    Sélectionnez Fournisseurs pour créer ou modifier un fournisseur d'authentification JASPI.

    Remarque : Le fournisseur d'authentification JASPI peut être activé à l'aide des fournisseurs configurés au niveau du domaine. Par défaut, toutes les applications du système ont accès aux fournisseurs d'authentification JASPI configurés au niveau global. Le module d'exécution de sécurité recherche d'abord les fournisseurs d'authentification JASPI au niveau du domaine. S'il ne les trouve pas, il les recherche ensuite dans la configuration de sécurité globale. Ne configurez de fournisseurs d'authentification JASPI dans un domaine que si seules les applications de ce domaine de sécurité doivent utiliser le fournisseur.
  9. Attributs du mécanisme d'authentification :

    Indique les différents paramètres de mémoire cache à appliquer au niveau du domaine.

    1. Paramètres de la mémoire cache d'authentification - pour indiquer vos paramètres de la mémoire cache d'authentification. La configuration indiquée sur ce panneau s'applique uniquement à ce domaine.
    2. Délai d'attente LTPA - Vous pouvez configurer un délai d'attente LTPA différent au niveau du domaine. La valeur de la durée d'attente par défaut, définie au niveau global, est de 120 minutes. Si le délai d'attente LTPA est définie au niveau du domaine, tout jeton créé dans le domaine de sécurité lors de l'accès aux applications utilisateur est créé avec ce délai d'expiration.
    3. Utilisation des noms d'utilisateur complets du domaine - Lorsque cette option est activée, les noms d'utilisateur renvoyés par des méthodes telles que getUserPrincipal( ) sont qualifiés avec le domaine de sécurité (registre d'utilisateurs) utilisé par les applications dans le domaine de sécurité.
  10. Fournisseurs d'autorisations :

    Vous pouvez configurer un fournisseur JACC (Java Authorization Contract for Containers) tiers externe au niveau du domaine. Le fournisseur JAAC de Tivoli Access Manager peut être configuré uniquement au niveau global. Les domaines de sécurité peuvent toujours l'utiliser s'ils ne remplacent pas le fournisseur d'autorisation par un autre fournisseur JACC.

    Les attributs JACC, par exemple l'objet règle, sont basés au niveau de la JVM. Ceci implique qu'il ne peut exister qu'un seul objet règle JACC dans un processus JVM. Toutefois, quand plusieurs fournisseurs JACC sont configurés, le processus du gestionnaire de déploiement doit gérer tous ces fournisseurs dans la même JVM car il doit propager les règles d'autorisation des applications vers les fournisseurs respectifs sur la base du nom de l'application.

    Si votre fournisseur JACC peut gérer la propagation des règles d'autorisation vers plusieurs fournisseurs, vous pouvez le configurer au niveau global. Dans ce cas, quand vous installez une application, ce fournisseur JACC est appelé dans le processus du gestionnaire de déploiement et c'est lui qui propage les informations au fournisseur JACC correspondant sur la base du nom de l'application transmis dans l'ID de contexte.

    Alternativement, vous pouvez définir la propriété personnalisée com.ibm.websphere.security.allowMultipleJaccProviders=true au niveau de la sécurité globale. Une fois cette propriété définie, WebSphere Application Server propage les données des règles d'autorisation au fournisseur JACC associé au domaine qui correspond au serveur cible où l'application est installée. Cette propriété est utilisée uniquement par le processus du gestionnaire de déploiement car les serveurs gérés n'hébergent pas plusieurs fournisseurs JACC.

    [z/OS]Vous pouvez également configurer les options d'autorisation SAF suivantes au niveau du domaine de sécurité :
    • ID utilisateur non authentifié ;
    • associateur de profil SAF ;
    • activation ou non de la délégation SAF ;
    • utilisation ou non du profil APPL pour limiter les accès à WebSphere Application Server ;
    • suppression ou non des messages en échec d'autorisation ;
    • stratégie d'enregistrement d'audit SMF ;
    • préfixe de profil SAF.

    [z/OS]Les vérifications CBIND sont considérées comme des opérations administratives. Par conséquent, la valeur définie au niveau global pour le préfixe du profil SAF est utilisée pour déterminer le nom de la ressource CBIND à contrôler. Par exemple : CB.BIND.<cluster_name ou SAF_profile_prefix>.

    [z/OS]Pour plus d'informations sur les options d'autorisation SAF, voir Autorisation SAF (System Authorization Facility) z/OS.

  11. Propriétés personnalisées :

    Définissez des propriétés personnalisées au niveau du domaine qui sont soit nouvelles soit différentes de celles au niveau global. Par défaut, toutes les applications de la cellule peuvent accéder à toutes les propriétés personnalisées au niveau de la configuration de sécurité globale. Le code d'exécution de la sécurité vérifie en premier lieu la présence de la propriété personnalisée au niveau du domaine. S'il ne la trouve pas, il tente de l'obtenir dans la configuration de sécurité globale.

    Une fois que les attributs globaux sont personnalisés pour un domaine (pour le service JAAS et les propriétés personnalisées uniquement), ils peuvent toujours être utilisés par les applications utilisateurs.

Modèle de programmation de la sécurité du client et de l'application lors de l'utilisation de domaines de sécurité

Un client ou une application Java agissant comme un client qui a accès à EJB effectue d'abord typiquement une recherche de nom. Le nom, qui est utilisé par les applications d'administration et utilisateur, est considéré comme une ressource d'administration. Cette ressource est protégée par les informations de configuration de sécurité globale. Dans une configuration comportant plusieurs domaines, où la sécurité globale utilise le registre d'utilisateurs, et où un domaine utilise un autre superdomaine (realm), le client Java doit authentifier deux superdomaines (realm) différents. La première authentification est nécessaire pour le domaine de la configuration de sécurité globale afin de réussir la dénomination, la deuxième sert à permettre l'accès au EJB, qui utilise un domaine différent.

Le rôle CosNamingRead protège toutes les opérations de lecture de la dénomination. Ce rôle est généralement attribué au sujet spécial Tous. Cela implique que tous les utilisateurs, valides ou pas, peuvent chercher l'espace de noms. Lorsque plusieurs domaines sont définis, si le rôle CosNamingRead a le sujet spécial Tous, le code d'exécution de la sécurité du côté client ne vous demande pas de vous connecter. A la place, le sujet NON AUTHENTIFIE est utilisé pour accéder à l'opération de dénomination. Une fois que l'opération de recherche de la dénomination est terminée, et lorsque le client essaie d'accéder au EJB, un panneau de connexion apparaît et indique le domaine actuellement utilisé par cette application EJB (c'est-à-dire le domaine (realm) utilisé dans le domaine). Le client présente alors les justificatifs utilisateur appropriés pour ce domaine, qui a ensuite accès au EJB. Cette logique s'applique à toutes les variations de source de connexion, y compris properties et stdin, et pas uniquement lorsque la source de connexion est définie sur prompt.

Si le sujet spécialTous est supprimé du rôle CosNamingRead, vous recevrez deux fois la demande de connexion. Si la source de connexion est properties, vous pouvez supprimer la mise en commentaire de la propriété com.ibm.CORBA.loginRealm dans le fichier $WAS_HOME/profiles/$ProfileName/properties/sas.client.props et ajouter les domaines appropriés en utilisant “|” comme séparateur. Vous devez également entrer les utilisateurs et les mots de passe correspondants dans les propriétés com.ibm.CORBA.loginUserid et com.ibm.CORBA.loginPassword respectivement. Lorsque vous ouvrez une session à l'aide d'un programme, dans le code client Java, vous devez vous authentifier deux fois avec des justificatifs utilisateur différents : une fois avant d'effectuer la recherche de dénomination pour l'EJB (l'utilisateur doit être dans le domaine global), et une deuxième fois avant d'appeler une méthode dans l'EJB (l'utilisateur doit être dans le domaine (realm) du domaine EJB).

[z/OS]Le rôle CosNamingRead défini sur le serveur de sécurité z/OS n'est pas référencé pour déterminer si les lectures de noms sont protégées dans un environnement de domaine à sécurité multiple, même quand l'autorisation SAF est activée. Au lieu de cela, le système utilise les paramètres contenus dans le fichier admin-authz.xml. Vous pouvez également utiliser la propriété personnalisée com.ibm.security.multiDomain.setNamingReadUnprotected pour contrôler si les lectures de noms sont protégées. Cette propriété remplacera toutes les affectations du rôle CosNamingRead quelque soit le fournisseur d'autorisation utilisé.

En général, lorsqu'un client Java a besoin de s'authentifier dans plusieurs domaines différents, il doit fournir les justificatifs pour chacun de ces domaines. Si la source de connexion est prompt ou stdin, on vous demande de vous connecter plusieurs fois, c'est-à-dire une fois par domaine. Si la source de connexion a la valeur properties, les propriétés appropriées du fichier sas.client.props (ou tout autre fichier associé) sont utilisées pour l'authentification dans différents domaines.

Dans certains cas, un client peut effectuer plusieurs appels vers le même domaine. Par exemple, le client Java a accès à une ressource utilisant realm1, puis l'accès à une ressource utilisant realm2 et, enfin, à nouveau l'accès à une ressource realm1. Dans ce cas, le client reçoit une demande de connexion trois fois ; le première pour realm1, la deuxième pour realm2 et, enfin, à nouveau pour realm1.

Par défaut, le sujet utilisé pour se connecter à un domaine n'est pas mis en mémoire cache par le code du côté client. Si vous êtes dans ce cas et que vous voulez que le client mette en mémoire cache l'objet basé sur le domaine, attribuez la valeur true à la propriété com.ibm.CSI.isRealmSubjectLookupEnabled dans le fichier sas.client.props. Si la propriété com.ibm.CSI.isRealmSubjectLookupEnabled est définie, le code client met en mémoire cache le sujet sur la base du nom du domaine. La fois suivante où le client Java doit s'authentifier dans ce domaine, le cache est mis à un emplacement permettant d'obtenir le sujet et le client ne reçoit pas d'invitation de connexion. De même, lorsque la propriété com.ibm.CSI.isRealmSubjectLookupEnabled est définie, l'objet qui a été connecté la première fois est utilisé pour d'autres connexions. Si les informations concernant le sujet doivent être modifiées, cette propriété ne doit pas être définie.

Si le client effectue une connexion se faisant à l'aide d'un programme, il peut accéder au domaine avec l'utilisateur et le mot de passe qu'il doit authentifier. Dans ce cas, lorsque la propriété com.ibm.CORBA.validateBasicAuth a la valeur true (ce qui constitue la valeur par défaut) dans le fichier sas.client.props, le registre qui correspond au nom du domaine est utilisé pour la connexion. Ce domaine doit être pris en charge dans le processus où a lieu l'authentification.

Lorsque vous utilisez des configurations WSLogin JAAS, vous devez également définir l'option use_realm_callback dans le fichier wsjaas_client.config dans $WAS_HOME/profiles/$ProfileName/properties pour que le nom de domaine soit transmis au gestionnaire d'appel. Si vous voulez indiquer une URL du fournisseur différente pour le serveur de noms, définissez l'option use_appcontext_callback et entrez les propriétés de l'URL du fournisseur dans une table de hachage pour WSLogin.

Si vous ne connaissez pas le nom de domaine, utilisez <default>> à la place. L'authentification s'effectue pour le domaine de l'application. Si le sujet spécial Tous n'est pas attribué à l'opération de lecture de la dénomination, vous devez fournir le domaine utilisé par les applications d'administration (registre utilisé dans la configuration de sécurité globale), ainsi que l'utilisateur et le mot de passe appropriés de ce registre pour que la recherche réussisse.

Une fois la recherche terminée, effectuez une autre connexion à l'aide d'un programme en indiquant le nom de domaine de l'application (ou <default>>), ainsi que l'utilisateur et le mot de passe pour l'utilisateur approprié dans le registre utilisé par l'application. Ce cas est similaire à celui où la source de connexion est prompt. Vous devez vous authentifier deux fois : une fois pour le registre utilisé par la configuration de sécurité globale (pour la recherche de dénomination) et une deuxième fois pour le registre utilisé par l'application afin d'accéder à l'EJB.

Si com.ibm.CORBA.validateBasicAuth n'a pas la valeur false dans le fichier $WAS_ROOT/profiles/$ProfileName/properties/sas.client.props, la connexion à l'aide d'un programme peut utiliser <default>> comme nom de domaine pour les opérations de recherche et EJB. L'authentification réelle se produit uniquement lorsque la ressource est accessible côté serveur, auquel cas le domaine est calculé en se basant sur la ressource accessible.

Le nouveau support des domaines de sécurité introduit dans la version 7.0 de WebSphere Application Server ne modifie pas le modèle actuel de programmation de sécurité des applications. Cependant, il apporte plus de flexibilité et de fonctions, telles que les suivantes :

  • Les applications utilisateur peuvent toujours trouver l'objet registre d'utilisateurs “UserRegistry” à l'aide de la recherche de dénomination. Pour rechercher l'objet registre utilisé par les applications d'administration, vous pouvez entrer “AdminUserRegistry”.
  • L'utilisation d'application de la configuration de connexion JAAS ne change pas dans une configuration de plusieurs domaines. Cependant, si une application doit se référer à la configuration JAAS indiquée au niveau du domaine, l'administrateur et le déployeur de cette application doivent s'assurer que ce domaine est configuré avec les configurations JAAS requises.
  • Si une application doit communiquer avec d'autres applications qui utilisent des domaines différents, la relation de sécurité doit être établie pour les communications entrantes et sortantes lors de l'utilisation des jetons LTPA. Voir Communication entre domaines pour plus d'informations.
  • Lors de l'utilisation d'une connexion à l'aide d'un programme, si vous voulez vous connecter au domaine utilisé par l'application, choisissez <default>> comme nom de domaine ou entrez le nom que l'application utilise. Si vous voulez vous connecter au domaine global, vous devez fournir le nom de ce domaine. Si vous donnez le nom d'un autre domaine, seul un sujet d'authentification de base sera créé. L'authentification réelle de l'utilisateur se produit lorsque la requête se dirige vers le serveur qui héberge ce domaine. Si le serveur n'héberge pas le domaine, la connexion échoue.

Déploiement d'applications dans plusieurs configurations de domaines

Lorsque vous déployez une application dans plusieurs configurations de domaines, tous les modules de l'application doivent être installés dans les serveurs ou les clusters qui appartiennent au même domaine de sécurité. Sinon, selon les attributs de sécurité configurés dans ces domaines de sécurité, cela peut provoquer des incohérences. Par exemple, si les domaines contiennent différents registres d'utilisateurs, les informations sur les utilisateurs et les groupes peuvent être différentes, ce qui peut provoquer des incohérences lors de l'accès aux modules. Autre exemple : lorsque les données JAAS sont différentes d'un domaine de sécurité à l'autre. Les configurations JAAS ne sont pas accessibles à partir de tous les modules de l'application. Le code d'exécution de la sécurité et les tâches de commande dépendent d'un domaine associé à une application lors de la manipulation d'attributs tels que le registre d'utilisateurs, les configurations de connexion JAAS, les données d'authentification J2C et l'autorisation.

Dans la plupart des cas, le déploiement de l'application échoue s'il concerne différents domaines. Cependant, étant donné que cela était possible dans les versions précédentes de WebSphere Application Server lorsque seuls quelques attributs étaient pris en charge au niveau du serveur, l'outil de déploiement vérifie d'abord la présence d'attributs configurés dans les domaines. Si les attributs du domaine sont les mêmes que ceux pris en charge dans les versions précédentes, la console d'administration demande confirmation pour s'assurer que vous voulez déployer les modules d'application dans plusieurs domaines de sécurité. A moins que le déploiement doive absolument s'effectuer dans plusieurs domaines, arrêtez-le et sélectionnez les serveurs et les clusters d'un seul domaine de sécurité.

Communication entre domaines

Lorsque les applications communiquent à l'aide du protocole RMI/IIOP et que LTPA est le mécanisme d'authentification, le jeton LTPA passe entre les serveurs concernés. Le jeton LTPA contient l'ID unique qualifié du domaine (également appelé accessId) de l'utilisateur qui se connecte à l'application frontale. Lorsque le serveur en aval reçoit ce jeton, il tente de le déchiffrer. Si les clés LTPA sont partagées entre les deux serveurs, le déchiffrement s'effectue avec succès et l'ID d'accès de l'utilisateur est obtenu à partir du jeton. Le domaine de l'ID d'accès est comparé avec le domaine actuellement utilisé par l'application. Si le domaine correspond, la validation du jeton LTPA s'effectue avec succès et obtient l'autorisation. Si le domaine ne correspond pas, la validation du jeton échoue étant donné que l'utilisateur du domaine externe ne peut pas être validé dans le domaine en cours de l'application. S'il n'est pas prévu que les applications communiquent entre elles lors de l'utilisation de RMI/IIOP et du mécanisme d'authentification LTPA, vous ne devez pas continuer.

Si vous ne voulez pas qu'il y ait une communication interdomaine lors de l'utilisation des jetons RMI/IIOP et LTPA, vous devez d'abord établir la sécurité entre les domaines concernés, pour la communication entrante et sortante.

Le domaine du serveur à l'origine de la demande doit inclure des domaines sécurisés auxquels envoyer le jeton. Ceux-ci sont appelés outboundTrustedRealms. Le domaine du serveur qui reçoit la demande doit sécuriser les domaines desquels il peut recevoir les jetons LTPA. Ceux-ci sont appelés inboundTrustedRealms.

Les domaines sécurisés sortants peuvent être établis à l'aide de la commande addTrustedRealms avec la valeur outbound définie pour l'option –communicationType. Ils peuvent également être établis dans la console d'administration en cliquant sur Domaines d'authentification sécurisés - sortant dans le panneau communications sortantes CSIv2.

Les domaines sécurisés entrants peuvent être établis à l'aide de la même tâche de commande addTrustedRealms avec la valeur inbound définie pour l'option –communicationType. Ils peuvent également être établis à l'aide de la console d'administration.

L'illustration présentée ultérieurement montre la communication entre les applications qui utilisent différents domaines utilisateurs (registres) à l'aide de RMI/IIOP. Dans cet exemple, l'application app1 (un servlet, par exemple) est configurée de façon à utiliser le registre d'utilisateurs realm1. L'application app2 (un EJB par exemple) est configurée de façon à utiliser le registre d'utilisateurs realm2. L'utilisateur (utilisateur1) se connecte d'abord au servlet dans app1 qui tente ensuite d'accéder à un EJB dans app2. Les éléments suivants doivent être définis :

  • Dans Domaine1, domaine1 doit sécuriser domaine2 pour la communication sortante.
  • Dans Domaine2, domaine2 doit sécuriser domaine1 pour la communication entrante.
  • L'ID d'accès pour utilisateur1 doit être configuré dans la table d'autorisation pour app2.

Lorsque app2 reçoit le jeton LTPA qui contient l'ID d'accès d'utilisateur1, il le déchiffre. Les deux serveurs partagent les mêmes clés LTPA. Le jeton LTPA s'assure ensuite que le domaine externe est un domaine sécurisé et exécute l'autorisation basée sur l'ID d'accès de l'utilisateur1. Si la propagation des attributs de sécurité n'est pas désactivée, les informations de groupe d'utilisateur1 sont également propagées vers app2. Les groupes peuvent être utilisés pour le contrôle d'autorisation, à condition que la table d'autorisation contienne les informations du groupe. Vous pouvez associer aux rôles un sujet spécial, AllAuthenticatedInTrustedRealms, au lieu d'ajouter des utilisateurs individuels et des groupes à la table d'autorisation.

Si les applications de l'exemple précédent sont déployées dans différentes cellules, procédez comme suit :

  • Partagez les clés LTPA entre les cellules.
  • Mettez à jour la table d'autorisation pour app2 avec des ID d'accès d'utilisateurs et de groupes externes à l'aide de l'utilitaire wsadmin. La console d'administration n'a pas accès aux domaines qui sont en dehors de la portée de la cellule.
Figure 4. Communication entre domaines dans un environnement à domaines multiples Dans l'exemple, ci-dessus, si les applications sont déployées dans différentes cellules, vous devez partager les clés LTPA entre les cellules et mettre à jour la table des autorisations définie pour app2 avec les ID d'accès des groupes et des utilisateurs externes au moyen de l'utilitaire wsadmin. La console administrative n'a pas accès aux domaines situés hors de la portée de la cellule.

Une fois que la sécurité a été établie entre les domaines, et lorsque le serveur reçoit le jeton LTPA et que celui-ci est déchiffré, il vérifie que le domaine externe est dans sa liste des domaines sécurisés entrants. S'il est sécurisé, l'authentification réussit. Cependant, étant donné qu'il s'agit d'un domaine sécurisé, il ne recherche pas le registre d'utilisateurs afin de rassembler des informations concernant l'utilisateur. L'information contenue dans le jeton LTPA sert pour l'autorisation de l'utilisateur.

La seule information contenue dans le jeton LTPA est l'ID unique de l'utilisateur. Cet ID unique de l'utilisateur doit être dans la table d'autorisation de cette application. Si c'est bien le cas, l'autorisation se réalise avec succès. Cependant, si la propagation des attributs est activée, d'autres attributs d'autorisation (groupes auxquels appartient l'utilisateur) pour l'utilisateur sont envoyés à partir du serveur d'origine vers le serveur récepteur. Ces attributs supplémentaires servent à prendre les décisions d'accès. Si les informations sur les groupes sont dans les jetons de propagation, elles sont utilisées lors de l'exécution de la décision d'autorisation.

Comme indiqué précédemment, les informations sur les utilisateurs ou sur les groupes des domaines sécurisés doivent être dans la table d'autorisation de l'application réceptrice. Plus précisément, l'ID d'accès des utilisateurs et/ou des groupes doivent être dans le fichier de liaison de l'application. Cela doit être le cas lorsque l'application est déployée. Dans la console d'administration, lorsqu'une application est déployée dans un domaine, vous pouvez ajouter à la table d'autorisation les ID d'accès des utilisateurs et des groupes de n'importe quel domaine sécurisé de l'application.

Vous avez également accès à l'option permettant d'associer aux rôles un sujet spécial, AllAuthenticatedInTrustedRealms. Ainsi, il n'est pas nécessaire d'ajouter des groupes et des utilisateurs individuels. Ce sujet est similaire au sujet spécial AllAuthenticated actuellement pris en charge. La différence est qu'AllAuthenticated se réfère aux utilisateurs du même domaine alors qu'AllAuthenticatedInTrustedRealms s'applique à tous les utilisateurs des domaines sécurisés et du domaine de l'application.

Vous pouvez associer l'ID d'accès à l'aide du script d'installation $AdminApp. Etant donné que l'ID d'accès a un seul format, utilisez la tâche de commande listRegistryUsers en attribuant la valeur true à displayAccessIds. Si un nom ou un format non valide est entré dans ce champ, l'autorisation échoue.

Les informations sur les utilisateurs ou sur les groupes des domaines sécurisés sont obtenues par le gestionnaire de déploiement, étant donné qu'il a accès à toutes les configurations du registre d'utilisateurs dans tous les domaines. Cependant, dans certains cas, il n'est pas possible d'obtenir ces informations.

Par exemple, si un serveur hébergé sur un noeud externe utilise localOS comme registre pour son domaine, le gestionnaire de déploiement ne peut pas obtenir les informations sur les utilisateurs et sur les groupes à moins qu'il ne soit en cours d'exécution dans la même configuration de système d'exploitation. Il faut contacter le système d'exploitation externe pour obtenir ces informations. Pour ce faire, vous devez appeler le registre du serveur associé à ce domaine. Les serveurs associés à ce domaine doivent alors être démarrés. Vous devez également attribuer la valeur true à la propriété com.ibm.websphere.allowRegistryLookupOnProcess dans les propriétés personnalisées de la sécurité de niveau supérieur. Lorsque cette propriété est définie, le code du gestionnaire de déploiement recherche un des serveurs qui est associé au domaine de sécurité et qui obtient directement les informations sur les utilisateurs et sur les groupes. Cela est possible en appelant un MBean dans l'un des serveurs.

Si le MBean de n'importe lequel des serveurs qui utilisent ce domaine n'est pas accessible, la console d'administration affiche un panneau où vous pouvez entrer l'utilisateur et l'ID d'accès manuellement pour chaque utilisateur et chaque groupe. Il est important que le bon format de l'ID d'accès soit entré dans ce champ. Le format de l'ID d'accès de l'utilisateur est user:realmName/userUniqueId. realmName est le nom du domaine où réside l'utilisateur, et userUniqueId est l'ID unique qui représente l'utilisateur, selon le registre utilisé.

Par exemple, pour LDAP, uniqueUserId est le nom distinctif (DN), pour le registre Windows localOS et le SID (ID de sécurité) de l'utilisateur. Pour les plateformes Unix, il s'agit de son UID. Pour les registres personnalisés, cela dépend de l'implémentation.

De même, pour les groupes, le format d'accessId est group:realmName/groupUniqueId. Comme précédemment indiqué, utilisez les commandes listRegistryUsers et listRegistryGroups avec l'option –displayAccessIds ayant la valeur true de manière à pouvoir obtenir le format correct pour le domaine ou le domaine (realm) qui vous intéresse.

Une fois les utilisateurs et les groupes issus des domaines sécurisés ou du sujet spécial AllAuthenticatedInTrustedRealms ajoutés à la table des autorisations de l'application, elle est prête à accepter les demandes émanant d'autres applications qui utilisent l'un de ses domaines sécurisés. La validation de jeton LTPA sur le serveur récepteur s'assure d'abord que le domaine est sécurisé. >Le moteur d'autorisation vérifie ensuite que l'utilisateur externe et/ou les groupes ou le sujet spécial AllAuthenticatedInTrustedRealms ont accès aux rôles nécessaires à l'accès à la ressource. Si la valeur est true, l'accès est accordé.

La communication interdomaine est applicable uniquement lorsque vous utilisez l'autorisation intégrée à WebSphere. Si vous utilisez d'autres moteurs d'autorisation intégrant SAF for z/OS, les autorisations interdomaine peuvent être obtenues en implémentant des modules de connexion personnalisée qui mappent des utilisateurs externes aux utilisateurs de leur propre référentiel.

Fédération d'un noeud avec des domaines de sécurité

Lorsqu'un domaine de sécurité est configuré dans la version de base et fédéré avec une cellule, il est également configuré pour le serveur de cette cellule. La même configuration de domaine de sécurité peut être utilisée par le serveur avant et après la fédération. Si un serveur de base doit être fédéré avec une cellule, la ressource attribuée au domaine de sécurité doit correspondre à la portée du serveur et non à la portée de la cellule.

Si le serveur de base doit être enregistré avec un processus d'agent administratif, utilisez la portée de la cellule en tant que ressource si vous souhaitez que tous les serveurs du profil de base utilisent ce domaine de sécurité.

Si le domaine de sécurité à la base existe déjà au niveau de la cellule au moment de la fédération, la commande addNode échoue. Vous pouvez utiliser l'option –excludesecuritydomains pour ne pas inclure le domaine de sécurité lors de la fédération.

Lorsque le noeud fédéré est supprimé d'une cellule, les ressources de ce noeud doivent être supprimées des domaines de sécurité. Si des clusters englobant des noeuds sont associés aux domaines de sécurité, ces noeuds ne sont pas supprimés. Vous pouvez toujours supprimer les ressources des domaines de sécurité ou des domaines inutilisés à l'aide des commandes de script ou de la console d'administration.

Domaines de sécurité dans un environnement multiversion

Vous devez créer les domaines de sécurité une fois que tous les noeuds ont été transférés vers la dernière version. Ceci est particulièrement vrai lorsqu'il est nécessaire d'associer la cellule à un domaine. Cependant, gardez à l'esprit les éléments suivants si vous souhaitez créer des domaines de sécurité dans un environnement multiversion :

  • Si un domaine à l'échelle de la cellule est créé dans une configuration multiversion, un domaine nommé PassThroughToGlobalSecurity est automatiquement créé. Tous les clusters mixtes sont attribués à ce domaine au moment de la création du domaine à l'échelle de la cellule. Le domaine PassThroughToGlobalSecurity est particulier : on ne peut lui ajouter d'attributs, uniquement des ressources.

    Toutes les ressources affectées au domaine PassThroughToGlobalSecurity utilisent les informations de configuration de la sécurité globale. A chaque fois qu'un noeud de la configuration multiversion est migré à la dernière version, les serveurs et clusters de ces noeuds sont ajoutés à ce domaine. Les applications de tous les serveurs et clusters de ces noeuds n'utilisent pas le domaine à l'échelle de la cellule. Ils utilisent à la place la configuration de sécurité globale avant et après la migration.

    Si l'un de ces serveurs doit utiliser le domaine à l'échelle de la cellule, vous devez supprimer ces ressources du domaine PassThroughToGlobalSecurity. Les nouveaux serveurs et clusters créés dans le noeud migré utilisent le domaine à l'échelle de la cellule et non le domaine PassThroughToGlobalSecurity. Par conséquent, vous disposez d'un mélange de serveurs et de clusters, certains utilisant la configuration de sécurité globale et d'autres utilisant le domaine à l'échelle de la cellule.

  • Dès lors qu'un domaine à l'échelle de la cellule a été créé, l'ajout de membres de cluster d'une ancienne version à un cluster WebSphere Application Server Version 9.0 est restreint, étant donné que cette action en fait un cluster mixte. Cette restriction s'applique également lorsqu'un cluster WebSphere Application Server Version 9.0 est associé à un domaine et qu'un membre de cluster d'une version antérieure est ajouté à ce cluster. Cette restriction permet d'éviter l'association d'un domaine de sécurité à un cluster mixte.
  • Si possible, créez un domaine à l'échelle de la cellule après la migration de tous les noeuds. Dans ce cas, le domaine à l'échelle de la cellule est applicable à l'ensemble de la cellule et non juste à certains éléments. Il n'est également plus nécessaire de créer le domaine PassThroughToGlobalSecurity et le scénario de cluster mixte avec les domaines de sécurité.

Modification des domaines de sécurité

Utilisez les tâches de la console d'administration ou les commandes de script pour modifier les domaines de sécurité. Pour consulter la liste complète des tâches et des commandes de script d'administration, voir les liens dans "Tâches connexes" à la fin de ce document.

Une fois un domaine de sécurité créé et associé à un ensemble de portées, les serveurs associés à ce nouveau domaine doivent être redémarrés. Après le redémarrage, les applications des portées associées au nouveau domaine utilisent les attributs de sécurité définis dans le domaine.

La modification d'un attribut du domaine nécessite le redémarrage de toutes les portées qui lui sont attribuées. Si de nouvelles portées sont ajoutées, elles doivent également être redémarrées. Toute modification apportée à la configuration du domaine, que ce soit aux attributs de sécurité ou aux portées, a un impact sur les applications qui utilisent la configuration du domaine.

Avant de modifier un domaine existant, pensez aux impacts éventuels ci-dessous. Par exemple, si un registre d'utilisateurs configuré au niveau d'un domaine est supprimé et les serveurs redémarrés, le registre d'utilisateurs du domaine à l'échelle de la cellule (si celui-ci est défini), ou la configuration de la sécurité globale, est alors utilisé. Cela peut avoir un impact sur l'authentification et l'autorisation des applications. Les utilisateurs et les groupes associés à une application peuvent ne plus être valides dans le nouveau registre. Le retrait des configurations JAAS d'un domaine est également à prendre en considération. Les applications reposant sur les configurations JAAS ne peuvent plus les utiliser. Chaque modification d'une configuration de sécurité peut avoir un impact sur vos applications et doit donc être effectuée avec le plus grand soin.

[z/OS]

Tolérance des PTF requis pour les environnements multi-édition

Des PTF de tolérance sont requis pour les environnements multi-éditions dans lesquels des versions précédentes des clients IIOP de WebSphere Application Server for z/OS interopèrent avec un serveur d'applications WebSphere Application Server Version 9.0 for z/OS qui héberge plusieurs domaines de sécurité.

Le client IIOP antérieur à la Version 9.0 nécessite une mise à jour de son code de traitement des recherches (locate) IIOP afin de pouvoir effectuer des recherches IIOP couvrant les différents domaines de sécurité d'un serveur d'applications Version 9.0.

Les PTF de tolérance pour toutes les versions de service affectées sont répertoriés ultérieurement dans cette section. Le client IIOP antérieur à Version 9.0 doit se trouver au minimum au niveau de service donné pour que l'interopération avec un serveur d'applications Version 9.0 contenant plusieurs domaines de sécurité aboutisse.

WebSphere
Application Server
for z/OS 5.1 :  W510246
WebSphere
Application Server
for z/OS v6.0 :  602.29
WebSphere
Application Server
for z/OS v6.1 :  610.17

Cette exigence s'applique uniquement aux clients IIOP de WebSphere for z/OS qui appellent des demandes auprès d'un serveur d'applications WebSphere for z/OS contenant plusieurs domaines de sécurité configurés et activés.


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_sec_multiple_domains
Nom du fichier : csec_sec_multiple_domains.html