Architectures Applicatives

publicité
2016
Architectures
Applicatives
SERVEUR D’APPLICATIONS TOMCAT
OLIVIER D.
Table des matières
1
Etat des lieux .......................................................................................................................................... 4
2
Le serveur d’application Tomcat - Introduction ................................................................................... 9
3
Du programme à la configuration du serveur ....................................................................................10
4
L’élément <valve> (logs, restrictions, …) ............................................................................................14
5
Les ressources mises à disposition pour les applications Java ........................................................16
6
La sécurité du serveur et des applications ........................................................................................18
7
Les fichiers journaux – Analyse et supervision ..................................................................................23
Olivier DEHECQ – http://aide.informatique1.fr
Page 2
Signalétique
Nota, astuce :
Contient une partie serveur web qui traite les réponses statiques.
Important, à retenir :
Ceci est une chose importante
Commande MS-DOS
C:\> c:\tomcat5.5\bin\startup.bat
Commande UNIX
# /tomcat5.5/bin/startup.sh
Chemin de fichier, dossier, emplacement sur le disque
Fichier web.xml
Exemple de contenu de document
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" />
Contenu du fichier web.xml
<welcome-file>index.html</welcome-file>
Contenu du fichier server.xml
port
"8080"
port d’écoute du connecteur
Autre contenu de fichier :
<role rolename="RUserHelloWorld"/>
Spécifique aux documents xml :
Balise
Nom de propriété
Valeur
Commentaire
Olivier DEHECQ – http://aide.informatique1.fr
Page 3
1
Etat des lieux
Notion de couches



Si une machine fait le tout :
Si 2 machines font le tout :
Si 3 machines font le tout :
1.1
Les types d’architectures
1.1.1
Architecture 1 tiers
1.1.2
Architecture 1 tiers déployée
architecture 1 tiers
architecture 2 tiers
architecture 3 tiers
Olivier DEHECQ – http://aide.informatique1.fr
Page 4
1.1.3
Architecture 2 tiers : client / serveur
Gestion distante des données :
Présentation distante :
La base du dialogue :
Le middleware prend en charge le protocole de communication client / serveur



(1) Service à l’écoute des demandes extérieures
(2) Détient les informations sur le serveur à contacter
(3) Le driver est formaté pour s’adapter au middleware correspondant (SQL Server, Oracle, …)
Une API définit les méthodes de communications avec le serveur selon le langage (Java, .Net,
etc.). Si on veut changer de SGBD (ex. : SQL server à la place de Oracle), on change juste le
driver propre au middleware.
Une API est un dictionnaire présent physiquement dans l’application (en fait partie).
1.1.4
Architecture 3 tiers
On s’appuie sur les technologies de la norme W3C car la plupart des postes disposent de navigateurs
web prenant en compte HTML, XHTML, CSS et JavaScript.
Pas d’installation pour les pc : ce sont donc des clients légers.
Olivier DEHECQ – http://aide.informatique1.fr
Page 5
La partie développement est déportée sur le serveur d’application (plus facile).
1.1.5
Architecture n tiers
Fonctionnement des architecture N-Tiers
1.2
Les rôles
Serveur web :
Machine qui reçoit les requêtes HTTP. Peut faire serveur de fichiers pour les pages statiques.
Serveur d’application :
Prend en charge les traitements (construction d’une réponse dynamique). Contient un
composant prenant en charge l’exécution du traitement.
Contient une partie serveur web qui traite les réponses statiques.
Serveur d’objets :
Traitements métiers (exemple application orientée objets) / services web (exemple Google
Maps®) mis à disposition du serveur d’application pour simplifier la tâche.
Exemple de serveurs d’objets : serveur EJB, Microsoft DCOM, CORBA …
1.2.1
Cas de Google Search
C’est le développeur du service publié qui crée le fichier WSDL.
Le site http://webserviceX.net référence les services publiés.
Olivier DEHECQ – http://aide.informatique1.fr
Page 6
1.3
Le protocole HTTP
A chaque connexion, une nouvelle requête est créée : pas de stockage de résultat (ajouter un serveur
BD).
URI (Uniform Request Identifier) : http://host:port/path?query#fragment
1.3.1
Types de requêtes http


