Réalisation : Encadrés par : BEN GHORBEL Mohamed Zied OUESLATI Cherif. Mr. ROMDHANI Mohamed

Transcription

1 Réalisation : BEN GHORBEL Mohamed Zied OUESLATI Cherif Encadrés par : Mr. ROMDHANI Mohamed

2 Plan Le projet JBoss JBoss : La Naissance JBoss : un serveur d application libre JBoss : Un serveur certifié J2EE Architecture JBoss Configuration JBoss Structure du répertoire JBoss Principaux fichiers de configuration Configuration du conteneur Configuration avancée du cache Packaging et Déploiement des Webapps Packaging de L EJB CMP Fichiers XML des JAR JCA : J2EE Connector Architecture Plan Sécurité sous JBoss Sécurité J2EE Les rôles J2EE Balises de sécurités appliquées au serveur JBoss Custum Security JBossSX Security Model JAAS Security Manager SSL au niveau de JBoss Sécurisation des ressources web, servler et jsp Clustering Conclusion

3 Le Projet JBoss Le Projet JBoss (1/7) Qu'est ce qu'un serveur d'application? Un serveur d'application est un serveur abritant tous les composants d une application qui vont réagir d une part aux demandes des clients et d autres part dans la recherche des données correspondantes à ces requêtes. Son rôle est de gérer l'ensemble des tâches d'interconnexions du client : L'authentification applicative (LDAP, base de données, etc.) Le chiffrement des communications Le tracking de session d'un utilisateur connecté Les fonctions de répartition de charge applicative entre plusieurs serveurs La gestion des connexions aux bases de données.

4 Le Projet JBoss (2/7) Les technologies les plus souvent utilisées par les serveurs d'application s'appuient sur les Enterprise JavaBeans (EJB). La grande force des serveurs d'application est de proposer un environnement de développement afin d'automatiser et de générer des squelettes de code permettant d'implémenter des objets prédéfinis. Le Projet JBoss (3/7) JBoss : La Naissance JBoss est né d'une initiative collective de développeurs, dont Gavin King le fondateur du projet Hibernate, fédérée par le très médiatique président Marc Fleury, ancien ingénieur français de chez SUN, mentor charismatique et fondateur du projet et de la société JBoss Group. Sorti en Mars 1999, JBoss est devenu l'un des serveurs J2EE les plus populaires du marché imposant le modèle Open Source au sein de références commerciales telles que WebSphere d'ibm ou WebLogic de BEA

5 Le Projet JBoss (4/7) JBoss : un serveur d'application libre L'objet initial était de créer un serveur d'application Open Source sous licence LGPL (The GNU Lesser General Public Licence) fondé sur les spécifications de la plate-forme J2EE GPL Vs LGPL GPL oblige que toute l application soit libre LGPL permet la co-existence d un composant libre avec un composant propriétaire Il est maintenu par : Une communauté d'environ 500 développeurs dans le monde, dont un noyau dur de 50 personnes. Le JBoss Group : l'entité commerciale et de conseil créée en 2002 à partir du groupe de travail originel JBoss. Le Projet JBoss (5/7) Documentation gratuite?!! Pas du tout Les documentations de JBoss écrites par JBoss Group sont payantes, sauf le guide de démarrage (Quick Start), c'est en parti grâce à ces revenus que le produit peut rester gratuit. 99$ pour une personne ou 500$ pour un site.

6 Le Projet JBoss (6/7) JBoss : Un serveur de production implémentant l'ensemble des spécifications J2EE A partir de la version 3.0 JBoss devient un produit complètement exploitable par l'entreprise puisqu elle intègre désormais des fonctionnalités telles que la répartition de charge Les versions les plus stables sont celles à partir de JBoss possède une infrastructure JMX (Java Management extension) qui permet d implémenter les différents services du standard J2EE En juillet 2004, JBoss a conclu avec succès les tests nécessaires à l'obtention de la certification J2EE 1.4 pour son serveur d'applications et devint le premier serveur certifié J2EE 1.4 Le Projet JBoss (7/7) JBoss : Le palmarès JBoss a été élu meilleur serveur d'application 2002 par le magazine Java World spécialisé dans la programmation Java Une moyenne mensuelle de plus de téléchargements et plus de 4 millions de téléchargements depuis "SourceForge.net"

7 Architecture de JBoss Architecture de JBoss (1/32) Introduction JBoss est un serveur très léger implémentant l'ensemble des spécifications J2EE. Configuration matérielle minimale : JDK (1.4.2 recommandé) 512 MB RAM 100 MB espace en disque dur 400 MHz CPU JBoss a de nombreuses particularités dont l'architecture qui est très flexible (parfaitement plugable) et facile d'utilisation ce qui fait le bonheur des débutants en J2EE et des architectes expérimentés cherchant une plate forme middleware personnalisable.

8 Architecture de JBoss (2/32) C'est une architecture de type micro-kernel; tout est développé sous forme de modules JMX pouvant être remplacés ou enrichies par d'autres modules, au format JMX, d où la modularité. Architecture de JBoss (3/32) Architecture Technique de JBoss Les différents modules constituant l'architecture standard de JBoss sont : Le JTS/JTA La security = = JBossTX la gestion de la sécurité par JBossSX Le JMX Implementation EJB Container et Remote Management = composant JBossServer Le JMS Les Databases = stockage des = objects avec le composant JBossMQ JBossCMP Les Data sources = composant JBossCX réalisant la gestion des connecteurs Les Java Server Pages = serveurs Tomcat et Jetty

