Affichage des articles dont le libellé est rational application developper. Afficher tous les articles
Affichage des articles dont le libellé est rational application developper. Afficher tous les articles

mardi 30 juin 2009

Publier un EAR sur un WebSphere distant avec Maven 2

Voici comment publier un EAR créé avec RAD par exemple sur un serveur WebSphere 6 installé sur une autre machine avec le plugin Was6 Maven Plugin.

Les informations sur le site du plugin n'étant pas très nombreuses, je trouve bon de présenter rapidement ici un cas concret pour son utilisation !

Il faut que le serveur WebSphere sur la machine distant soit démarré. ET, je le précise car c'est pas clair sur le site du plugin, il FAUT qu'un WebSphere soit installé sur le poste à partir duquel on envoi le EAR. Il ne faut pas qu'il soit démarré. En effet, le plugin a besoin de scripts pour le déploiement du EAR d'où la nécessité d'une installation de WS.

Après avoir généré l'EAR, il suffit simplement de taper la commande Maven 2 dans son projet Web :
mvn was6:installApp
-Dwas6.host=MON_SRV
-Dwas6.conntype=SOAP
-Dwas6.username=MON_USR
-Dwas6.password=MON_PSW
-Dwas6.updateExisting=false
-Dwas6.earFile=monProjet-web.ear
-Dwas6.port=8880
(les retours à la lignes sont là par soucis
de lisibilité)

Il faut remplacer :
MON_SRV par le nom ou l'adresse du serveur distant où déployer l'EAR sur le WebSphere
MON_USR et MON_PSW sont utilisés si la sécurité est activé sur le WebSphere distant (sinon ne pas renseigner ces valeurs)
updateExisting : si l'application a deja été déployée une fois, mettre à true pour qu'on fasse un update
earFile : le chemin vers l'EAR à déployer

C'est donc tout simple !

NOTE méga importante : j'ai remarqué que le déploiement ne fonctionne pas si le chemin vers votre projet Web contient des espaces (erreur lors du build avec ant) ! Déplacer éventuellement le projet pour que son chemin n'en contienne pas ! je vous aurez prévenu ! :)

Néanmoins, si comme moi, vous avez activé la sécurité SSL sur votre serveur WebSphere, il FAUT le certificat de sécurité du serveur pour que la commande fonctionne !

