Sécurité des connecteurs Java EE

L'architecture de connecteur Java™ EE (Java 2 Platform, Enterprise Edition) définit une architecture standard permettant de connecter la plateforme J2EE à des systèmes EIS (Enterprise Information Systems) hétérogènes. Les exemples d'EIS incluent ERP (Enterprise Resource Planning), le traitement transactionnel de grand système et les systèmes de base de données.

L'architecture de connecteur permet à un fournisseur d'EIS de fournir un adaptateur de ressources à son système EIS. Un adaptateur de ressources est un pilote logiciel au niveau système qui permet à une application Java de se connecter à un système EIS. L'adaptateur de ressources se connecte à un serveur d'applications et offre une connectivité entre le système EIS, le serveur d'applications et l'application d'entreprise. L'accès aux informations des systèmes ESI requiert généralement un contrôle des accès pour empêcher les accès non autorisés. Les applications J2EE doivent s'authentifier auprès du système EIS pour pouvoir ouvrir une connexion.

L'architecture de sécurité de connecteur J2EE est conçue pour développer le modèle de sécurité complet pour les application J2EE de manière à inclure l'intégration à des environnements EIS. Un serveur d'applications et un EIS collaborent pour assurer l'authentification exacte d'un principal de ressources, qui établit une connexion avec un EIS sous-jacent. Même si d'autres mécanismes peuvent être définis, l'architecture du connecteur reconnaît les mécanismes d'authentification ci-après :
  • BasicPassword : Mécanisme d'authentification via ID utilisateur et mot de passe de base propre à un système EIS
  • [AIX Solaris HP-UX Linux Windows][IBM i]Kerbv5 : Mécanisme d'authentification basé sur Kerberos Version 5

Les applications indiquent si une connexion gérée par l'application ou par un conteneur doit être utilisée dans les l'élément resource-ref du descripteur de déploiement. Chaque élément resource-ref décrit une liaison de référence de la fabrique de connexion unique. L'élément res-auth d'un élément resource-ref, dont la valeur est Application ou Container, indique si le code du bean enterprise peut effectuer une connexion ou si le serveur d'applications peut se connecter au gestionnaire de ressources à l'aide de la configuration de mappage de principal. L'élément resource-ref est généralement défini au moment de l'assemblage de l'application à l'aide d'un outil d'assemblage. L'élément resource-ref peut également être défini ou redéfini au moment du déploiement.

Connexion gérée par l'application

Pour accéder à un système EIS, les applications localisent une fabrique de connexions dans l'espace de noms JNDI (Java Naming and Directory Interface) et appellent la méthode getConnection sur cet objet fabrique de connexions. La méthode getConnection peut requérir un ID utilisateur et un mot de passe sous forme d'argument. Une application J2EE peut transmettre un ID utilisateur et un mot de passe à la méthode getConnection, qui transmet à son tour les informations à l'adaptateur de ressources. Toutefois, la définition d'un ID utilisateur et d'un mot de passe dans le code de l'application peut compromettre la sécurité.

Les développeurs et les testeurs de l'entreprise peuvent accéder à l'ID utilisateur et au mot de passe, s'ils apparaissent dans le code source Java. En outre, les utilisateurs peuvent les visualiser s'ils annulent la compilation de la classe Java.

L'ID utilisateur et le mot de passe ne peuvent pas être modifiés sans nécessiter une modification du code. Le code de l'application peut également extraire des jeux d'ID utilisateur et de mots de passe de la zone de stockage persistante ou d'un service externe. Cette méthode requiert l'intervention des administrateurs informatiques, qui doivent configurer et gérer un ID utilisateur et un mot de passe à l'aide du mécanisme propre à l'application.

Pour accéder aux données d'authentification, le serveur d'applications prend en charge un alias d'authentification géré par un composant sur une ressource. Les données d'authentification s'appliquent à toutes les références à la ressource. Cliquez sur Ressources > Adaptateurs de ressources > Fabriques de connexions J2C > nom_configuration. Sélectionnez Utiliser l'alias d'authentification géré par composant.

Si res-auth=Application, les données d'authentification sont collectées des éléments suivants, dans l'ordre :
  1. L'ID utilisateur et le mot de passe transmis à la méthode getConnection
  2. L'alias d'authentification géré par composant dans la fabrique de connexions ou la source de données
  3. Le nom d'utilisateur et le mot de passe des propriétés personnalisées dans la source de données