1.3.2
GET : les paramètres sont dans l’entête de requête
POST : les paramètres sont dans le corps de la requête.
Utilisation des requêtes
Avec un proxy :
Lorsqu’il y a un proxy, le proxy renvoie un message 407 (proxy authentication) au client pour lui
demander de s’authentifier.
Le client répond par un proxy autorization (les identifiants sont transportés dans le corps de la
requête : cas d’un POST ; ou dans l’entête de la requête en crypté : cas d’un GET).
Le client peut ensuite envoyer les requêtes au serveur web.
Autres cas :
L’entête des requêtes donne des infos sur le client (langue, navigateur, etc.) et le serveur envoie aussi
des informations dans ses entêtes de réponses (durée de cache, durée de session, etc.)
Olivier DEHECQ – http://aide.informatique1.fr
Page 7
1.3.3
La communication
HTTP 1.0 :


1 site par adresse IP
Etablissement TCP à chaque requête (350ko) puis libération TCP
HTTP 1.1 :


X sites par adresse IP :
o notion de répertoire virtuel
Etablissement TCP à la première demande, libération TCP lorsqu’on quitte le site :
o notion de session (espace réservé sur le serveur d’application pour un client donné).
Le sessionID :

Avec les cookies
(1) Le SessionID est généré par le serveur et est unique pour le serveur.
Le navigateur doit accepter les cookies

Sans les cookies
Il est possible de rajouter un champ caché sur la page ou bien de faire de la réécriture d’URL (changer
les href), mais la sécurité est moindre car les paramètres sont passés sans l’entête de requête.
Olivier DEHECQ – http://aide.informatique1.fr
Page 8
2
Le serveur d’application Tomcat - Introduction
Utilise la norme J2EE ; langage Java
Adresses utiles :


