Présentation de la planification de la sécurité
Lorsque vous accédez à des information sur Internet, vous vous connectez via des serveurs Web et des serveurs d'applications aux données d'une entreprise en bout de chaîne. Dans la présente section, nous étudierons les configurations et les stratégies de sécurité les plus couramment utilisées.
La présente section décrit la protection apportée par chaque couche de sécurité et examine les procédures de sécurité couramment appliquées pour assurer une protection optimale de bout en bout. La figure suivante présente les blocs de construction composant l'environnement d'exploitation de la sécurité dans WebSphere Application Server :
- Sécurité WebSphere Application Server
- Sécurité WebSphere
- La sécurité WebSphere Application Server applique les stratégies et les services de sécurité de manière uniforme lors de l'accès aux ressources Web, aux beans enterprise et aux ressources administratives JMX. Elle fait appel aux technologies et aux fonctions de la sécurité WebSphere Application Server pour répondre aux besoins d'un environnement d'entreprise sécurisé.
- Sécurité Java
- Interface de programmation d'application (API) de la sécurité Java EE (Java Platform, Enterprise Edition)
- Le collaborateur de sécurité applique les stratégies de sécurité Java EE (Java Platform, Enterprise Edition) et prend en charge les API de la sécurité Java EE.
- Sécurité EJB en utilisant le protocole CSIv2 (Common Secure Interoperability Version 2)
- CSIv2 (Common Secure Interoperability Version 2) est un protocole de sécurité à trois niveaux IIOP développé par OMG (Object Management Group). Il fournit une protection des données, une authentification interopérable et une délégation. Les trois niveaux incluent un niveau de sécurité de transport de base, un niveau d'authentification client supplémentaire et un niveau d'attribut de sécurité. WebSphere Application Server for z/OS prend en charge CSIv2, niveau de compatibilité 0.
- Sécurité Java 2
- Le modèle Sécurité Java 2 assure un contrôle avancé des accès aux ressources système et notamment au système de fichiers, aux propriétés système, à la connexion socket, à la création d'unités d'exécution, au chargement des classes, etc. Le code d'application doit accorder explicitement des droits d'accès à une ressource protégée.
- Java Virtual Machine (JVM) 5.0
- Le modèle de sécurité JVM fournit une couche de sécurité située au-dessus de la couche de sécurité du système d'exploitation. Par exemple, la sécurité JVM protège la mémoire contre les accès non limités, génère des exceptions lorsque des erreurs se produisent dans une unité d'exécution et définissent des types de tableau.
- Sécurité de la plateforme
Sécurité du système d'exploitation
L'infrastructure de sécurité du système d'exploitation sous-jacent fournit certains services de sécurité pour WebSphere Application Server. Ces services incluent la sécurité du système de fichiers qui protège les fichiers sensibles lors de l'installation du produit pour WebSphere Application Server. L'administrateur système peut configurer le produit pour obtenir des informations d'authentification provenant directement du registre d'utilisateurs du système d'exploitation.
Sécurité du système d'exploitation
L'infrastructure de sécurité du système d'exploitation sous-jacent fournit certains services de sécurité pour WebSphere Application Server. L'identité du système d'exploitation du serviteur, du contrôleur et du démon Started Task, telle que définie par le profil STARTED, est l'identité utilisée pour contrôler l'accès aux ressources, telles que les fichiers ou les sockets. La sécurité du système d'exploitation peut éventuellement fournir des services d'authentification en utilisant le registre d'utilisateurs du système d'exploitation local et/ou des services d'autorisation en utilisant le mécanisme d'autorisation SAF pour la console d'administration WebSphere et pour les applications exécutées sur le serveur d'applications.
L'administrateur doit non seulement connaître SSL (Secure Sockets Layer) et TLS (Transport Layer Security), mais également SAF (System Authorization Facility) et RACF (Resource Access Control Facility) ou un produit équivalent fondé sur SAF.
L'identité et la vérification des utilisateurs peuvent être gérées par le biais du système d'exploitation local utilisé comme registre d'utilisateurs, de la fonction RACF ou d'un produit équivalent fondé sur SAF. Un registre d'utilisateurs LDAP, personnalisé ou fédéré peut également être utilisé.
WebSphere peut être configuré pour utiliser l'autorisation SAF qui fait appel à la fonction RACF ou à un produit équivalent fondé sur SAF pour gérer et protéger les utilisateurs et regrouper les ressources. WebSphere peut également être configuré pour utiliser le mécanisme d'autorisation de WebSphere ou un fournisseur d'autorisation externe JACC.
Lorsque vous utilisez le système d'exploitation local en tant que registre d'utilisateurs et/ou le mécanisme d'autorisation SAF, Security Auditing est une fonction héritée de RACF ou des produits équivalents fondés sur SAF.
- Sécurité réseau
- Les couches de sécurité réseau fournissent l'authentification au niveau du transport et assurent l'intégrité et la confidentialité des données. Vous pouvez configurer SSL pour la communication entre des serveurs d'applications distincts. Vous pouvez également faire appel à la sécurité IP et au réseau VPN (Virtual Private Network) pour renforcer la protection des messages.
Chaque serveur d'applications du produit se compose d'un conteneur Web, d'un conteneur d'EJB (Enterprise Java Beans) et du sous-système d'administration.
Le gestionnaire de déploiement de WebSphere Application Server contient uniquement le code d'administration de WebSphere Application Server et la console d'administration.
La console d'administration est une application Web Java EE spécifique qui fournit l'interface graphique nécessaire pour effectuer des opérations d'administration. Les données de configuration de WebSphere Application Server sont stockées dans les fichiers de descripteur XML, qui doivent être protégés par la sécurité du système d'exploitation. Les mots de passe et les autres données de configuration confidentielles peuvent être modifiés à l'aide de la console d'administration. Toutefois, vous devez protéger ces mots de passe et ces données confidentielles. Pour plus d'informations, voir Codage des mots de passe dans les fichiers.
Pour les données de configuration, l'application Web de la console d'administration doit respecter une contrainte définie selon laquelle les servlets et les fichiers JSP (JavaServer Pages) de la console sont accessibles uniquement via la connexion SSL lorsque la sécurité administrative est activée.
Dans WebSphere
Application Server version 6.0.x et antérieure, le port HTTPS de la console d'administration a été configuré pour utiliser les fichiers DummyServerKeyFile.jks et DummyServerTrustFile.jks avec le certificat auto-signé par défaut. Les certificats et clés factices doivent être remplacés dès que l'installation de WebSphere
Application Server est terminée ; les clés sont communes à l'ensemble de l'installation, elles ne sont donc pas sécurisées. WebSphere
Application Server version 6.1 fournit une fonction de gestion intégrée des certificats et des clés, qui génère une clé privée distincte et un certificat auto-signé avec le nom d'hôte du serveur imbriqué pour autoriser la vérification du nom d'hôte. WebSphere
Application Server version 6.1 autorise également l'intégration avec une autorité de certification externe pour utiliser les certificats émis par cette dernière. Le processus d'installation des serveurs WebSphere
Application Server version 6.1 fournit une option permettant d'activer la sécurité administrative au cours de l'installation. Ainsi, un processus WebSphere
Application Server est sécurisé immédiatement après l'installation. WebSphere
Application Server version 7.0 étend les fonctions de gestion des certificats intégrés en créant un certificat chaîné (certificat personnel signé par un certificat racine) pour régénérer le certificat personnel sans affecter la sécurité établie. Il permet également de personnaliser le certificat au cours de la création du profil (vous pouvez importer votre propre certificat ou modifier le nom distinctif de celui créé par défaut) et de modifier le mot de passe par défaut du fichier de clés.
La figure suivante illustre un environnement informatique classique à plusieurs niveaux.
La figure suivante illustre un environnement informatique classique à plusieurs niveaux.
Sécurité administrative
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
Vous pouvez configurer ces protocoles pour qu'ils utilisent SSL (Secure Sockets Layer) lorsque vous activez WebSphere Application Server sécurité administrative. Le sous-système d'administration de WebSphere Application Server de chaque serveur utilise SOAP, les connecteurs JMX (Java Management Extensions) et RMI/IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol) pour transmettre les commandes d'administration et les données de configuration. Lorsque la sécurité administrative est désactivée, le connecteur JMX SOAP utilise le protocole HTTP et le connecteur RMI/IIOP utilise le protocole TCP/IP. Lorsque la sécurité administrative est activée, le connecteur JMX SOAP utilise toujours le protocole HTTPS. Lorsque la sécurité administrative est activée, vous pouvez configurer le connecteur JMX RMI/IIOP pour utiliser SSL ou TCP/IP. Il est recommandé d'activer la sécurité administrative, ainsi que SSL, pour protéger les données de configuration confidentielles.
Vous pouvez activer HTTPS pour les applications même si la sécurité administrative est désactivée. Vous pouvez configurer le port SSL d'un serveur spécifique en l'ajoutant à la liste des ports HTTP dans le conteneur Web du serveur, en plus de son ajout aux hôtes virtuels dans la configuration de l'environnement.
Vous pouvez connecter l'application Web à l'aide de HTTPS et du port approprié. Les communications internes de WebSphere
Application Server for z/OS n'utilisent pas SSL si vous n'activez pas la sécurité administrative.
Lorsque la sécurité administrative est activée, vous pouvez désactiver la sécurité d'application sur chaque serveur d'applications en désélectionnant l'option Activer la sécurité administrative au niveau du serveur. Pour plus d'informations, voir Sécurisation de serveurs d'applications spécifiques. La désactivation du serveur d'applications n'a pas d'incidence sur le sous-système d'administration de ce serveur, qui est contrôlé uniquement par la configuration de la sécurité. Le sous-système d'administration et le code de l'application disponible sur un serveur d'applications partagent la configuration du protocole de sécurité définie en option sur chaque serveur.
Sécurité des ressources Java EE
La sécurité des ressources Java EE est assurée par le conteneur Web et le conteneur d'EJB. Chacun d'eux offre deux types de sécurité, à savoir déclarative et par programmation.
Dans le premier cas, la structure de sécurité d'une application comprend l'intégrité et la confidentialité des données, les conditions d'authentification, les rôles de sécurité et le contrôle des accès. Le contrôle des accès est exprimé sous une forme extérieure à l'application. Notamment, le descripteur de déploiement est le vecteur principal d'une sécurité déclarative pour la plateforme Java EE. WebSphere Application Server gère des règles de sécurité Java EE, et notamment les informations issues du descripteur de déploiement et indiquées par les déployeurs et les administrateurs dans un jeu de fichiers XML. Au moment de l'exécution, le conteneur utilise les règles de sécurité définies dans les fichiers XML pour appliquer des contraintes de données et un contrôle d'accès.
Lorsque la sécurité déclarative s'avère insuffisante pour exprimer le modèle de sécurité d'une application, vous pouvez utiliser la sécurité par programmation pour prendre des décisions sur les accès. Lorsque la sécurité administrative est activée et que la sécurité du serveur d'applications n'est pas désactivée au niveau du serveur, la sécurité des applications, Java EE est appliquée. Si des règles de sécurité sont définies pour une ressource Web, le conteneur Web effectue un contrôle des accès lorsque la ressource est demandée par un client Web. Le conteneur Web interroge le client sur ses données d'authentification (lorsque celles-ci ne sont pas définies selon la méthode d'authentification spécifiée), vérifie que les contraintes relatives aux données sont respectées et détermine si l'utilisateur authentifié possède le rôle de sécurité requis. Le collaborateur de sécurité Web effectue un contrôle d'accès basé sur les rôles à l'aide de l'implémentation d'un gestionnaire d'accès. Ce dernier prend des décisions d'autorisation en fonction des règles de sécurité issues du descripteur de déploiement. Un principal d'utilisateur authentifié peut accéder au servlet ou au fichier JSP demandé s'il possède l'un des rôles de sécurité requis. Les servlets et les fichiers JSP peuvent utiliser les méthodes HttpServletRequest, isUserInRole et getUserPrincipal.
Lorsque la sécurité administrative et la sécurité d'application sont activées et que la sécurité au niveau du serveur d'applications n'est pas désactivée, le conteneur d'EJB applique le contrôle d'accès lors de l'appel de la méthode EJB.
Lorsque la sécurité globale est activée au niveau de la
cellule et que la sécurité du serveur d'applications n'est pas désactivée, le conteneur
d'EJB applique le contrôle d'accès lors de l'appel de la méthode EJB.
L'authentification est effectuée même si les droits d'accès de la méthode ne sont pas définis pour la méthode EJB spécifique. Le collaborateur de sécurité EJB assure le contrôle d'accès basé sur les rôles à l'aide de l'implémentation du gestionnaire d'accès. Ce dernier prend des décisions d'autorisation en fonction des règles de sécurité issues du descripteur de déploiement. Un principal de l'utilisateur authentifié est autorisé à accéder à la méthode EJB demandée s'il possède l'un des rôles de sécurité requis. Le code EJB peut utiliser les méthodes EJBContext, isCallerInRole et getCallerPrincipal. Utilisez le rôle Java EE fondé sur le contrôle des accès pour éviter que des utilisateurs non autorisés accèdent aux données stratégiques via Internet ou le réseau intranet. Voir Sécurisation des applications Web à l'aide d'un outil d'assemblage et Sécurisation des applications de bean enterprise.
Sécurité fondée sur les rôles
- Rôle Moniteur
- Un moniteur peut afficher les informations et l'état, mais ne peut effectuer aucune modification.
- Rôle Opérateur
- Un opérateur peut déclencher des modifications d'état lors de l'exécution, telles que le démarrage d'un serveur d'applications ou l'arrêt d'une application, mais il ne peut pas modifier la configuration.
- Rôle Configurateur
- Un configurateur peut modifier les informations de configuration, mais ne peut pas modifier l'état de l'environnement d'exécution.
- Rôle Administrateur
- Opérateur et configurateur, qui peut également modifier des données de configuration et des stratégies de sécurité, telles que les ID et mots de passe du serveur, activer ou désactiver la sécurité administrative et la sécurité Java 2 et mapper des utilisateurs et des groupes au rôle administrateur.
- iscadmins
- Le rôle iscadmins a des privilèges d'administrateur pour la gestion des utilisateurs et des groupes à partir de la console d'administration uniquement.
- Responsable du déploiement
- Un déployeur peut exécuter à la fois des actions de configuration et des opérations d'exécution sur des applications.
- AdminSecurityManager
- Un gestionnaire de sécurité administrative peut octroyer des rôles d'administration aux utilisateurs. De plus, lorsqu'une sécurité administrative à granularité fine est appliquée, les utilisateurs auxquels ce rôle a été octroyé peuvent gérer des groupes d'autorisation.
- Auditeur
- Un auditeur peut afficher et modifier les paramètres de configuration du sous-système d'audit de sécurité.
L'utilisateur qui possède le rôle Configurateur peut effectuer la plupart des opérations d'administration, notamment l'installation d'applications et de serveurs d'applications. Lorsque la sécurité administrative est activée, le configurateur ne dispose pas de droits suffisants pour effectuer certaines tâches de configuration, telles que la modification de l'identité et du mot de passe de WebSphere Application Server, la redéfinition du mot de passe et des clés LTPA (Lightweight Third-Party Authentication) et l'affectation des utilisateurs aux rôles de sécurité pour l'administration. Ces tâches de configuration confidentielles requièrent l'utilisation du rôle d'administration car l'ID du serveur est mappé au rôle Administrateur.
Activez la sécurité administrative de WebSphere Application Server pour assurer l'intégrité du sous-système d'administration. La sécurité du serveur d'applications peut être désactivée au cas par cas si vous ne possédez pas d'informations confidentielles à protéger. Pour garantir la sécurité d'administration, voir Autorisation de l'accès pour des rôles d'administration et Affectation d'utilisateurs et de groupes à des rôles.
Droits de sécurité Java 2
WebSphere Application Server utilise le modèle de sécurité Java 2 pour créer un environnement sécurisé et exécuter le code de l'application. La sécurité Java 2 fournit un contrôle des accès affiné et fondé sur les règles pour protéger les ressources système, telles que les fichiers, les propriétés système, l'ouverture des connexions socket, le chargement des bibliothèques, etc. La spécification Java EE version 1.4 définit la série de droits d'accès de sécurité Java 2 standard que les composants Web et EJB doivent posséder.
Droits de sécurité | Cible | Action |
---|---|---|
java.lang.RuntimePermission | loadLibrary | |
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | connexion |
java.io.FilePermission | * | lecture, écriture |
java.util.PropertyPermission | * | lecture |
Droits de sécurité | Cible | Action |
---|---|---|
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | connexion |
java.util.PropertyPermission | * | lecture |
/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
Ce fichier est utilisé comme règle par défaut pour la machine virtuelle Java (JVM).
${java.home}/jre/lib/security/java.policy
Ce fichier est utilisé comme règle par défaut pour la machine virtuelle Java (JVM).
${USER_INSTALL_ROOT}/properties/server.policy
Ce fichier est utilisé comme règle par défaut pour tous les processus serveur du produit.
$WAS_HOME/properties/server.policy
Ce fichier est utilisé comme règle par défaut pour tous les processus serveur du produit.
Pour simplifier la gestion, les règles de WebSphere Application Server reposent sur le type de ressource plutôt que sur la base de code (emplacement). Les fichiers suivants sont les fichiers de règles par défaut d'un sous-système WebSphere Application Server. Ces fichiers de règles, qui sont une extension de l'environnement d'exécution de WebSphere Application Server sont appelés interfaces SPI (Service Provider Programming Interfaces) et sont partagés par plusieurs applications Java EE :
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
- racine_profil/config/cells/nom_cellule/nodes/nom_noeud/spi.policy
Ce fichier est utilisé pour les ressources imbriquées définies dans le fichier resources.xml, telles que le service JMS (Java Message Service), JavaMail et les pilotes JDBC.
- racine_profil/config/cells/nom_cellule/nodes/nom_noeud/library.policy
Ce fichier est utilisé par la bibliothèque partagée définie par la console d'administration WebSphere Application Server.
- racine_profil/config/cells/nom_cellule/nodes/nom_noeud/app.policy
Ce fichier est utilisé comme règle par défaut pour les applications Java EE.
![[z/OS]](../images/ngzos.gif)
- $WAS_HOME/config/cells/nom_cellule/nodes/nom_noeud/spi.policy
Ce fichier est utilisé pour les ressources imbriquées définies dans le fichier resources.xml, telles que le service JMS (Java Message Service), l'API JavaMail et les pilotes JDBC.
- $WAS_HOME/config/cells/nom_cellule/nodes/nom_noeud/library.policy
Ce fichier est utilisé par la bibliothèque partagée définie par la console d'administration WebSphere Application Server.
- $WAS_HOME/config/cells/nom_cellule/nodes/nom_noeud/app.policy
Ce fichier est utilisé comme règle par défaut pour les applications Java EE.
![[IBM i]](../images/iseries.gif)
- racine_profil/config/cells/nom_cellule/nodes/nom_noeud/spi.policy
Ce fichier est utilisé pour les ressources imbriquées définies dans le fichier resources.xml, telles que le service JMS (Java Message Service), JavaMail et les pilotes JDBC.
- racine_profil/config/cells/nom_cellule/nodes/nom_noeud/library.policy
Ce fichier est utilisé par la bibliothèque partagée définie par la console d'administration WebSphere Application Server.
- racine_profil/config/cells/nom_cellule/nodes/nom_noeud/app.policy
Ce fichier est utilisé comme règle par défaut pour les applications Java EE.
Le chargement de bibliothèques dans WebSphere Application Server permet aux applications de quitter le bac à sable Java. WebSphere Application Server utilise un fichier de règles de filtrage pour vous alerter lorsque l'installation d'une application échoue car elle requiert des droits supplémentaires. Par exemple, il est recommandé de ne pas accorder le droit java.lang.RuntimePermission exitVM à une application afin que le code de l'application ne puisse pas arrêter WebSphere Application Server.
Les règles de filtrage sont définies par le masque du filtre dans le fichier racine_profil/config/cells/nom_cellule/filter.policy. En outre, WebSphere Application Server effectue un filtrage des droits d'exécution en fonction de la règle indiquée pour s'assurer que le code de l'application n'a pas reçu de droits dangereux pour l'intégrité du système.
De nombreuses applications développées pour des versions précédentes de WebSphere Application Server risquent donc de ne pas être conformes à la sécurité Java 2. Pour migrer rapidement ces applications vers la version la plus récente de WebSphere Application Server, vous pouvez leur accorder provisoirement le droit java.security.AllPermission dans le fichier was.policy. Testez ces applications pour vérifier qu'elles s'exécutent dans un environnement où la sécurité Java 2 est active. Par exemple, identifiez les droits supplémentaires éventuellement requis et accordez ces droits uniquement à une application spécifique. Si vous n'accordez pas le droit AllPermission aux applications, vous limitez les risques d'altération du système. Pour plus d'informations sur la migration des applications, voir Migration de la stratégie de sécurité Java 2.
L'environnement d'exécution de WebSphere Application Server utilise la sécurité Java 2 pour protéger les fonctions d'exécution confidentielles. Les applications auxquelles est accordé le droit AllPermission ont non seulement accès aux ressources système confidentielles, mais aussi aux ressources d'exécution de WebSphere Application Server. Elles peuvent altérer ces deux types de ressources. Dans certains cas où une application est considérée comme sûre, WebSphere Application Server permet de désactiver la sécurité Java 2 au niveau de chaque serveur d'applications. Vous pouvez appliquer la sécurité Java 2 par défaut dans la console d'administration et désélectionner l'indicateur de sécurité Java 2 pour la désactiver sur un serveur d'applications spécifique.
- Lorsque la sécurité Java 2 est appliquée, le code de l'application ne peut pas accéder aux classes d'exécution WebSphere Application Server chargées de gérer les données de configuration tant qu'il ne dispose pas des droits d'exécution WebSphere Application Server.
- Lorsque la sécurité Java 2 est appliquée, le code de l'application ne peut pas accéder aux fichiers de configuration XML de WebSphere Application Server tant qu'il ne dispose pas des droits de lecture et d'écriture nécessaires pour ces fichiers.
- Le sous-système d'administration JMX fournit SOAP sur HTTP ou HTTPS et une interface éloignée RMI/IIOP pour permettre aux programmes d'applications d'extraire et de modifier les fichiers et les données de configuration. Lorsque la sécurité administrative est activée, une application peut modifier la configuration de WebSphere Application Server dans la mesure où elle présente des données d'authentification valides et où l'identité de sécurité possède les rôles requis.
- Si un utilisateur peut désactiver la sécurité Java 2, il peut également modifier la configuration de WebSphere Application Server, y compris l'identité de sécurité de WebSphere Application Server, les données d'authentification et d'autres données confidentielles. Seuls les utilisateurs possédant le rôle de sécurité Administrateur sont autorisés à désactiver la sécurité Java 2.
- Comme l'identité de sécurité de WebSphere Application Server est associée au rôle Administrateur, seuls les utilisateurs possédant ce rôle sont autorisés à désactiver la sécurité administrative, à modifier les ID et mots de passe du serveur et à mapper les utilisateurs et les groupes vers des rôles d'administration.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Autres ressources d'exécution
Les autres ressources d'exécution de WebSphere Application Server sont protégées par un mécanisme identique, comme décrit précédemment. Il est indispensable d'activer la sécurité administrative de WebSphere Application Server et d'utiliser la sécurité Java 2 pour limiter l'accès des ressources locales aux applications. La spécification Java EE définit plusieurs méthodes d'authentification pour les composants Web : authentification de base HTTP, authentification par formulaire et authentification par certificat client HTTPS. Lorsque vous utilisez la connexion par certificat client, il est plus pratique pour le navigateur client que les ressources Web possèdent une contrainte pour les données confidentielles ou intégrales. Si un navigateur utilise HTTP pour accéder à la ressource Web, le conteneur Web le redirige automatiquement vers le port HTTPS. Le protocole de sécurité CSIv2 prend également en charge l'authentification par certificat client. Vous pouvez également utiliser l'authentification client SSL pour configurer des communications sécurisées entre un groupe de serveurs sélectionnés, sur la base d'une relation de confiance.
Le protocole de sécurité CSIv2 prend également en charge l'authentification par certificat client. Vous pouvez utiliser l'authentification client SSL pour configurer des communications sécurisées entre un groupe de serveurs sélectionnés, sur la base d'une relation de confiance.