Voici comment procéder (inspiré de la doc d'IBM : http://publib.boulder.ibm.com/infocenter/iwphelp/v2r5m1/index.jsp?topic=/com.ibm.wcs.ic.doc_2.5.1/infocenter/i_sec_t_impcertwasstores.html) : il faut exporter le certificat de sécurité SSL depuis le serveur distant et l'installer dans le WebSphere de la machine à partir de laquelle est déployée l'application.

Exporter le certificat :
1. Ouvrir la console administrative du serveur WebSphere distant
2. Aller dans Sécurité/Certificat SSL et gestion des clés
3. Cliquer sur 'Gérer les configurations de sécurité du noeud final'
4. Déplier 'Communication entrante/...Cell/nodes/servers/server1/ (varie selon le serveur)
5. Cliquer sur 'SOAP_CONNECTOR_ADDRESS'
6. Dans l'écran, cliquer sur 'Gérer des certificats'
7. Cocher dans la liste des certificats, le certificat concerné (en général Default) puis cliquer sur Extraire
8. Dans l'écran d'extraction, saisir un nom (par ex monCertificat.cer) et sélectionner 'Données ASCII codées en base 64' pour le type de données
9. Cliquer sur Ok, le certificat est extrait
10.Récupérer le fichier du certificat en allant dans le profil du WebSphere, par exemple dans C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\etc

Importer le certificat sur la machine à partir de laquelle est déployée l'application :
1. Aller dans le répertoire du profil WebSphere de la machine à partir de laquelle est déployée l'application (par exemple dans C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01)
2. Exécuter le fichier bat ikeyman.bat se situant dans bin/
3. Le gestionnaire des clés IBM s'ouvre
4. Cliquer sur ouvrir un fichier : pour le type de base de données de clés, sélectionner PKCS12.
5. Ouvrir le fichier trust.p12 du répertoire etc/ du profil (par exemple dans C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\etc\)
6. Si on vous demande un mot de passe, le mot de passe par défaut est WebAS
7. Une fois chargé, cliquer sur Ajout
8. Sélectionner le certificat récupéré du serveur distant (voir plus haut)
9. Une fois ajouté, sauvegarder en écrasant le fichier trust.p12 ouvert plus haut (mettre le même mot de passe)
10. Vous pouvez quitter ikeyman

La commande Maven 2 devrait désormais fonctionner !

Voili, c'est tout !

mardi 9 juin 2009

Erreur IWAE0006E au déploiement d'une application WebSphere

Bonjour,
depuis 3 jours, sur ma machine, impossible de déploier mon application J2EE sur WebSphere en utilisant RAD !

J'avais une erreur IWAE0006E dans la console se plaignant que mon application n'était pas valide et que le web.xml manquait à l'appel ! Que nenni ! Tout était parfait pourtant dans mon projet sous RAD, j'ai trituré dans tous les sens pendant 3 jours pensant que le problème venait de ma configuration (tout marchait bien il y a encore 1 semaine!)...

J'aurai du en fait chercher du coté de mon ami Google : voici un lien qui corrigera le problème (en anglais) : http://www-01.ibm.com/support/docview.wss?uid=swg21255956

Pour résumer (je vous laisse lire l'article d'IBM), si par hasard vous avez modifié vos répertoires sources du projet (propriétés du projet/chemin de génération JAVA/Sources) et que vous avez le malheur d'avoir mis une source vers un répertoire qui n'existe plus, ça empeche le déploiement de l'application avec l'erreur enigmatique IWAE0006E dans la console...

La combine consiste à virer de la configuration du projet les répertoires sources qui n'existent plus (en modifiant le fichier settings/org.eclipse.wst.common.component de votre projet)

Voili, bon courage avec RAD et WebSphere ! (il en faut parfois!)

mercredi 13 mai 2009

Utiliser la sécurité de WebSphere pour un projet Web dans RAD

Ce petit tuto va vous expliquer rapidement comment mettre en place un système de login robuste et performant dans un projet Web sous Web Sphere (version 6.1 ici).

On va faire cela sous RAD (Rational Application Developper).

Dans 80% des applications (et dans 99% en entreprise), on a besoin d'authentifier un utilisateur. Par authentification, on entends un système qui permet d'identifier un utilisateur de l'application, en l'occurrence ici, par son login et son mot de passe.

Gérer l'authentification est très sensible car elle peut poser des problèmes de sécurité pourtant c'est un élément élémentaire pour toute application Web. Heureusement pour nous, avec trés peu d'effort, on peut mettre en place un système trés fiable et souple en utilisant l'authentification intégrée à Web Sphere. En 10 min on pourra mettre en place ce système ! alors qu'il faudrait plusieures heures de travail si on le développerai soit même (avec tous les risques que cela comporte).

Supposons que vous avez une projet Web déjà tout prêt (projet JSP, Struts 2 etc... peu importe) dans RAD et que vous voulez y rajouter l'authentification et un système de gestion de rôle. En effet, chaque utilisateur du système n'a pas forcément les mêmes droits. Par exemple, un utilisateur lambda pourra par exemple que consulter les données alors que peut être l'administrateur pourra lui créer, supprimer ou modifier. On dit qu'on attribut des rôles aux utilisateurs. Un utilisateur peut avoir plusieurs rôles en même temps. Avec une gestion assez fine des rôles, on peut arriver à permettre ou interdire certaines fonctionnalités de l'application selon l'utilisateur.

Avant de commencer, il faut activer, si ce n'est pas déjà fait, la sécurité dans WebSphere :
  1. Ouvrir la console administrative de WebSphere
  2. Dans Sécurité/Administration, applications et infrastructure sécurisée, il faut que 'Activer la sécurité applicative' soit cochée. Si ce n'est pas le cas, éxecuter l'assistant de configuration des paramètres de sécurité.
  3. Suivre les indications de l'assistant. Notamment, on vous demandera un login et mot de passe pour se connecter à WebSphere (bien retenir ces informations car elles vous seront demandées à la prochaine connexion à la console administrative !)
  4. Sauvegarder vos modifications et redémarrer le serveur WebSphere
  5. RAD ne risque de plus fonctionner avec votre serveur. Double cliquer sur le serveur dans RAD et dans la partie sécurité : cocher "la sécurité est active sur ce serveur" puis renseigner le login et mot de passe saisis au point 3
La sécurité est désormais active sur le serveur ! Vous verrez que maintenant, les adresses sont en https et non plus en http

On va voir maintenant comment créer notre page de login. Elle va être simple : elle contient seulement un formulaire qui va envoyer les informations de connexion à Web Sphere.
Voici son code HTML :

<html>
<body>

<form action="j_security_check" method="post" />

Login : <input type="text" name="j_username" /><br>
Password : <input type="password" name="j_password" /><br>
<input type="submit" value="Connect" />
</form>

<body>
</html>


Lorsque l'utilisateur clique sur 'Connect', le login et mot de passe sont envoyées dans une servlet de WebSphere : j_security_check. Cette servlet vérifie que l'utilisateur existe bien et vérifie son mot de passe. Si l'utilisateur est connu, l'utilisateur sera authentifié sur toutes les pages de l'application Web.
Les utilisateurs sont définis directement dans WebSphere (dans la partie Sécurité ou Utilisateur et Groupe sous la console administrative). C'est assez bien fait, car on peut très bien coupler WebSphere et Active Directory de Windows, ainsi, tous les utilisateurs de Windows seront directement utilisables par notre application !!!

Maintenant il gérer la sécurité dans notre projet avec RAD :
  1. Ouvrir le projet Web dans RAD
  2. Ouvrir Web.xml (descripteur de déploiement)
  3. Aller dans l'onglet "Pages"
  4. Dans la partie "Connexion", mettre "FORM" dans la méthode d'authentification et /login.jsp dans la page de connexion. Cela indique qu'on utilise la page de login créée plus haut comme page de connexion à notre application
Il faut désormais définir les rôles de sécurité. Identifiez les et les créer :
  1. Dans Web.xml, aller dans l'onglet "Sécurité"
  2. Ajouter un roles (en haut de l'écran), par exemple le rôle Admin qui sera destiné aux administrateurs de l'application
  3. Procéder de même pour tous les roles
Une fois les rôles définis, on doit spécifier à quoi ont accès les rôles. ça peut être n'importe qu'elle ressource du site (jsp, image, feuille de style, action struts etc...) :
  1. Toujours dans l'onglet "Sécurité" de Web.xml, créer une contrainte sécurité. Une contrainte spécifie un groupe de ressource que l'on autorise pour des rôles
  2. La contrainte doit avoir au moins un pattern de ressource. Le pattern définit l'ensemble des ressources concernées : par exemple *.jsp pour toutes les jsp du site, *.action pour toutes les actions struts 2, admin*.jsp pour toutes les pages jsp commençant par admin etc...
  3. Il faut ensuite associer les roles à ces ressources. Seuls les utilisateurs ayant les rôles choisis auront accés aux ressources
Pour finir, il reste plus qu'a associer les rôles aux utilisateurs (un utilisateur peut avoir plusieurs roles). Il y a deux méthodes : à partir de la console administrative de WebSphere ou directement à partir de RAD :
  1. Dans RAD, ouvrir l'éditeur de sécurité du projet (dans l'arborescence du prjet)
  2. Les rôles créés dans Web.xml devraient apparaitre.
  3. On peut mapper des utilisateurs ou des groupes à chaque role.
  4. Créer éventuellement les utilisateurs dans WebSphere (à partir de la console administrative)
Pour tester votre application, ouvrez une page concernée par une contrainte de sécurité. Tout d'abord, l'application va vous demander un login/mdp. Choisir un utilisateur ayant le bon rôle. Vous devez avoir accés à la page. Recommencer avec un utilisateur n'ayant pas le role, l'accés à la page doit être refusé.

Note : vous devez proposer, à tout moment, à l'utilisateur de se déconnecter de l'application. Pour cela, rajouter un lien cliquable sur chacune de vos pages pointant vers l'URL : ibm_security_logout?logoutExitPage=##URL##
Remplacer ##URL## par l'adresse de la page vers laquelle aller àpres la déconnexion (par exemple la page d'acceuil de votre site)

Voili, c'est tout !