9 Architecture de JBoss (4/32) Le composant JBossServer Ce composant constitue le coeur du serveur d'application JBoss. Son rôle est de gérer le noyau grâce au JMX, mais également de fournir les conteneurs EJB. Contrairement à la plupart des serveurs d'applications J2EE, JBossServer permet de déployer et redéployer automatiquement les nouvelles applications sans avoir à stopper ou arrêter le serveur. Architecture Technique Architecture de JBoss (5/32) Le composant JBossMQ Ce composant est apparu en avril Il implémente l'api Java Messaging Service (JMS). Le JMS permet un échange entre des applications ou des composants via des brokers de messages ou MOM (Middleware Oriented Messages). Le module JBOssMQ supporte plusieurs sortes de message : RMI (Remote Méthode Invocation) OIL (Optimized Invocation Layer) UIL pour les applications clientes qui n'acceptent pas les connexions venant du serveur Architecture Technique

10 Architecture de JBoss (6/32) Le composant JBossTX Ce composant permet le support des moniteurs de transaction avec les API JTA/JTS. Les services offerts par JBossTX sont : Fournir aux applications la capacité de contrôler le périmètre et la durée d'une transaction Supporter les transactions synchronisées etc. Architecture Technique Architecture de JBoss (7/32) Le composant JBossCMP Ce module permet de gérer les connexions aux bases de données grâce au connecteur JDBC. La version actuelle de JBossCMP permet de se connecter à 17 bases de données dont Oracle, SQLServer, DB2, Sybase, PointBase, Cloupscape, HypersonicsSQL, PostgreSQL, mysql, etc. Particularité intéressante : le moteur CMP est bâti sur le populaire outil Hibernate qui a une très bonne réputation sur les persistances objets Architecture Technique

11 Architecture de JBoss (8/32) Le composant JBossSX JBossSX fournit une implémentation de la sécurité standard à J2EE. Ce composant a pour rôle de gérer la sécurité grâce à l'api JAAS ; il permet notamment l'authentification des utilisateurs grâce au module JAAS Login Architecture Technique Architecture de JBoss (9/32) Le composant JBossCX JBossCX permet de gérer les connecteurs aux systèmes d'informations de l'entreprise comme CICS, TUXEDO, SAP, Siebel, etc... Architecture Technique

12 Architecture de JBoss (10/32) Le composant Web Servers Le serveur web est géré à l'aide de deux produits existants Tomcat et Jetty. Architecture Technique Architecture de JBoss (11/32) Introduction à l AOP L'AOP (Aspect-Oriented Programming) ou en français POA (Programmation Orientée Aspects) est l'innovation qu'apporte JBoss à partir de la version 4.0 Depuis 1997, l'aop provoque l'engouement de la communauté scientifique s'intéressant au principe bien connu en génie logiciel: la séparation des préoccupations ou des différentes responsabilités d'un programme en le décomposant en éléments logiques En effet, il existe un certain nombre de fonctionnalités, transversales au logiciel développé, dont on retrouve le code au sein de l'ensemble des classes de l'application à l'exemple de la gestion des logs, de la sécurité, de la configuration, du cache, des transactions, de l'accès à distance...