Pour effectuer cette tâche, vous pouvez générer trois certificats à l'aide des utilitaires KEYMAN et de gestion des certificats. En outre, vous pouvez utiliser le certificat W et les certificats sécurisés A et B. Configurez le serveur HTTPS de WebSphere Application Server A pour qu'il utilise le certificat A et qu'il établisse une relation de confiance avec le certificat W.
Pour effectuer cette tâche, vous pouvez générer trois certificats à l'aide de la fonction RACF (Resource Access Control Facility), appelés certificats W, A et B. Configurez le plug-in WebSphere Application Server afin qu'il utilise le certificat W et les certificats sécurisés A et B. Configurez le serveur HTTPS de WebSphere Application Server A pour qu'il utilise le certificat A et qu'il établisse une relation de confiance avec le certificat W.
Serveur | Clé | Confiance |
---|---|---|
Plug-in WebSphere Application Server | W | A, B |
WebSphere Application Server A | A | W |
WebSphere Application Server B | B | W |
WebSphere Application Server Deployment Manager représente le point d'administration central. Les commandes de gestion système sont envoyées par le gestionnaire de déploiement à chaque serveur d'applications. Lorsque la sécurité administrative est activée, vous pouvez configurer WebSphere Application Server afin qu'il requiert l'authentification mutuelle et SSL.
Serveur | Clé | Confiance |
---|---|---|
WebSphere Application Server A | A | C, E |
WebSphere Application Server B | B | D, E |
WebSphere Application Server C | C | A, E |
WebSphere Application Server D | D | B, E |
WebSphere Application Server Deployment Manager E | E | A, B, C, D |
Lorsque WebSphere Application Server est configuré pour utiliser un registre d'utilisateurs LDAP (Lightweight Directory Access Protocol), vous pouvez également configurer le protocole SSL avec l'authentification mutuelle entre chaque serveur d'applications et le serveur LDAP en utilisant des certificats auto-signés afin que WebSphere Application Server transmette uniquement des mots de passe invisibles au serveur LDAP.
Dans cet exemple, les processus d'agent de noeud ne sont pas étudiés. Chaque agent de noeud doit communiquer avec les serveurs d'applications situés sur le même noeud et avec le gestionnaire de déploiement. Les agents de noeud doivent également communiquer avec les serveurs LDAP lorsqu'ils sont configurés pour utiliser un registre d'utilisateurs LDAP. Vous pouvez laisser le gestionnaire de déploiement et les agents de noeud utiliser le même certificat. Supposons que les serveurs d'applications A et C se trouvent sur le même noeud. L'agent de ce noeud doit posséder les certificats A et C dans son magasin de tiers dignes de confiance.
WebSphere
Application Server ne fournit pas d'utilitaires de configuration ou de gestion des registres. En outre, il ne définit pas les règles régissant les mots de passe du registre. Il est conseillé d'utiliser les règles recommandées par le registre, notamment la longueur définie pour le mot de passe et la date d'expiration.
Serveur et sécurité administrative
- Fonctionnalités CSIv2 (Common Secure Interoperability Version 2)
- Vérification d'identité sur le serveur en aval
- Sélection d'un mécanisme d'authentification
- Sélection d'un registre ou d'un référentiel
- Sécurité Java 2
- Service d'autorisation et d'authentification Java
- Sécurité des connecteurs Java EE
- Exception de contrôle d'accès pour la sécurité Java 2
- Implémentation d'un fournisseur d'authentification personnalisé à l'aide de JASPI