Les propriétés du nom d'utilisateur et du mot de passe peuvent être au préalable définies dans le fichier RAR (Resource Adapter Archive).

[AIX Solaris HP-UX Linux Windows][z/OS]Ces propriétés peuvent également être définies dans la console d'administration ou à l'aide d'une procédure de scriptage wsadmin dans la section Propriétés personnalisées.

[IBM i]N'utilisez pas les propriétés personnalisées qui permettent aux utilisateurs de se connecter aux ressources.

Connexion gérée par conteneur

L'ID utilisateur et le mot de passe du système EIS (Enterprise Information Systems) cible peuvent être fournis par le serveur d'applications. Le produit fournit des fonctionnalités de connexion gérée par conteneur. Le serveur d'applications localise les données d'authentification appropriées pour le système EIS afin de permettre au client d'établir une connexion. Lorsqu'il est configuré pour utiliser la connexion gérée par conteneur, le code de l'application n'a pas à fournir d'ID utilisateur et de mot de passe lors de l'appel de getConnection. En outre, les données d'authentification doivent s'appliquer à toutes les références à une ressource. Le serveur d'applications fait appel au mécanisme d'authentification intégrable JAAS (Java Authentication and Authorization Service) pour utiliser une configuration de connexion JAAS préconfigurée et un module de connexion pour mapper l'identité de sécurité d'un client et les justificatifs d'une unité d'exécution à un ID utilisateur et à un mot de passe préconfigurés.

Le produit prend en charge un module de mappage LoginModule par défaut qui mappe l'identité d'un client sur l'unité d'exécution vers un ID utilisateur et un mot de passe préconfigurés pour le système EIS indiqué. Le module de mappage par défaut est un module LoginModule JAAS spécialisé qui renvoie un justificatif PasswordCredential défini par les données d'authentification J2C (Java 2 connector) configurées. Le module de mappage LoginModule par défaut lance une recherche dans les tables mais n'effectue pas d'authentification à proprement parler. L'ID utilisateur et le mot de passe sont stockés avec un alias dans la liste des données d'authentification J2C.

La liste des données d'identification J2C se trouve dans le panneau Sécurité Globale accessible depuis Java Authentication and Authorization Service > Données d'authentification J2C. La fonction de mappage du principal et du justificatif par défaut est définie par la configuration de connexion JAAS par application DefaultPrincipalMapping.

Les données d'authentification J2C modifiées à l'aide de la console d'administration sont appliquées lorsque la modification est sauvegardée dans le référentiel et que la connexion test est effectuée. En outre, les données d'authentification J2C modifiées à l'aide du scriptage wsadmin sont appliquées au démarrage ou au redémarrage d'une application pour un processus de serveur d'applications donné. La modification des données d'authentification J2C est appliquée en appelant la méthode du MBean SecurityAdmin, updateAuthDataCfg. Affectez au paramètre HashMap la valeur null pour permettre au MBean Securityadmin de régénérer les données d'authentification J2C à partir des valeurs les plus récentes du référentiel.

Ne modifiez pas la configuration de connexion DefaultPrincipalMapping car le produit a amélioré les performances de cette configuration de mappage par défaut couramment utilisée. Le produit ne prend pas en charge la modification de la configuration DefaultPrincipalMapping, la modification du module LoginModule par défaut ni l'empilement d'un module LoginModule personnalisé dans la configuration.

[z/OS]Sous z/OS, si aucun ID ou mot de passe n'est disponible ou défini par un alias, l'environnement d'exécution de WebSphere Application Server recherche un ID utilisateur SAF (System Authorization Facility) dans le sujet.

Pour la plupart des systèmes, la méthode par défaut associée à un mappage plusieurs à un est suffisante. Toutefois, le produit ne prend pas en charge les configurations de mappage de principal et de justificatif personnalisées. Les modules de mappage personnalisés peuvent être ajoutés à la configuration JAAS de connexion d'application en créant une configuration de connexion JAAS avec un nom unique. Par exemple, un module de mappage personnalisé univoque peut fournir un mappage ou des fonctions Kerberos.