Tomcat : http://tomcap.apache.org
JRE : http://java.sun.com/j2se
2.1
Installation du serveur d’application Tomcat
2.1.1
Installer JRE et JDK
Installer la VM java - le JDK : contient le JRE (java runtime environment)
Définir la position de la VM Java :
PATH = … ; c:\Program Files\Java\jdk1.6.0_04\bin
Définir la position du JDK :
JAVA_HOME = C:\Program Files\Java\jdk1.6.0_04
Tester :
C:\> java -version
Doit renvoyer la version de la VM Java
2.1.2
Installer le serveur Tomcat (à partir du fichier .zip)
C:\> netstat -an
Pour voir les ports utilisés (8080 doit être disponible notamment, sinon résoudre le problème.
Ne pas mettre de caractères spéciaux dans le chemin d’accès à Tomcat
CATALINA_HOME = C:\Tomcat5.5
chemin d’installation de Tomcat
Il faut fermer et rouvrir l’invite de commande pour que les variables soient prises en compte.
C:\> c:\tomcat5.5\bin\startup.bat
Démarrage du serveur Tomcat
Tester:
Ouvrir le navigateur web, URL : http://localhost:8080. Doit afficher la page d’accueil Tomcat.
Créer un service windows pour Tomcat :
C:\> c:\tomcat5.5\bin\service.bat install
Configurer ensuite le démarrage automatique du service.
Olivier DEHECQ – http://aide.informatique1.fr
Page 9
3
Du programme à la configuration du serveur
3.1
Contenu d’une application web respectant la norme JEE
Méthode de fonctionnement des pages dynamiques
Méthode de traitement des données
3.2
Structure d’une application Java
Répertoire racine (contexte) :



WEB-INF
Classes
Lib
racine de la partie privée du site (seulement accessible par Tomcat)
servlet - caché par défaut (.class)
Références aux composants supplémentaires (.jar)
Le reste est dans la partie publique (accessible aussi par le client) :



pages .html
pages .jsp
images, sons, vidéos
Olivier DEHECQ – http://aide.informatique1.fr
Page 10
Il y a aussi un fichier web.xml  descripteur de déploiement : description des traitements
Utilisé par le serveur Tomcat pour savoir où se trouvent ses composants
3.2.1
Le fichier web.xml (structure globale)
<!--Nom de l’application : -->
<display-name>TDCoursDeploiement</display-name>
<!--Balises de définition des pages d’accueil du site (dans l’ordre) - Obligatoire : -->
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
<!--Définition des servlets – nom des pages, définissent les actions du programme à mener : -->
<servlet>
<description/>
<display-name>FormulaireServlet</display-name>
<servlet-name>FormulaireServlet</servlet-name>
<servlet-class>actions.FormulaireServlet</servlet-class>
</servlet>
<!--Paramètre d’initialisation des servlets – appellent les pages : -->
<servlet-mapping>
<servlet-name>FormulaireServlet</servlet-name>
<url-pattern>/FormulaireServlet</url-pattern>
</servlet-mapping>
3.2.2
Le développeur fournit
Soit l’arborescence complète : partie publique + partie privée (WEB-INF) dans un seul répertoire, soit
un fichier .war (archive compressée de l’arborescence).
Olivier DEHECQ – http://aide.informatique1.fr
Page 11
3.3
Déploiement sur un serveur J2E
Le fichier server.xml est structuré selon l’organisation présentée dans le schéma :
_ Server (1 seul)
|_ Service (de 1 à n services)
|_ Connecter (de 1 à n connecteurs)
| _ Engine (1 seul)
|_ Host (de 1 à n hosts)
|_ Context (de 0 à n contexts)
Pour savoir quelle sera la page par défaut d’un site : web.xml
Pour configurer le server : server.xml
3.4
Arborescence Tomcat
\ bin
exécutables
\ common
répertoire partagé entre le serveur et les applications
\ classes
fichiers .class
\ lib
fichiers .jar
\ conf
server.xml
toute la configuration de l’instance du serveur Tomcat
tomcat-users.xml définit les droits des utilisateurs
\ logs
catalina-.log
démarrages et arrêts détaillés du service
stderr/stdout
erreurs et sorties des applications Java prévues pour
\ webapps
répertoire de dépôt des applications
\ ROOT
page par défaut de Tomcat
\ work
contient les fichiers générés par les requêtes
3.5
Le fichier server.xml
Règles d’écritures :
Ecrire tout en minuscule (sauf contre-indications)
Pas de caractères spéciaux (à cause d’UTF-8)
Attention à la case des composants Java : java.xyz.Xyz
Attention à l’ordre et à la fermeture des balises
Faire une copie de sauvegarde avant d’éditer le fichier
Aide : http://localhost:8080/tomcat-docs/config/host.html
Olivier DEHECQ – http://aide.informatique1.fr
Page 12
3.5.1
Les balises
Structure des balises xml :
<Host name="localhost" appBase="webcoursapps" unpackWARs="true">
</Host>
Fichier server.xml :
<server>
port
shutdown
<service>
name
<connector>
port
secure
redirectPort "8443"
enableLookup
max … min …
<host>
name
appBase
unpackWARs
autoDeploy "false"
workDir
<context>
docBase
path
reloadable "true"
swallowOutput
cookies
3.6
définit les propriétés du serveur
"8005"
port d’écoute de Tomcat
"SHUTDOWN"
pour arrêter le service. Il est conseillé de mettre "DODOTOMCAT"
définit les propriétés du service
"catalina" le changer. Mettre "Tomcat5Service" pour les logs
définit les propriétés du connecteur
"8080"
port d’écoute du connecteur
"true"
pour les connecteur HTTPS. Connecteur sécurisé
redirige les requêtes vers un autre port si il n’est pas capable de les traiter
"false"
Pour alléger les traitements des serveurs en exploitation
définit les performances (découpe le moteur en threads)
définit les propriétés de l’hôte
"www.monsite.fr"
nom de l’hôte. Doit être unique
"webcoursapps"
sous répertoire de $catalina… contenant ses fichiers
"true"
pour pouvoir travailler à partir de fichiers .war
prend immédiatement en charge changements de fichiers
"/work"
emplacement du répertoire de travail. /work par défaut.
définit les propriétés du contexte (« site web »)
"monAppliWeb"
répertoire physique contenant le contexte. Emplacement du répertoire de
travail, sous-arborescence du dossier de host.
"/" ou "/toto"
répertoire virtuel du contexte (pour l’appeler en html)
prend immédiatement en charge les changements de la partie privée
"true"
permet la prise en charge des messages dans stdout et stderr (si prévu dans
le programme Java).
"true"
prend en charge les cookies. Vrai par défaut
Déploiement d’une application
1. Déployer les webapps :
copier les arborescences et les fichiers .war dans le dossier de l’host
2. Vérifier dans les répertoires des arborescences (ou dans le fichier .war), que le fichier web.xml
contient bien la page web par défaut :
Fichier web.xml
3. Définir le chemin physique et le nom de l’hôte :
Fichier server.xml
4. Définir l’emplacement physique et virtuel du contexte (par où on le choppe et où il va
réellement chercher les données) :
Fichier server.xml
5. Renseigner le fichier hosts :
Fichier C:\Windows\Drivers\Etc\Hosts
6. Redémarrer le service Tomcat :
C:\> shutdown.bat
C:\> startup.bat
Olivier DEHECQ – http://aide.informatique1.fr
Page 13
4
L’élément <valve> (logs, restrictions, …)
Cet élément permet de configurer des traitements qui se lanceront à chaque fois qu’une requête sera
exécutée. (Un peu comme un trigger : cf. SQL). Utile pour les logs par exemple.



On peut placer la balise <valve> dans <engine>,<host>,<context> ce qui permet de faire de la
granularité.
Il y a entre 0 et plusieurs valves par balise.
On peut associer une valve à un chemin d’accès à une classe Java
Exemple de code xml d’une valve :
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Valve className="mypkg.MyValve" foo="bar"/>
</Host>
4.1
Génération d’un fichier de log local
<valve>
className


"org.apache.catalina.valves.AccessLogValve"
définit le rôle de la valve.
RemoteAddrValve permet de filtrer les adresses IP.
AccessLogValve permet de créer des logs personnalisés.
Cas d’une valve AccessLogValve :
<Valve
className="org.apache.catalina.valves.AccessLogValve" rôle de la valve
directory="${catalina.base}/logs"
répertoire
prefix="access_log"
préfixe du nom de fichier log
fileDateFormat="yyyy-MM-dd.HH"
format de date dans le fichier
suffix=".log"
suffixe du nom de fichier de log
pattern="%t %H cookie:%{SESSIONID}c request:%{SESSIONID}r %m %U %s %q %r"
contenu loggé
/>
4.2
Génération d’un fichier de log vers une BD
<valve
className
connexionURL
driverName
tableName
/>
"org.apache.catalina.valves.JDBCAccessLogValve" permet de logger vers une BD
"jdbc:sqlserver://ipaddr:1443;databasename=myDb;user=tomcat;password=t0m"
chemin de connexion à la BD. Cas de SQLServer
"com.microsoft.sqlserver.jdbc.SQLServerDriver"
nom du driver (connexion au MIDDLEWARE de la BD). Cas de SQL Server.
"SmaLog"
nom de la table qui stockera les données loggées
Olivier DEHECQ – http://aide.informatique1.fr
Page 14
4.2.1
Côté SGBGR
Le port d’attaque du SGBDR est 1443. Un utilisateur tomcat doit être créé avec les droits d’accès. Le
formatage de la table est toujours le même pour les fichiers de log.
Si on démarre le service Tomcat directement :
Erreur grave : exception java.sql.SQLException:com.microsoft.sqlserver.jdbc.SQLServerDriver
Il faut copier le driver JDBC pour la base SQL Server : sqljdbc.jar dans \common\lib\
On peut aussi personnaliser les colonnes telles que définies dans la BD si on n'utilise pas le
format par défaut. Dans ce cas il faut ajouter des attributs à la balise <valve>
(RI p121)
4.3
Les valves RemoteAddrValve et RemoteHostValve (RI p. 121 et
214)
Objectif : Restrictions d'accès par adresses IP
<Valve>
…
allow
deny
"127.0.0.1,10.*"
"10.0.2.101"
seules ces adresses IP sont acceptées
ces adresses IP sont refusées
LES RESSOURCES DU SERVEUR <Resource>
C'est le développeur qui s'adapte au serveur
Olivier DEHECQ – http://aide.informatique1.fr
Page 15
5
Les ressources mises à disposition pour les applications
Java



valeurs constantes (noms prédéfinis)
pools de connexion (nom de pool)
traitements : classes (noms des traitements)
Les noms de ces ressources sont indexés dans l’arbre JNDI.
Au niveau de l’application, l’accès à ces ressources et paramétré dans le fichier web.xml :
<resource-env-ref>
<resource-env-ref-name>envSociete</resource-env-ref-name>
<resource-env-ref-type>java.lang.String</resource-env-ref-type>
</resource-env-ref>
Portée
<Context>
Visibilité
Visible uniquement par
l’application
<Server>
<GlobalNamingResource>
Visible uniquement par le serveur
Méthode recommandée :
<Server>
On peut définir directement
<Resource> dans le contexte.
Méthode
Non recommandé !
<GlobalNamingResource>
<Resource>
<Host>
<ResourceLink>
5.1
Mise en place d'une variable (dans server.xml)
5.1.1
Au niveau de la balise <Context>
<ResourceLink>
name "envSociete"
global "GlobalEnvSociete"
type
"java.lang.String"
5.1.2
nom avec lequel l’appli y accède (tel que référencé dans web.xml).
nom de la ressource pour le serveur
type de variable (ici : chaîne)
Au niveau de la balise <GlobalNamingResource>
<Environment>
name "GlobalEnvSociete"
nom de la ressource pour le serveur
type
"java.lang.String" type de la variable
value "ENI Ecole"
valeur de la variable
5.2
Mise en place d’un pool de connexion
5.2.1
Récupérer le driver SQLJDBC.jar (pour SQL Server 2005)


Le copier dans \common\lib
Le copier dans \server\lib
accès pour les applications
accès pour le serveur
Olivier DEHECQ – http://aide.informatique1.fr
Page 16
5.2.2
Définir la ressource ‘pool de connexion’ dans server.xml :
<GlobalNamingResource>
<Resource>
name "PoolSgbd"
nom de la ressource (= <ResourceLink global).
type
"javax.sql.DataSource"
pour les pools de connexion
auth
"container" ou "Application"
méthode d’authentification.si « container » alors c’est le serveur qui
prend en charge l’authentification, sinon c’est l’application qui le fait (cf. web.xml).
5.2.3
Cas de auth="container"
description
"BD SQL Server" nom de la ressource pour le serveur (facultatif)
driverClassName "com.microsoft.sqlserver.jdbc.SQLServerDriver"
nom du driver (connexion au MIDDLEWARE de la BD). Cas de SQL Server.
url
"jdbc:sqlserver://ipaddr:1443;databasename=myDb;user=tomcat;password=t0m"
chemin de connexion à la BD. Cas de SQLServer
*username
"u1"
login, si non défini dans l’url
*password
"Passw0rd"
mot de passe, si non défini dans l’url
Caractéristiques du pool :
maxActive
["8"]
nombre max de connexions simultanées
maxIdle
["8"]
nombre max de connexions disponibles, en attente
minIdle
["0"]
nombre min de connexions disponibles, en attente
maxWait
["∞"] en ms. Temps max d’attente avant que le serveur renvoie une erreur si elle n’a pas pu
être traitée
initialSize
["0"]
nombre de connexions disponibles au démarrage de tomcat
5.2.4
Au niveau de la balise <Context>
<ResourceLink>
name "sgbd/sqlserver"
global " BD SQL Server "
type
"javax.sql.DataSource "
5.2.5
nom avec lequel l’appli y accède (tel que référencé dans web.xml).
nom de la ressource pour le serveur
type de ressource (base de données SQL)
Résumé
1) Configurer SQL Server : utilisateur (>Securite>Connexion>sa) + vérifier nom base
2) Copier les fichiers sur le serveur : SQLJDBC.jar
3) Définir server.xml <GlobalNamingResource><Resource>
Se baser sur web.xml :
<resource-env-ref>
<resource-env-ref-name>envSociete</resource-env-ref-name>
<resource-env-ref-type>java.lang.String</resource-env-ref-type>
</resource-env-ref>
<resource-env-ref-name> définit le nom de la ressource
4) Définir server.xml (cf. 2.4.2.4)
Olivier DEHECQ – http://aide.informatique1.fr
Page 17
6
La sécurité du serveur et des applications
6.1
Présentation globale
Objectif : sécuriser l’accès à tout ou partie du site
Fichiers intervenant dans la sécurité
Olivier DEHECQ – http://aide.informatique1.fr
Page 18
6.2
Authentification Basique
6.2.1
Le fichier web.xml
Attention à bien fermer les balises au bon endroit !
Le fichier web.xml du serveur est un ‘include’ des fichiers web.xml des applications
<!--definir les éléments sécurisés-->
<security-constraint>
<web-resource-collection>
<!--lister les ressources sécurisées-->
<web-resource-name>Acces Securisé</web-resource-name>
<url-pattern>/FormulaireHttps.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<!-- activer automatiquement le protocole https pour les urls sécurisées-->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
<auth-constraint>
<!--role à définir dans la base de comptes utilisée-->
<role-name>RUserHelloWorld</role-name>
</auth-constraint>
</security-constraint>
<!--déclarer le mode d'authentification utilisé-->
<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>ModeDigest</realm-name>
</login-config>
<!--rôles autorisés pour la connexion-->
<security-role>
<!--role à définir dans la base de comptes utilisée-->
<role-name>RUserHelloWorld</role-name>
</security-role>
6.2.2
Le fichier tomcat-users.xml
<tomcat-users>
<role rolename="RUserHelloWorld"/>
<user username="u1" password="secret" roles="RUserHelloWorld"/>
</tomcat-users>
6.2.3
Le fichier server.xml
On utilise la configuration de base de server.xml. Rien à changer.
<GlobalNamingResources>
<!-- name=resourceName -->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
<!-- chemin du royaume -->
pathname="conf/tomcat-users.xml" />
…
<Engine>
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
Comme le auth-mode du web.xml est BASIC, alors utilise le royaume présent par défaut dans le
<Engine>. C’est le UserDatabase, il utilise conf/tomcat-users.xml
Olivier DEHECQ – http://aide.informatique1.fr
Page 19
6.3
Authentification Digest
6.3.1
Le fichier web.xml
Identique à la méthode BASIC, sauf pour les balises :
<!--déclarer le mode d'authentification utilisé-->
<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>ModeDigest</realm-name>
</login-config>
Astuce : la boite de dialogue pour l’authentification est différente !
6.4
Les royaumes