13 Architecture de JBoss (12/32) Il est par exemple fort courant, dans un code Java, de trouver ce genre de lignes de codes : public void mamethode() { try { this.traitement(); logger.log("traitement accompli avec succès!"); } catch (ExceptionABC eabc){ // Cette exception survient dans les cas A, B et C logger.log(eabc); } catch (ExceptionD ed){ // Cette exceptionn survient dans le cas D } } Il est clair ici qu'il y a entrelacement de deux fonctionnalités distinctes: code métier et gestion de log. Introduction à l AOP Architecture de JBoss (13/32) L objectif de l'aop, est d'éviter ce type d'entrelacement de code, en séparant de manière claire le code métier et l'utilisation de fonctionnalités transversales. Ceci peut par exemple être obtenu par le biais de commentaires, de types Javadoc, précisant quels aspects vont être utilisés par ce code métier, et à quel endroit. Le fragment de code exposé ci-dessus pourrait ainsi devenir : /** required = "logging" insertionpoint="after" involvedcases="default,exceptionabc" */ public void mamethode() { this.traitement (); } Introduction à l AOP

14 Architecture de JBoss (14/32) L'AOP peut par ailleurs être utilisée directement en Java, pour peu que l'architecture du produit s'y prête. C'est ce qui est fait dans JBoss avec notamment les intercepteurs et dans Tomcat avec les valves. L'équipe de développement de JBoss a été très inspirée par l'aop pour implémenter de manière transparente les services offerts par J2EE; la sécurité est prise en charge par le SecurityInterceptor. Il en est de même pour d'autres facettes comme la Persistance, le Transactionnel et le Clustering. Lors d'un chargement d'un EJB, JBoss va instrumenter la classe en interceptant son bytecode et en modifiant le comportement de la classe selon les besoins définis par le développeur. Introduction à l AOP Architecture de JBoss (15/32) Quels sont les avantages de cette technique Gain de productivité Réutilisabilité des objets comme des aspects Qualité du code Evolutivité Simplicité des développements Introduction à l AOP

15 Architecture de JBoss (16/32) L'AOP "is good" mais qui en a recourt au juste? Les développeurs d'applications pour tester leurs codes: Par injection d'erreurs ou des routines validation. Les développeurs de Middleware: Création transparente des services. Les intégrateurs de systèmes / utilisateurs finaux: Personnalisation du software à son environnement: largement plus maniable que les fichiers de configuration. Introduction à l AOP Architecture de JBoss (17/32) Les intercepteurs Dans JBoss, un EJB est appelé généralement à distance depuis une interface externe: Lorsqu'un client souhaite appeler la méthode traitement de l'objet serveur, il dispose généralement d'un proxy sur cet objet, qui lui permet à distance de manipuler l'interface de l'objet serveur. Ce proxy transfère tous les appels Appel d'un EJB dans un serveur J2EE de méthodes, via le réseau, à un ServerObject qui fournit une encapsulation complète de l'objet serveur en tant qu'ejb.

16 Architecture de JBoss (18/32) Dans le cas de JBoss, l'objet ServerObject dispose d'une liste d'intercepteurs à travers lesquels va passer l'appel de méthode avant qu'il n'atteigne l'objet serveur. Comme il est indiqué dans la figure ci-dessous, l'appel de la méthode va être traité d'abord par chaque intercepteur avant que l'ejb ne le reçoive, et, de la même manière, la valeur de retour de cet EJB sera traitée par chaque intercepteur avant que le client ne la reçoive. Les Intercepteurs Architecture de JBoss (19/32) Mais les intercepteurs: c'est quoi au juste? Ces intercepteurs sont en fait une mise en oeuvre directe de la programmation orientée aspect (AOP) au sein d'un programme Java ; se sont en fait des classes java implémentant l'interface Interceptor. Ils se placent en effet entre le serveur d'application et l'objet censé être appelé pour fournir des fonctionnalités supplémentaires. Ceci prend tout son sens lorsqu'on sait que ces intercepteurs peuvent traiter de: La sécurité de l'appel de méthode La mise en place de logs de bas niveau La persistance Les Intercepteurs

17 Architecture de JBoss (20/32) En effet, lorsqu'un EJB persistant est chargé l'intercepteurs org.jboss.mx.interceptor.persistenceinterceptor, qui lui est associé, permet de le persister en base. Celui-ci, à chaque retour de méthode, va vérifier que l'ejb est «clean» ou «dirty», et s'il est «dirty», il va le persister grâce à la gestion de la persistance de JBoss. Par ailleurs, il faut savoir que ces intercepteurs sont traités comme des objets sans état, et sont donc assignés sous forme d'un pool de traitement. L'ensemble des informations relatives à ces intercepteurs est stocké dans un objet de contexte qui, lui, est particulier à l'ejb. Ceci permet donc de marier de très bonnes performances, puisque les données sont stockées à l'endroit le plus utile, avec un très bon design, gage de réutilisabilité et de clarté du code. Les Intercepteurs Architecture de JBoss (21/32) Enfin, l'utilisation de ces intercepteurs est totalement transparente pour l'utilisateur. Par exemple, la gestion de la sécurité des accès dans JBoss se fait par la modification du fichier ejb-jar.xml d'une webapplication. On bénéficie donc ici d'un mécanisme modulaire de gestion des aspects transversaux de l'application : Transparent pour l'utilisateur Très modulaire (puisque les intercepteurs sont définis dans les fichiers de configuration) Facilement modifiable (puisqu'il n'y a qu'à implémenter un intercepteur spécifique pour modifier l'une de ces fonctionnalités, comme par exemple la sécurité). Les Intercepteurs

18 Architecture de JBoss (22/32) JBoss et JMX Qu est ce que le JMX? JMX (Java Management Extensions) est une spécification de Sun fournie à travers le JCP (Java Community Process) qui permet d'administrer à distance des applications Java, mais également des équipements d'administration de réseau (firewall,routeur,...). Cette spécification se décompose en trois niveaux : Le niveau instrumentation : les MBeans. Le niveau d agent : le MBeanServer. Le niveau des services distribués. Architecture de JBoss (23/32) Le niveau instrumentation : les MBeans Les Mbeans (Managed Beans) représentent la brique de base au sein de cette architecture. Les MBeans constituent des interfaces de communication avec les éléments physiques (qu ils soient locaux ou distants) ou les programmes gérés à travers JMX. Les MBeans sont des classes Java correspondant à la définition des JavaBeans. Il existe 3 types de MBean: Le MBean standard : fournit un jeu de propriétés constant durant l'exécution de l'application. Le MBean dynamique : voit ses propriétés évoluer au cours du temps, non seulement en valeur, mais également par leur définition. Le MBeanModel : fournit une implémentation standard pour le MBean dynamique. JBoss et JMX

19 Architecture de JBoss (24/32) Le niveau agent : les MBeanServer La couche agent de la spécification permet de gérer des MBeans, mais également de fournir des adaptateurs de protocoles permettant d'accéder à cette couche depuis des clients, comme par exemple depuis un client HTML. Au sein de cette couche, un composant, standardisé par JMX, a un rôle essentiel. Il s'agit du MBeanServer. Ce serveur permet d'enregistrer des MBeans, de les explorer, et de les exploiter de manière locale ou à distance. Au sein d'un MBeanServer, chaque MBean est connu sous un nom unique : Ce MBeanServer permet donc d'agréger les informations fournies par les différents MBeans. Les informations sont exploitées, soit par la logique spécifique de l'agent, soit par les différents connecteurs et services associés JBoss et JMX Architecture de JBoss (25/32) La couche agent fournit par spécification un certain nombre de services, qui peuvent être implémentés sous forme de MBeans : Le service m-let ou service de gestion des applets. Le service de monitoring permet, dans le cadre d'une gestion réseau, de surveiller des variables déportées. Le service de compteur envoie un événement lorsqu'un délai est écoulé. Le service de gestion relationnelle permet de définir des relations entre MBeans et de s'assurer de la validité de ces relations. JBoss et JMX

20 Architecture de JBoss (26/32) Le niveau de connectivité ou de services distribués : Ce niveau joue le rôle d'une interface pour les applications de management distantes (Remote Manager). Les gestionnaires distants peuvent accéder aux informations de gestion et de contrôle exposées par les objets MBeans pour chaque application en ayant recourt à des connecteurs de protocoles issus de l'architecture des connecteurs J2EE En utilisant un connecteur, un agent JMX peut ainsi obtenir des capacités de communication CORBA, SNMP, HTTP,... Plusieurs systèmes de gestion utilisant différents protocoles peuvent ainsi cohabiter et supporter simultanément les fonctionnalités de gestion applicative par le billet d'une console d'administration tel que Trivoli d'ibm JBoss et JMX Architecture de JBoss (27/32) Par défaut, un adaptateur est fourni pour le HTML, qui permet de disposer, pour n'importe quel agent JMX, d'une console d'administration accessible depuis un navigateur internet. C est sur ce principe que fonctionne la console JMX fournit en standard avec JBoss. JBoss et JMX

21 Architecture de JBoss (28/32) JMX en tant que bus interne de JBoss et les composants standards. Au démarrage de JBoss, le seul composant qui soit directement lancé contient le MBeanServer de l'architecture JMX de JBoss, et permet ainsi de voir n'importe quelle instance de JBoss comme un agent JMX, disposant de la console d'administration HTML de manière standard JBoss et JMX Architecture de JBoss (29/32) Cet agent JMX contient également une classe qui va lancer l'ensemble des services déclarés dans le fichier de configuration jboss-service.xml. On récupère alors la console JMX de JBoss (vu des MBeans déployés) Les différents services de JBoss sont effectivement des MBeans (persistance, transaction, sécurité) Ce qui mène aux avantages suivants : Grande flexibilité Grande adaptabilité pour la plateforme JBoss. JBoss et JMX

22 Architecture de JBoss (30/32) Possibilité, en cours d exécution de JBoss, de modifier par le biais de la console d'administration JMX, les paramètres de fonctionnement d'un service. Mais il est également possible d'arrêter ou de redémarrer un service, même critique, sans pour autant arrêter le serveur. Fournir les services de JBoss sous forme de MBeans est donc la garantie d'une grande facilité d'utilisation, mais aussi d'une grande facilité de mise à jour, la seule partie réellement fondamentale étant le code de l'agent. La meilleure façon d ajouter des services au serveur JBoss est donc d écrire vos propres MBeans JMX. JBoss et JMX Architecture de JBoss (31/32) Hot Deployment: Une modification de la configuration existante est ignorée par le système jusqu'à ce qu'il redémarre. Au niveau du hardware, ceci pourrait se passer lors de l'ajout d'une mémoire ou des disques durs. Au niveau du software, ceci se passe si les fichiers de configuration sont modifiés. Le Hot Deployment consiste au fait que le serveur vérifie périodiquement si sa configuration a été changée. Si c est le cas, alors il examine toutes les opérations qui dépendent de ce changement pour calculer le moment optimum pour changer le paramètre modifié. A partir de JBoss 3.x, tout est hot-deployable : Pas besoin de redémarrer le serveur à chaque fois que vous déployez ou undéployez un composant ou une application, ajouter ou retirer un MBean. Ceci grâce à la nouvelle architecture de déploiement et de chargement de classes (ClassLoading) et plus exactement par le biais du service du MBean URLDeploymentScanner. JBoss et JMX

23 Architecture de JBoss (32/32) Ce service surveille un ou plusieurs URLs susceptibles de contenir des archives à déployer et déploie par la suite ces archives par ordre d apparition ou de changement. Il permet aussi de undéployer les applications précédemment déployés si l archive à partir de laquelle l application a été déployée est retirée. Parmi les attributs de configuration de ce service on trouve: URLs : une liste d URLs des emplacements qui devront être scanner threads. Exemple : «deploy/»,«jboss.server.home.dir}/deploy» ScanPeriod: temps en millisecondes entre les exécutions des scanners threads. RecursiveSearch : indique si les sous répertoires peuvent être vu comme contenant des éléments à déployer ou non. JBoss et JMX Configuration de JBoss

24 Configuration de JBoss(1/13) Structure du répertoire JBoss Arborescence générale Structure du répertoire server Les configurations standard disponibles Principaux fichiers de configuration Configuration du conteneur Configuration avancée du cache Le Conteneur Web Tomcat Configuration de JBoss(2/13) Structure du répertoire JBoss 1. Arborescence générale :

25 Configuration de JBoss(3/13) bin : Tous les scripts de démarrage et d'arrêt de JBoss (run.bat, shutdown.bat et twiddle.bat ) lib : Contient les fichiers JAR nécessaires au fonctionnement du noyau JBoss (le "Microkernel"). Chargés au lancement du serveur, ils sont partagés par les différentes configurations JBoss. docs : Contient des fichiers de configuration exemples (configuration de bases de données ) ainsi que les fichiers DTD des XML nécessaires au bon fonctionnement de JBoss. client : Stocke la configuration et les fichiers jar qui pourraient être utilisées par une application java cliente ou bien par un conteneur web externe. Configuration de JBoss(4/13) server : Il comprend trois configurations types : minimal : Pour un serveur JBoss autonome (pas dans un cluster) et ne permet de lancer que des services de base relatifs au déploiement des EJB. default : Pour un serveur JBoss autonome lançant un Servlet engine embarqué (Jetty ou Tomcat suivant la version) all : Configuration complète pour un support des clusters et le lancement du moteur Http/JSP en mode embarqué. Configuration Personnalisée : Il est recommandé de créer une configuration de lancement personnalisée en créant un répertoire de configuration spécifique à l'exemple des répertores "all", "minimal" et "default".

26 Configuration de JBoss(5/13) Structure du répertoire server : Chacun des sous - répertoires se trouvant ici se rapporte à une configuration de serveur différente. Nous allons décrire dans la suite celle de "default": data : contient d autres répertoires avec des fichiers en relation avec d autres bases de donné es telles que Hypersonic ou MySql. Il est aussi utilisé par JBossMQ (l implémentation JBoss de JMS) afin de stocker des messages dans le disque. deploy : Répertoire de déploiement des fichiers Jar, Ear et War de l application. Il est aussi utilisé par les services déployables à chaud. Ce répertoire est scanné constamment à la recherche de mises à jour ou autres composants modifiés. Configuration de JBoss(6/13) lib : Les fichiers JAR dont doit se prémunir la configuration de serveur actuelle. log: Fichiers de logging, il est par défaut "ON". JBoss utilise le package de Jakarta "log4j". tmp: Répertoire de travail utilisé par Autodeployer pour stocker les fichiers temporaires. work: Utilisé par Tomcat pour la compilation des JSP. conf : C'est le répertoire des configurations de JBoss. Il contient entre autres le fichier jboss-service.xml qui spécifie les services du noyau.

27 Configuration de JBoss(7/13) Divers fichiers de configuration : jboss-service.xml : contient les services MBeans nécessaires au démarrage de JBoss. Tout Jmx Mbean standard peut être placé dans le fichier jboss-service.xml tant qu il ne dépend pas d un service JBoss des Mbeans (ex : nommage). Sinon il devra être configuré dans jboss.xml. Contrairement à la syntaxe MLet, ce fichier contient du XML bien formé. mail-service.xml : En suivant la spécification EJB, JBoss alloue un accès au mail via les API JavaMail standard. Ce fichier spécifie les propriétés du mail provider (où se trouvent les serveurs POP, SMTP ). jnp.properties & jndi.properties : Le premier spécifie les propriétés de JNP qui est l implémentation du JNDI provider sous JBoss. Le deuxième montre les propriétés spécifiques aux clients JNDI. Configuration de JBoss(8/13) standardjaws.xml : Représente le fichier de configuration par défaut du moteur CMP de JBoss. Il inclut le nom JNDI de la source de données par défaut, les réglages (par défaut aussi) des beans CMP etc auth.conf : Fichier de configuration du module JAAS Login. server.policy : Représente la politique Java2 de sécurité par défaut pour le serveur JBoss. Ce fichier n est pas utilisé car JBoss ne tourne pas avec un SecurityManager par défaut. standardjboss.standardjboss.xml : Avance la configuration du conteneur par défaut. Mais qu est ce qu on entend par configuration du conteneur?!!

28 Configuration de JBoss(9/13) Configuration du conteneur : En fait, lors du déploiement, JBoss crée un conteneur particulier pour chaque Bean configuré selon le type de ce dernier. Les différentes configurations standard (au nombre de 9) sont stockées dans standardjboss.xml. Si l on souhaite en ajouter une autre qui soit personnalisée, ceci devrait être fait dans "jboss.xml". Configuration de JBoss(10/13) Importantes optionalités offertes pour la configuration du conteneur : <instance-pool> : Groupement d instances de Beans libres. <instance-cache> : Le cache contient les instances de Beans actuellement associés à un contexte. S il augmente beaucoup en volume, il va rendre certaines instances passives. <persistence-manager> : Se charge du stockage d informations permanentes dans l instance d un Bean. <Container-invoker-conf> : Contient beaucoup d éléments liés à la configuration. <Commit-Option> : Quatre Options qui définissent chacune un mode de sauvegarde dans le cache ainsi que des délais de rafraîchissement et de synchronisation,l essentiel étant que le conteneur arrive à assurer un état intégral des transactions constamment persistant.

29 Configuration de JBoss(11/13) Descripteurs de déploiement spécifiques au conteneur : Les informations spécifiques au conteneur se trouvent généralement dans d extra descripteurs XML qui font le mapping entre les informations logiques utilisées dans l application(tels que les noms JNDI) et les valeurs qui sont utilisées par le serveur. JBoss utilise des fichiers différents pour les EJB et les modules Web d une application : ce sont les fichiers "jboss.xml" et "jbossweb.xml". Notons qu en plus d être utilisé pour les EJB entity, le Container Managed Persistence (CMP) sert aussi à la configuration du moteur de persistance de JBoss via le fichier «jbosscmp-jdbc.xml». Configuration de JBoss(12/13) Configuration avancée du Cache JBoss nous octroie la possibilité de choisir une configuration de cache pour chaque configuration de conteneur. Si l on veut en définir une bien propre à nous c est possible en la spécifiant sous les balises et sous-balises de <instance-cache> de jboss.xml. Nous avons le choix entre deux algorithmes qui sont : Algorithme de non passivation du cache LRU D autres balises sont aussi disponibles : <max-capacity> <overager-period> <max-bean-age>

30 Configuration de JBoss(13/13) Le Conteneur Web Tomcat JBoss est maintenant fourni avec «Tomcat 5.0.x» comme le conteneur web par défaut. Le service embarqué Tomcat est le SAR extensible «jbossweb-tomcat50.sar»dans le répertoire de déploiement. Tous les fichiers Jar requis par Tomcat peuvent être trouvés là bas, ainsi que le fichier web.xml qui procure un ensemble de configurations par défaut pour les applications Web. NB : le fichier META-INF/jboss-service.xml contient dans la partie déclaration des Mbeans pour le service Tomcat l élément <attribute..> qui contient les informations sur la configuration standard de Tomcat. Packaging et Déploiement des WebApps

31 Packaging et Déploiement des WebApps(1/16) Packaging de l EJB CMP dans JBoss : EJB CMP.jar EJB CMP.jar ejb interfaces META-INF *.class home remote jaws.xml ejb-jar.xml jboss.xml jbosscmp-jdbc.xml Packaging et Déploiement des WebApps(2/16) Packaging de l EJB CMP dans JBoss : EJB CMP.war EJB CMP.war web WEB-INF HTML+JSP lib web.xml Jbossweb.xml EJB CMP-Client.jar

32 Packaging et Déploiement des WebApps(3/16) Packaging du EJB CMP dans JBoss : EJB CMP.ear EJB CMP.ear EJB CMP.jar EJB CMP.war META-INF Application.xml Packaging et Déploiement des WebApps(4/16) Fichiers xml des JAR Jaws.xml Jboss.xml Jbosscmp-jdbc.xml

33 Packaging et Déploiement des WebApps(5/16) jaws.xml Sert pour le mapping O/R dans le contexte d un EJB CMP. Spécifie comment les tables de la BD devront être construites/utilisées. Définit des «Finders» pour accéder aux beans entity En cas d absence, Jboss charge la configuration de standardjaws.xml Packaging et Déploiement des WebApps(6/16) Quelques options de jaws.xml <create-table>: indique si la table doit être créée au moment du déploiement (true/false). <remove-table>: indique si la table doit être supprimée au moment de l undéploiement. <tuned-updates>: si cette option est vraie seulement l opération de modification est valide. <read-only>: si cette option est activée l insertion est la modification seront désactivées. <time-out>: La période de rafréchissement du Bean en millisecondes. <select-for-update>: si cette option est vraie une requête "SELECT... FOR UPDATE" va être exécutée. <debug>: cette option va générer en cas d activation- un rapport log.

34 Packaging et Déploiement des WebApps(7/16) Exemple Jaws.xml CREATE TABLE CLASS (ID INTEGER, TEACHER VARCHAR(100), STUDENTNBR INTEGER); <jaws> <enterprise-beans> <entity> <ejb-name>classbean</ejb-name> <table-name>class</table-name> <create-table>false</create-table> <cmp-field> <field-name>classid</field-name> <column-name>id</column-name> </cmp-field> <cmp-field> <field-name>teachername</field-name> <column-name>teacher</column-name> </cmp-field> <cmp-field> <field-name>studentcount</field-name> <column-name>studentnbr</column-name> </cmp-field> </entity> </enterprise-beans> </jaws> Packaging et Déploiement des WebApps(8/16) jboss.xml (1) Complément de ejb-jar.xml. Peut réaliser le mapping O/R. En cas d absence de ce fichier JBoss se prémunit d un comportement standard.

35 Packaging et Déploiement des WebApps(9/16) jboss.xml (2) <jboss> <enterprise-beans> <entity> <ejb-name>client</ejb-name> <jndi-name>ejb/cmp/client</jndi-name> <resource-ref> <res-ref-name>jdbc/clientdb</res-ref-name> <jndi-name>java:/defaultds</jndi-name> </resource-ref> </entity> </enterprise-beans> </jboss> Packaging et Déploiement des WebApps(10/16) jbosscmp-jdbc.xml Sert à mapper une DataSource avec une base de données. Peut faire le mapping O/R. En cas d absence de jbosscmp-jdbc.xml JBoss lit les données à partir de conf/standardjbosscmp-jdbc.xml. Il peut aussi réaliser quelques tâches de jaws.xml.

36 Packaging et Déploiement des WebApps(11/16) Problème: jaws.xml et jbosscmp-jdbc.xml ont certaines balises communes. Que se passe-t-il si certaines de ces balises ont des configurations différentes? Packaging et Déploiement des WebApps(12/16) Solution: Au moment du déploiement de l EJB, JBoss charge la configuration de standardjaws.xml puis il l écrase avec celle de jaws.xml s il existe, ensuite il remplace les balises communes par celles de jbosscmpjdbc.xml.

37 Packaging et Déploiement des WebApps(13/16) <createtable>true</createtable> <createtable>false</createtable> <createtable>true</createtable> Packaging et Déploiement des WebApps(14/16) JCA (J2EE Connector Architecture) Architecture J2EE de connecteurs spécifique à une ressource transactionnelle et sécurisée. Utilisée au niveau des DataSources dans JBoss. Exemple de configurations de DataSources sont fournies sous JBOSS_DIR/docs/examples/jca.

38 Packaging et Déploiement des WebApps(15/16) Schéma simplifié d une DataSource dans JBoss <mbean>: tout élément du mbean doit être spécifié afin de définir les services du mbean qui devront être inclus dans le descripteur de déploiement jbossservice.xml. <no-tx-datasource>: spécifie la configuration du service de connexion «org.jboss.ressource.connectionmanager.notxconnectionmanager» et supprime les transactions. <local-tx-datasource>: Permet de s assurer que toutes les transactions locales liées à la connexion fonctionnent parfaitement. <xa-datasource>: cet élément est pareil au précédent sauf que le Connection Manager n est plus le même: LocalTxConnectionManager pour local-tx-datasource XATxConnectionManager pour xa-datasource Packaging et Déploiement des WebApps(16/16) Exemple de fichier DataSource mysql

39 Sécurité en JBoss Sécurité en JBoss (1/25 ) La Sécurité J2EE La spécification J2EE inclut une infrastructure de sécurité déclarative des composants applicatifs déployés sur le conteneur du serveur d application. Le concept de sécurité déclarative fait appel à un environnement de sécurité applicative à base de rôle, contrôles d accès et éléments d authentification sous la forme d un fichier descripteur. les infrastructures de sécurité sont introduites par le module jbosssx (Jboss security extension) qui utilise l API JAAS (Java Authentication and Authorization Service).

40 Sécurité en JBoss (2/25 ) Les rôles J2EE L architecture de sécurité J2EE fournit un mécanisme pour mapper automatiquement les rôles ou fonctions d un utilisateur du système. Ex : Contable Rapports financiers. Sécurité en JBoss (3/25 ) Les spécification EJB 2.x et Servlet 2.2 supportent ce modèle déclaratif qui délègue au serveur d application la responsabilité d appliquer les contrôles nécessaires. L architecture EJB encourage le Bean Provider à implémenter les beans métier sans intégrer les codes de sécurité et leurs mécanismes dans les méthodes métier et ceci facilitera aux développeurs la tâche de configurer la sécurité d une façon très appropriée à l environnement opérationnel de l entreprise.

41 Sécurité en JBoss (4/25 ) Quels rôles appellent quelles méthodes? ejb-jar.xml et web.xml. Sécurité en JBoss (5/25 ) ejb-jar.xml

42 Sécurité en JBoss (6/25 ) web.xml Sécurité en JBoss (7/25 ) Balises de sécurité appliquées au serveur JBoss <security-role-ref>: Cette balise indique qu un composant utilise la valeur role-name comme argument de la méthode iscallerinrole(string) <security-indentity>:cette balise établit l identité que prendra le Bean d entreprise lorsqu il effectuera des appels aux autre Beans d entreprise. Sa valeur est soit dans la balise <use-caller-indentity> ou <run-as>. <assembly-descriptor>:l assembleur d application (assemblydescriptor) définit les méthodes permises pour chaque rôle.

43 Sécurité en JBoss (8/25 ) <assembly-descriptor> <security-role>:est un groupement sémantique de methodpermission. Un utilisateur doit avoir au minimum un security-role. Sécurité en JBoss (9/25 ) <assembly-descriptor> <method-permission>: est une permission pour invoquer un groupe spécifique de méthodes d un EJB home ou remote. <method-name>:indique le nom d une méthode de BEAN dont un rôle à le droit d y accèder. <ejb-name>:le nom de l EJB qui contient la méthode. <method-intf>:pour distinguer les méthode dotées de la même signature à la fois dans l interface d accueil et dans l interface distant. <méthod-params> Pour distinguer une méthode parmi plusieurs avec un nom de méthode surchargé. <role-name>: Indique le nom du rôle de sécurité qui doit être octroyé pour appeler la méthode.

44 Sécurité en JBoss (10/25 ) Sécurité en JBoss (11/25 ) Custum Security EJB1.1 spec définit un mécanisme permettant d implémenter dans le bean un modèle de sécurité personnalisé (custom security). Ceci requiert l introduction de la logique de sécurité dans l implémentation des méthodes EJB. La mise en oeuvre de EJB1.1 Custom Security consiste essentiellement en deux méthodes de l interface javax.ejb.ejbcontext : java.security.principal getcallerprincipal () boolean iscallerinrole(java.lang.string rolename) Le problème de cette approche est qu elle exige une dépendance entre la logique métier et la logique de sécurité.

45 Sécurité en JBoss (12/25 ) getcallerprincipal () Sécurité en JBoss (13/25 ) JBossSX Security Model Le modèle de sécurité dans Jboss est basé sur Container architecture s pluggable method interceptor. JbossSX est intégré dans le serveur Jboss à travers la chaîne Server Container Interceptor. La sécurité du container est manipulée par la classe org.jboss.ejb.plugins.securityinterceptor. La classe SecurityInterceptor repose sur l implémentation de trois interfaces se sécurité.

46 Sécurité en JBoss (14/25 ) Interfaces de sécurité org.jboss.security.ejbsecuritymanage: Responsable de la validation des credentials associés aux principals Principals : sont des identités incluant des usernames, numéro employé, numéro sécurité sociale Credentials : éprouvent des identités incluant des passwords,session keys, digital signatures org.jboss.security.realmmapping Responsable du mapping entre le principal et ses rôles. org.jboss.security.securityproxy Décrit les exigences pour un SecurityInterceptorProxy Sécurité en JBoss (15/25 ) JaasSecurityManager La mise en oeuvre de la sécurité dans JBoss consiste en: Un JMX service MBean : org.jboss.security.plugins.jaassecuritymanagerservice L implémentation de EJBSecurityManager et ReamlMapping : org.jboss.security.plugins.jaassecuritymanager Le JMX service MBean manipule les aspects configurables du security manager et l intègre dans le JNDI namespace.

47 Sécurité en JBoss (16/25 ) JaasSecurityManagerService MBean (jbossservice.xml )(1) Sécurité en JBoss (17/25 ) Descripteur de déploiement jboss.xml(1) La stratégie de sécurité (indépendance entre la logique métier et la logique de sécurité) exige la déclaration de la couche de sécurité au moment du dépoilement, d où l inclusion du fichier jboss.xml.

48 Sécurité en JBoss (18/25 ) Descripteur de déploiement jboss.xml(2) security-domain : nom JNDI de l instance security manager implémentant les interfaces EJBSecurityMgr et RealmMapping pour toutes les composants J2EE d une archive ear ou d un ejb-jar. role.mapping.manager: nom JNDI de l interface RealmMapping utilisé par le container. authentication.module: nom JNDI de l interface EJBSecurityMgr utilisé par le container security.proxy : classe d implémentation de security proxyorg.jboss.security.subjectsecurityproxy. Sécurité en JBoss (19/25 ) Exemple d une configuration Container Security Chaque lookup sur java:/jaas/jmx-console retournera une instance d un security manager associé au domaine jmx-console. Cette instance implémentera EJBSecurityMgr et RealmMapping.

49 Sécurité en JBoss (20/25 ) SSL (Secure Socket Layer) SSL peut donc être considéré comme une couche fonctionnant entre TCP/IP et les protocoles de communication de plus haut niveau comme HTTP et IIOP, pour fournir une solution de communication sécurisée. SSL v3 est le standard de SSL le plus généralement utilisé. Le protocole TLS (Transport Layer Security) élaboré par l IETF (Internet Engineering Task Force) étend SSL v3 en améliorant lesaspects d authentification de l algorithme SSL. Sécurité en JBoss (21/25 ) JBOSS_HOME\server\default\deploy\jbossweb-tomcat55.sar\ server.xml

50 Sécurité en JBoss (22/25 ) keytool -genkey -alias tomcat -keyalg RSA Sécurité en JBoss (23/25 ) Sécurisation des ressources Web (Servlets et JSP) L une des fonctionnalités les plus intéressantes de la spécification de l API Servlet 2.2 est le support en matière de sécurité qu elle requiert de la part du conteneur à Servlet. Ce support consiste en une authentification utilisateur flexible, des contrôles d accès par rôles, la sécurité de transmission et la sécurité par programme.).

51 Sécurité en JBoss (24/25 ) La sécurité des servlets(1) Quatre types d authentification sont prévus dans la spécification de l API Servlet : Authentification de base HHTP : consiste en un nom d utilisateur et un mot de passe crypté en base64 (SSL recommandé). Authentification des digests HHTP : le mot de passe est haché par le navigateur avant d être envoyé au serveur. Authentification des clients HTTPS : utilise SSL, requiert un certificat compatible de la part de l utilisateur. Authentification par formulaires : utiliser des propres formulaires de connexion personnalisés à l utilisateur. Sécurité en JBoss (25/25 ) Le concepteur d application Web sélectionne une méthode d authentification à l aide de l élément loginconf du fichier web.xml. Les contrôles d accès par rôles : Il s agit de choisir les ressources que l utilisateur peut avoir via l élément security-role du fichier web.xml. Les rôles sont mappés à des ressources d application via l élément web-ressource-collection et en des éléments authconstraint. Lorsqu un utilisateur demande l URL d une servlet, l invité de connexion lui est présenté :