Les raisons de ce petit projet

J’ai, dernièrement, eu un petit problème sur un serveur Websphere dont j’assure l’administration. Une page web (JSP) s’exécutant sur ce serveur d’application avait un bug (une boucle infinie). Cela a été relativement difficile à identifier car rien ne me permettait d’identifier les pages en cours d’exécution sur ce serveur.
Pour palier à ce manque d’informations j’ai réalisé un petit filtre qui me permet de suivre cela.
Je vous propose ce petit utilitaire à titre d’exemple de ServletFilter en espérant que cela pourra vous être utile.

(Lire la suite…)

Le problème

Lors de son installation Websphere est configuré pour accepter tout identifiant (sans mot de passe) pour accéder à la console d’administration. Vous pouvez saisir n’importe quoi cela passe parfaitement, il n’y a aucune vérification.
Cela est bien sûr non acceptable et dans les versions récentes un « Wizard » vous guide pour activer la sécurité globale mais cela active toute la sécurité J2EE ce qui est souvent bien inutile.

Le but de ce petit article est d’expliquer (j’espère clairement) comment sécuriser l’accès à la console d’administration WAS sans activer l’ensemble de la sécurité J2EE.

(Lire la suite…)

En déambulant sur le net je suis tombé par hasard sur trois blogs très intéressants.

Le premier http://blog.xebia.fr propose entre autre un « Livre Blanc » sur la migration vers Websphere 6.1 qui je trouve présente bien cela en restant relativement simple.

Le second nous présente une série de quatre articles sur le « Tuning de DB2 pour améliorer la rapidité sur un gros volume de données » j’ai trouvé cela fort bien fait et m’a permis d’apprendre certaines nouvelles choses sur DB2.

Enfin Didier Durand nous présente sur son blog le projet NACA qui a conduit au remplacement d’une architecture Mainframe IBM Cobol/CICS vers une solution Linux/Java en convertissant automatiquement plus de 4 millions de lignes de codes.

Description

J’ai dernièrement eu un petit problème en essayant de déployer dans WAS 6.0 (Websphere Application Serveur 6) une application incluant la signature de PDF. Lors de l’exécution de la servlet de signature j’avais le problème suivant :

java.lang.Exception: java.lang.Exception: java.io.IOException:
Error in loading the keystore: Private key decryption error:
(java.lang.SecurityException: Unsupported keysize or algorithm parameters)

Résolution

Cette erreur est causée par les librairies JCE utilisées par la machine virtuelle java exécutant WAS. Cette JVM est en standard la version « IBM 1.4.2″ et cette dernière possède un support limité des algorithmes de cryptographie. Pour corriger cela il suffit de remplacer 2 fichiers .jar dans la configuration de la JVM IBM (local_policy.jar et US_export_policy.jar).
Ces fichiers sont dans le répertoire $JAVA_HOME/jre/lib/security (par exemple /usr/lib/jvm/jre-ibm/lib/security ou /opt/IBM/WebSphere/AppServer/java/jre/lib/security).
Vous pouvez télécharger les librairies non limitées http://www-128.ibm.com/developerworks/java/jdk/security/142/ (fichier unrestrict142.zip)

Une fois le fichier téléchargé vous devez :

• Décompresser le fichier téléchargé
• Vérifier que ce fichier contient bien local_policy.jar et US_export_policy.jar
• Arrêter Websphere
• Sauvegarder les anciens fichiers
• Remplacer les deux fichiers
• Redémarrer WAS

Exécuter Websphere sous un autre utilisateur que root

Pour son installation Websphere demande obligatoirement d’utiliser le compte « root ». Au final j’ai été très surpris de constater que WAS s’exécute tournant par défaut sur le compte « root », la procédure d’installation ne demandant la création ou l’utilisation d’aucun autre compte. Cela me dérange car l’ensemble des objets créés par WAS sont alors la propriété de « root ».

Mais néanmoins il est très facile de corriger ce problème.

Modifications à effectuer

Je considère que vous avez créé l’utilisateur et le groupe souhaités. Il suffit alors de se connecter à la console d’administration de Websphere pour modifier les Paramètres d’exécution des processus.

Cette page est accessible via les menus Serveurs > Serveurs d’applications > nom_du_serveur puis (dans les options de cette page) Infrastructure du serveur > Gestion des processus et Java > Exécution des processus.

Vous pouvez alors modifier l’utilisateur qui exécutera le processus principal de Websphere et son groupe. Cela permet par exemple aux objets (images, fichiers, …) créés par WS d’être accessibles à d’autres utilisateurs que root.

Attention : après cette modification

– vous devez bien évidemment modifier le propriétaire des fichiers et répertoires accessibles à Websphere ( $WAS_HOME/ et vos WebApp et fichiers externes si besoin)

– De plus la sécurité globale en utilisant le « Système d’exploitation local » ne fonctionne que si l’utilisateur d’exécution de Webspeher est root sous Unix