InMemory Realm
JDBC Realm
royaumes chargés en mémoire. Ex. : tomcat-users.xml
royaumes presents sur les Bases de données
Olivier DEHECQ – http://aide.informatique1.fr
Page 20
6.4.1
Eviter le stockage des mots de passe en clair
On peut hacher les mots de passe en SHA ou en MD5 par défaut dans Tomcat (sinon il faut installer
des outils).
Le mode BASIC permet l’encryptage des mots de passe en SHA et MD5, le mode DIGEST ne prend en
charge que le MD5.
Méthode (RI p.189) :
C:\> digest .bat|.sh -a md5|sha <mot de passe en clair>
<mot de passe en clair> : utilisateur:ModeDigest:motdepasse
ModeDigest : valeur de <realm-name> dans web.xml
1. Exécuter la commande suivante :
C:\> digest.bat -a md5 toto:ModeDigest:1234
2. On copie ensuite le mot de passe haché à la place du mot de passe clair dans le royaume
(exemple : tomcat-users.xml)
3. On modifie ensuite la balise Realm de server.xml
digest="md5"
6.4.2
Modification du royaume utilisé (pour le mode DIGEST)
web.xml :
Définir les paramètres souhaités
server.xml
Placer la balise <Realm> dans le contexte de l’application voulue, changer le resourceName.
Dans la balise <GlobalNamingResource><Resource> changer le name et le pathname.
dans \conf, créer un royaume et ajouter les rôles et users.
6.5
Résumé sur les ressources et la sécurité
<GlobalNamingResource>
<Environment
<Resource
déclaration des ressources
ressource simple (exemple : variable)
ressource complexe (pool de connexion, user database)
<Engine> | <Host> | <Context> mise à disposition pour l’application
<ResourceLink
lien de la mise à disposition. Ressource de type environment, pool de connexion
<Realm
lien de la mise à disposition d’un royaume type userDatabase (resource
6.6
SSL (HTTPS) Transport crypté
Sécurise le mode de transport (cryptage des requêtes : entête + données), mais le mot de passe +
login sont envoyés en méthode BASIC ou DIGEST.
6.6.1
Le fichier web.xml
<security-constraint>
<!-- activer automatiquement le protocole https pour les urls sécurisées-->
<user-data-constraint>
< !--au même niveau que la ressource à sécuriser en HTTPS -->
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
Il faut en + rajouter les balises permettant le mode BASIC / DIGEST
Olivier DEHECQ – http://aide.informatique1.fr
Page 21
6.6.2
L’outil keytool (générer un certificat) – RI p.120
C:\> C:\Program Files\Java\jdk1.6.0_04\bin\keytool -genkey -alias <host concerné> -keyalg RSA -keystore
<Emplacement du certificat>
C:\> keytool -genkey –alias www.helloworld.fr –keyalg RSA –keystore c:\helloworld.keystore
Renseigner ensuite tous les champs, sauf le mot de passe de la clé à la fin (à cause de tomcat)
6.6.3
Server.xml
<Connector port="8443" disableUploadTimeout="true"
acceptCount="100" enableLookups="false" maxSpareThreads="75"
minSpareThreads="25" maxThreads="150" maxHttpHeaderSize="8192"
keystorePass="password" keystoreFile="c:\helloworld.keystore"
sslProtocol="TLS" clientAuth="false" secure="true" scheme="https"
/>
Fonctionnement de l’envoi de certificat pour https
Olivier DEHECQ – http://aide.informatique1.fr
Page 22
7
Les fichiers journaux – Analyse et supervision
7.1
Le fichier conf\logging.properties


Création d’un handler « 6www_hellowold_fr.org.apache.juli.FileHandler » qui va écrire tout ce
qu’il reçoit vers le répertoire de base /logs/www_helloworld_fr-xxxxx.log
Création d’un logger « org.apache.catalina.core.ContainerBase.[Catalina].[www.helloworld.fr] »
qui va écouter tout ce qui se dit sur le moteur [catalina] pour l’host [www.helloworld.fr] et va
le répéter au handler « 6www_hellowold_fr.org.apache.juli.FileHandler »
handlers = 1catalina.org.apache.juli.FileHandler, …, 6www_helloworld_fr.org.apache.juli.FileHandler
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
############################################################
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
##handler personnalisé vers la sortie www_helloworld_fr-xxxx.log
6www_helloworld_fr.org.apache.juli.FileHandler.level=ALL
6www_helloworld_fr.org.apache.juli.FileHandler.formatter=java.util.logging.SimpleFormatter
6www_helloworld_fr.org.apache.juli.FileHandler.directory=${catalina.base}/logs
6www_helloworld_fr.org.apache.juli.FileHandler.prefix=www_helloworld_fr6www_helloworld_fr.org.apache.juli.FileHandler.suffix=.log
############################################################
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler
##créer le logger pour le host www.helloworld.fr
org.apache.catalina.core.ContainerBase.[Catalina].[www.helloworld.fr].level=ALL
org.apache.catalina.core.ContainerBase.[Catalina].[www.helloworld.fr].handlers=6www_helloworld_fr.org.apach
e.juli.FileHandler
org.apache.catalina.core.ContainerBase
chemin jusqu’au Server
[Catalina]
nom du Engine
[www.helloworld.fr]
nom du Host (en dernier, donc audité)
[/context]
nom du context (pas dans cet exemple)



Créer un handler :
Créer un logger (RI p.228) :
Lister les handlers :
6www_helloworld_fr.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[www.helloworld.fr]
handlers= …, 6www_helloworld_fr.org.apache.juli.FileHandler
Récupérer le détail des requêtes (si demandé) dans server.xml (RI p115) :
<Host name="www.helloworld.fr" … />
<!--récupérer les requêtes clientes et les écrire dans le fichier de journalisation (cf Logger et Handler dans le
fichier logging.properties-->
<Valve className="org.apache.catalina.valves.RequestDumperValve"></Valve>
Olivier DEHECQ – http://aide.informatique1.fr
Page 23
Téléchargement