Les connexions accréditées incluent également un mappage univoque tout en prenant en charge la propagation de l'identité client. De plus, en utilisant l'objet de contexte sécurisé DB2, les connexions accréditées peuvent tirer parti du regroupement de connexions afin de réduire la baisse des performances due à la fermeture et à la réouverture des connexions avec une identité différente. L'utilisation des connexions accréditées améliore également la sécurité de votre base de données DB2 en supprimant le besoin d'attribuer tous les droits à un seul utilisateur. La connexion est établie par un utilisateur dont les justificatifs sont approuvés par le serveur DB2 afin d'ouvrir la connexion et le même utilisateur est également approuvé pour garantir l'identité des autres utilisateurs accédant au serveur DB2 à partir de l'application. Une nouvelle configuration de mappage appelée TrustedConnectionMapping a été créée pour implémenter les connexion accréditées.

Vous pouvez également utiliser la console d'administration WebSphere Application Server pour associer les références de la fabrique de connexions du gestionnaire de ressources à l'une des fabriques de ressources configurées. Si la valeur de l'élément res-auth est Container dans le descripteur de déploiement de votre application, vous devez spécifier la configuration du mappage. Pour définir la configuration de mappage, utilisez le lien Références de ressources sous Références dans le panneau Applications > Types d'application > Applications d'entreprise Websphere > nom_application. Pour plus informations, voir la section sur le mappage des références de ressources à des références.

Modules de mappage J2C et propriétés de mappage

Les modules de mappage sont des modules de connexion JAAS spéciaux qui fournissent des fonctionnalités de mappage de principal et de justificatif. Vous pouvez définir et configurer des modules de mappage personnalisés à l'aide de la console d'administration.

Vous pouvez également définir et transmettre les données de contexte aux modules de mappage en utilisant les options de connexion de chaque configuration de connexion JAAS. Dans le produit, vous pouvez également définir les données de contexte à l'aide des propriétés de mappage de chaque liaison de référence de la fabrique de connexions.

Les options de connexion définies dans chaque configuration de connexion JAAS sont partagées entre toutes les ressources utilisant la même configuration de connexion JAAS et les mêmes modules de mappage. Les propriétés de mappage définies pour chaque liaison de référence de la fabrique de connexions sont exclusivement utilisées par cette référence de ressource.

Etudions un scénario où un service de mappage externe est utilisé.

Vous pouvez par exemple utiliser le service GSO (Global Sign-On) de Tivoli Access Manager. Utilisez Tivoli Access Manager GSO pour rechercher les données d'authentification des deux serveurs dorsaux.

Vous disposez de deux serveurs EIS : DB2 et MQ. Les données d'authentification de DB2 sont différentes de celles de MQ. Utilisez l'option de connexion dans une configuration de connexion JAAS par mappage pour indiquer les paramètres nécessaires à l'établissement d'une connexion au service GSO de Tivoli Access Manager. Utilisez les propriétés de mappage d'une liaison de référence de la fabrique de connexions pour indiquer quel serveur EIS requiert l'ID utilisateur et le mot de passe.

Pour plus d'informations sur le développement d'un module de mappage, voir la rubrique Modules de mappage de principal J2C.

Remarque :
  • La configuration de mappage au niveau de la fabrique de connexion est désormais effectuée au niveau de la référence de la référence de la fabrique de connexions du gestionnaire de ressources. Les modules de connexion de mappage développés à l'aide des types de rappel JAAS de WebSphere Application Server, version 5 peuvent être utilisés par la référence de la fabrique de connexions du gestionnaire de ressources, mais les modules de connexion de mappage ne peuvent pas tirer parti de la fonction des propriétés de mappage personnalisées.
  • La liaison de référence de la fabrique de connexion prend en charge les propriétés de mappage et transmet ces propriétés aux modules de connexion de mappage à l'aide d'un nouveau rappel WSMappingPropertiesCallback. En outre, le rappel WSMappingPropertiesCallback et le nouveau rappel WSManagedConnectionFactoryCallback sont définis dans le package com.ibm.wsspi. Utilisez les nouveaux modules de connexion de mappage avec les nouveaux types de rappel.

Distribution sécurisée des messages avec élément SecurityContext entrant

Les informations de sécurité peuvent être fournies par un adaptateur de ressources EIS au serveur d'applications à l'aide d'un contexte de sécurité de flux entrant. Le mécanisme du contexte de sécurité de flux entrant permet au gestionnaire de travaux d'exécuter les actions d'une instance de travail sous une identité établie. Ces actions incluent la distribution de messages à des noeuds finals de message Java EE traités en tant que beans gérés par message sous une identité configurée dans un domaine de sécurité du serveur d'applications.

