The IT Crew - The Best Way To Predict The Future Is To Invent IT™

Sécurisation des conteneurs d'EJBs

Cette présentation est un exemple de solution pour sécuriser les conteneurs d'EJBs entre deux cellules WebSphere Application Server v7r0, elle vous permettra d'implémenter ce type de solutions pour sécuriser les communications entre EJBs au sein de votre systèmes d'information :

ClassLoader WebSphere Application Server

Le chargeur de classe Java (Java Classloader) est une partie du JRE (Java Runtime Environment) qui charge dynamiquement les classes java dans la machine virtuelle java.

En général, les classes sont chargées seulement à la demande. Le JRE n’a pas besoin de savoir quels sont les fichiers et systèmes de fichiers correspondants grâce au chargeur de classe.

Le chargeur de classe se charge de retrouver l’emplacement des bibliothèques logicielles, de lire leur contenu et de charger les classes qu’elles contiennent.

Le schéma ci-dessous représente le fonctionnement du chargeur de classes (ClassLoader) WebSphere Application Server :

Le premier chargeur de classes correspond au chargeur de classes standard de Java. Il utilise la variable d’environnement CLASSPATH pour charger les classes.

Le second chargeur de classe concerne des classes spécifiques à WebSphere et utilise la variable d’environnement ws.ext.dirs pour charger les classes. Outre le chargement de tout code utilisateur, ce ClassLoader charge également toutes les classes WebSphere et JEE ( anciennement J2EE) qui sont nécessaires à l’exécution.

Le troisième chargeur de classe, appelé Application EXtension ClassLoader (AEX), peut être utilisé pour les extensions d’applications. Il charge les JARs à partir du répertoire  <was>/lib/app.

Pour finir, les modules en cours d’exécution sur le serveur d’application sont chargés par un ou plusieurs chargeurs de classes de modules. Ils suivent les règles de chargement des classe JEE discutées précédemment pour charger les classes et fichiers JAR de votre application.

Le concept le plus important dans la figure ci-dessus est que chaque chargeur de classe est défini comme un enfant du chargeur de classes parent.

Par ailleurs, un chargeur de classes peut voir son système de délégation actif ou non. Les deux premiers ClassLoaders Java et WebSphere ont activé ce système de délégation, les deux derniers AEX et module (spécifications JEE) l’on désactivé.

Lorsque la délégation est activée, un ClassLoader délègue chaque première requête à ses ClassLoaders parents. Si aucun des chargeurs de classe parents ne retrouve la classe demandée, le chargeur de classe de la classe courante est alors chargé.

Lorsque la délégation est désactivée, le ClassLoader tente d’abord de charger la classe elle-même. Si elle ne peut pas charger la classe, ce ClassLoader demande à son parent de charger la classe.

Dans les deux cas, les demandes ne peuvent que remonter cette arborescence de classe. Si par exemple le ClassLoader WebSphere est paramétré pour trouver une classe dans un module JEE, il ne peut pas descendre au ClassLoader du module pour trouver cette classe, et une exception ClassNotFoundException se produira. Cependant, si une classe est chargée par un ClassLoader, toutes les nouvelles classes qu’il tentra de charger utiliseront le même ClassLoader courant, ou, à défaut, le parent.

Compte tenu des propriétés de délégation du ClassLoader WebSphere, l’ordre de recherche efficace devient:

1) Module ClassLoader
2) AEX - Application Extensions ClassLoader
3) ClassLoader Java
4) WebSphere ws.ext.dirs ClassLoader

Deux cas peuvent poser problème :
- WebSphere, JEE, et toutes les classes globales ne peuvent pas «voir» les classes qui sont contenues dans vos applications. Si vous ajoutez un fichier JAR dans le classpath global ou les propriétés ws.ext.dirs, il ne pourrait pas dépendre de classes contenues dans vos modules.
- Si vous avez besoin d’ajouter des pilotes de bases de données ou d’autres JARs à votre classpath, vous devez les ajouter à la propriété ws.ext.dirs, et non au classpath global. Si vous les ajouter dans le classpath global par erreur, les modules ne seront pas en mesure de charger (par exemple) la connexion à la base de donnée si le paramétrage de ce dernier s’effectue via des classes situées dans les JARs du module JEE.  Une erreur ClassNotFoundException semblera provenir du pilote de base alors qu’il s’agira d’une impossibilité pour les classes de pilote de base de données de charger le les classes contenues dans le classpath des modules JEE.

Une technique courante et portable permettant de trouver des ressources (fichiers de propriétés, des images et ainsi de suite) est d’utiliser le méthodes de chargement de classes de findResourceXX. Sur la base de la discussion précédente, vous pouvez voir pourquoi il est important d’utiliser le chargeur de classe pour ce travail. Par exemple, si vousutilisez le chargeur de classes WebSphere, vous ne serez pas en mesure de trouver toutes les ressources dans vos modules.

IBM HTTP Server 32 bits ou 64 bits ?

IBM HTTP Server v7.0  (IHS) est livré avec le produit WebSphere Application Server v7.0.

Le produit WebSphere Application Server V7.0 est disponible en 32-bit et 64-bit pour la plupart des systèmes d’exploitation et architectures de processeur.

L’édition d’IBM HTTP Server V7.0 incluse dans l’image d’installation livrée avec WebSphere Application Server V7.0 64-bit n’est pas nécessairement une édition du serveur HTTP en 64-bit.  En effet, la plupart des offres d’IBM HTTP Server V7.0 sont en 32-bit. Cependant le SDK fournit pour l’IHS reste en 64 bits pour les plateformes 64 bits (gestion du plug-in).

Il n’existe que deux version du serveur IHS en 64 bits, et ce uniquement pour les plateformes  Solaris x64 et HP-UX (processeurs Itanium ®). Toutes les autres offres IBM HTTP Server V7.0 distribués sont des logiciels 32-bit.

Source ...