Avertissement : Le contexte de sécurité de flux entrant est pris en charge uniquement pour les adaptateurs de ressources compatibles avec JCA 1.6. Actuellement, le produit ne fournit pas d'adaptateur de ressources intégré prenant en charge un contexte de sécurité de flux entrant. L'utilisation de l'élément entrant SecurityContext pour sécuriser la distribution des messages nécessite un adaptateur de ressources prenant en charge le contexte de sécurité de flux entrant et de messagerie Java EE.

La distribution sécurisée des messages vers un noeud final de message exige que la sécurité globale soit activée dans la configuration de sécurité globale. Elle requiert également l'activation de la sécurité des applications sur le serveur d'applications qui héberge l'application fournissant le bean géré par message du noeud final de message. Pour plus d'informations sur la sécurité globale, voir la rubrique "Paramètres de sécurité globale".

La stratégie de sécurité du descripteur de déploiement d'application doit être configurée avec des rôles associés à des identités d'utilisateur dans le domaine de l'application, qui est le registre d'utilisateurs du domaine de sécurité qui définit les portées de l'application. Cette configuration de sécurité active la sécurité EJB et autorise les identités d'utilisateur spécifiques du domaine de l'application à accéder aux méthodes MDB. Pour plus d'informations sur la sécurité, voir la rubrique "Sécurité".

La distribution sécurisée des messages exige également que l'adaptateur de ressources définisse les implémentations des interfaces WorkContextProvider et SecurityContext. Afin d'assurer la sécurité d'un message distribué, un adaptateur de ressources soumet d'abord une instance de travail qui fournit une implémentation SecurityContext, que le gestionnaire de travaux utilise pour établir l'objet de l'exécution pour cette instance.

Tout en établissant l'objet de l'exécution, un élément SecurityContext peut fournir des implémentations de rappels JASPIC (Java Authentication Service Provider Interface for Containers) que le gestionnaire de travaux utilise pour déterminer les identités d'appelant et de groupe (CallerPrincipalCallback, GroupPrincipalCallback), et pour authentifier l'identité et le mot de passe de l'appelant (PasswordValidationCallback). Si l'identité de l'appelant se trouve dans le domaine de l'application, le gestionnaire de travaux vérifie cette identité en construisant une instance WSSubject contenant le principal de l'appelant, tout principal de groupe et l'ensemble des justificatifs privés.

SecurityContext peut également fournir un objet d'exécution constitué d'une instance WSSubject créée par un autre module de connexion ou d'authentification. Le gestionnaire de travaux accepte cette instance WSSubject uniquement lorsque son principal d'appelant se trouve dans le domaine d'application ou dans un domaine sécurisé. Pour plus d'informations sur les domaines, voir la rubrique "Configuration de domaines sécurisés entrants pour plusieurs domaines de sécurité".

Le gestionnaire de travaux rejette une instance de travail (Work) lorsqu'elle ne peut pas établir d'instance WSSubject. Sinon, il répartit l'instance sur une unité d'exécution gérée sous l'instance WSSubject qui a été vérifiée ou acceptée. Si SecurityContext ne fournit aucune identité d'appelant, l'instance Work est répartie sous une instance WSSubject contenant le principal de l'appelant non authentifié.

Une fois répartie, une instance Work peut tenter de distribuer des messages au bean géré par message de l'application sécurisée. Tous les messages sont distribués sous l'instance WSSubject établie pour l'instance Work. Le collaborateur de sécurité EJB permet d'accéder à la méthode onMessage du bean géré par message chaque fois que le principal de l'appelant de l'instance WSSubject est associé à un rôle déclaré dans le descripteur de déploiement d'application. Sinon, le collaborateur refuse l'accès et le message n'est pas distribué. Au cours de la distribution, le bean géré par message peut utiliser les méthodes de contexte d'EJB (isCallerInRole et getCallerPrincipal) pour prendre des décisions d'accès supplémentaires, et le bean géré par message peut accéder à d'autres entités dans le domaine de sécurité pour lequel le principal de l'appelant possède des droits.


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_j2csecurity
Nom du fichier : csec_j2csecurity.html