Dans ce chapitre on va décrire un modèle de sécurité faisant intervenir les concepts de l’architecture orientée services, des spécifications WS-* et plus particulièrement WS-Security et la plate-forme J2EE.

La sécurité des services Web fait partie intégrante de la stack des spécifications WS-*.

Plusieurs standards lui sont associés. Les plus importants et les plus stables en terme de spécifications sont cités ci-dessous. Pour plus de détails concernant chaque spécification se reporter aux autres livres blancs sur la sécurité niveau données et messages.

Afin de comprendre l’interaction entre les participants à une transaction basée sur un service Web, il conviendrait de dresser la cinématique relative au flux de messages transportés entre l’infrastructure Client et l’infrastructure Serveur. Ensuite seront associées les différentes spécifications, standards et outils associés à chaque étape de ce flux.

Les schémas mettent en jeu un client et un serveur, la cinématique peut être adaptée dans le cas d’un échange avec un intermédiaire ou plusieurs.

La cinématique ci-dessous ne fait pas référence au contexte de sécurité partagé et constitue un modèle dont la topologie reste simple et compréhensible.

Ci-dessous Le flux des messages

1. Le code client initialise l’environnement relatif à l’infrastructure client en récupérant des informations sur le proxy de connexion et soumet la requête désirée. Dans le contexte de la plate-forme J2EE, le client utiliserait l’api Jax-RPC.
2. Une fois l’infrastructure client alertée de la requête du client, cette dernière associe un processus à cette requête. Le processus correspond à un ensemble de services coordonnés et orchestrés. Pour chaque service, l’infrastructure client se connecte à l’annuaire des services et récupère la définition liée au service en téléchargeant le fichier WSDL représentatif.
3. une fois le fichier WSDL récupéré, l’infrastructure client se connecte à l’annuaire de policy (politique ou stratégies) puis récupérer les stratégies associées à l’appel du service Web. Ces stratégies peuvent contenir des exigences en terme de sécurité.
4. L’infrastructure Client Interprète les stratégies de sécurité de l’invocation du service, par exemple savoir quelle partie du message doit être cryptée. En ayant le fichier de policy, l’infrastructure client identifie le type de jetons de sécurité attendus par l’infrastructure serveur.
5. L’infrastructure client demande au client de spécifier son identité afin de l’autoriser.
6. Une fois l’identité du client validée, un jeton de sécurité est récupère via le fournisseur d’identité.
7. Lors de cette étape, le client constitue le message de la requête SOAP. Il signe le message, crypte les parties sensibles et associe le jeton de sécurité à l’entête du message. Une fois le message sécurisé créé il est enfin envoyé à l’infrastructure du serveur.
8. L’infrastructure serveur s’occupe de valider le message de le décrypter et de vérifier le jeton de sécurité afin d’installer une relation de confiance. Une fois la confiance établie, le service final est invoqué.

Ci-dessous sont associés à chaque étape de cette des technologies, standards et spécifications.

Un composant web est une entité logicielle qui fournit une réponse à une requête.

Les composants web générent habituellement l'interface utilisateur d'une application web.

La plateforme J2EE définit deux types de composants web : les servlets et les JavaServer Pages (JSP).

La section suivante donne un apercu de ces composants qui sont détaillés utlérieurement.
Servlets

Une servlet est un composant qui étend les fonctionnalités d'un serveur web de manière portable et efficace.

Un serveur web héberge des classes Java servlets qui sont exécutées à l'intérieur du container web. Le serveur web associe un e ou plusieurs URLs à chaque servlet et lorsque ces URLs sont appelées via une requête HTTP de l'utilisateur la servlet est déclenchée.

Quand la servlet recoit une requête du client, elle génére une réponse, éventuellement en utilisant la logique métier contenue dans des EJBs ou en interrogeant directement une base de données. Elle retourne alors une réponse HTML ou XML au demandeur.

Un développeur de servlet utilise l'API servlet pour :

• Initialiser et finaliser la servlet


• Accéder à lénvironnement de la servlet


• Recevoir ou rediriger les requêtes et envoyer les réponses


• Interagir avec d'autres serlvets ou composants


• Maintenir les informations de sessions du client


• Filtrer avant ou après traitement les requêtes et les réponses


• Implémenter la sécurité sur le tier web

JavaServer Pages

La technologie JavaServer Pages (JSP) fournit un moyen simple et extensible pour générer du contenu dynamique pour le client web.

Une page JSP est un document texte qui décrit comment traiter la requête d'un client et comment créer une réponse.

Une page JSP contient :

• des informations de formatage (modèle) du document web, habituellement en HTML ou XML. Les concepteurs web peuvent modifier cette partie de la page sans affecter les parties dynamiques. Cette approche permet de séparer la présentation du contenu dynamique.


• des élements JSP et de script pour générer le contenu dynamique du document Web. La plupart des pages JSP utilise aussi des JavaBeans et/ou des Enterprise JavaBeans pour réaliser les opérations complexes de l'application. Les JSP permettent en standard d'instancier des beans, de modifier ou lire leurs attributs et de télecharger des applets. La technologie JSP est extensible en utilisant des balises personnalisées qui peuvent être encapsuler dans des bibliothèques de balises personnaliées (taglibs)

Conteneur de composants web

Les composants webs sont hébergés dans des conteneurs de servlets, conteneurs de JSP et conteneurs web.

En sus des fonctionnalités normales d'un conteneur de composants, un conteneur de servlets (servlets container) fournit les services réseaux par lesquels les requêtes et réponses sont émises.

Il décode également les requêtes et formate les réponses dans le format approprié.

Tous les conteneurs de servlets doivent supporter le protocole HTTP et peuvent aussi supporter le protocole HTTPS.

Un conteneur de JSP (JSP container) fournit les mêmes services qu'un conteneur de servlets.

Ces conteneurs sont généralement appelés conteneurs web (Web containers).

L'architecture Enterprise JavaBeans est une technologie côté serveur pour développer et déployer des composants contenant la logique métier d'une application d'entreprise.

Les composants Enterprise JavaBeans, aussi appelé Enterprise Beans, sont scalables, transactionnel et supporte l'accès concurrent.

Il y a 3 types d'enterprise beans : les beans de sessions, d'entité et de messages.

Les bean de session et d'entité comportent 2 interfaces : une interface de composant et une interface home.

L'interface home définit les méthodes pour créer, trouver, supprimer et accéder aux méta-données d'un bean.

L'interface de composant définit les méthodes métiers du bean.

Le bean à message n'ont pas d'interfaces home et composant.

Les interfaces composant et home d'un bean sont locales ou distantes.

Les interfaces distantes (remote interface) sont des interfaces RMI qui permettent au client du bean d'être situé n'importe où. Dans ce cas les arguments et valeurs de retour communiquées entre le client et le bean distant sont sérialisées pour être transportées sur le réseau, ce qui consomme des ressources.
Les interfaces locales impliquent que les clients du bean soient localisés dans la même machine virtuelle que le bean. Dans ces cas les arguments et valeurs de retours échangés sont transmis par référence. Cette méthode est plus performante que la méthode distante.

La section suivante donne un apercu des composants EJB. Ils sont décrits en détail dans la suite du document.

Beans de session (session bean)

Un bean de session fournit un service au lcient et habituellement n'existe que le temps d'une session cliente.

Un bean de session accompli des opérations de calcul ou d'accès à une base de données pour le client.

Bien qu'un bean de session puisse être transactionnel, il ne dispose pas de mécanismes de reprise sur erreur en casde plantage du serveur.

Les beans de session peuvent être sans état (stateless) ou peuvent maintenir des informations d'état entre les appels de méthode et les transactions (stateful).

Si le bean maintient des informations d'état, c'est au container d'EJB de garder ces informations lorsque le bean est déchargé de la mémoire du serveur. Cependant c'est au bean lui-même de gérer la persistance des données si il y a lieu.

Beans d'entité (entity bean)

Un bean d'entité est un objet persistant qui représente des données stockés dans une entrepôt de données.

Un bean d'entité est identifié par sa clé primaire (primary key).

Un bean d'entité peut assurer lui-même la persistance de ses données ou la déléguer au conteneur d'EJB.

Les beans dont la persistance est gérée par le conteneur sont plus portables et peuvent maintenir des relations entre eux. Cette fonction permet de joindre plusieurs tables de bases de données.

Si le bean gére lui-même sa persistance, alors le programmeur devra surement changer une partie du code SQL en changeant de base de données.

Bean à message (Message-Driven Beans)

Un bean à message permet à un client asynchrone d'accéder à la logique métier d'un tier EJB.

A message-driven bean enables asynchronous clients to access the business logic in the EJB tier. Les beans à messages sont activés uniquement par des messages recus d'une file de message JMS qu'ils écoutent.

Les clients n'accèdent pas directement au bean à message mais envoient un message à la file JMS.

Comme les beans à messages n'ont pas besoin d'exposer leurs méthodes à un client ils n'implémentent pas les interface composants ou home.

Ils ne maintiennent pas non plus d'information d'état sur le client.

Conteneur d'EJB (EJB Component Containers)

Les Enterprise beans sont hébergés dans des conteneurs d'EJB (EJB container). En plus des services traditionnels d'un conteneur, un conteneur EJB fournit des services de transaction et de persistance aux beans qu'il héberge, ainsi qu'un accès qaux services J2EE et aux APIs de communication.

La plateforme J2EE prévoit que plusieurs types de clients puissent accéder à une même application et interagir avec les composants côté serveur.

Applets

Les Applets sont des clients Java qui s'exécutent habituellement dans un navigateur web et qui ont accès à toutes les possibilités du langage Java. Les applications J2EE peuvent utiliser des clients applets pour avoir des interfaces utilisateurs plus puissantes que celles conues en HTML. Les applets communiquent avec le serveur par HTTP.

Applications clientes

Des applications clientes s'exécutent dans leur propre conteneur client. (le conteneur client est un jeu de librairies et d'API qui supportent le code client). Les applications clients ont des interfaces utilisateurs qui peuvent directment interagir avec le tier EJB en utilisant RMI-IIOP. Ces clients ont un accès complet.aux services de la plateforme J2EE comme les services de nommage JNDI, l'envoi de messages et JDBC. Le conteneur client gére l'accès à ces services et les communications RMI-IIOP.

Applications clientes Java Web Start

Les applications clients Java Web Start sont des applications autonomes reposant sur les JFC et Swing et capables d'utiliser les services de la plateforme J2EE par l'intermédiaire de la technologie Java WebStart. Ces applications peuvent être installées par le web et comuniquent avec le servuer en utilisant du XML encapsulé dans du HTTP(S).

Clients sans fil

Les clients sans fil sont basés sur la technologie Mobile Information Device Profile (MIDP), en conjonction avec Connected Limited Device Configuration (CLDC), qui fournissent un environnement J2ME complet pour les dispositifs sans fil.

Principes J2EE

L’architecture J2EE est une architecture d’application distribuée à base de composants.

Elle identifie et donne les spécifications des composants de l’application :

• composants logiciels ou beans (EJB),
• conteneur
• serveurs
• clients
  

Les conteneurs isolent les beans du client et d’une implémentation spécifique du serveur.

Les beans sont installés dans la partie serveur d’une application J2EE.

Les conteneurs et serveurs implémentent les mécanismes de bas niveau utilisés par les applications :

• transactions,
• persistance,
• gestion de la mémoire,
• sécurité

Les spécifications J2EE s’intéressent aux activités d’une application liées :

• au développement,
• au déploiement,
• à l’exécution.

Technologies de composants utilisées dans J2EE

Un composant est une unité logicielle de niveau applicatif.

En plus des JavaBeans, qui font partie du J2SE, J2EE supporte les typesde composants suivants :

• applets,
• application clientes,
• composants Enterprise JavaBeans (EJB),
• composants Web,
• composants adaptateurs de resource

Les applets et applications clientes sont exécutées sur le poste du client tandis que les composants EJB, Web et adaptateurs de ressources fonctionnent sur le serveur.

A léxception des adaptateurs de ressources, les concepterus et développeurs d'application développents les composants d'une application J2EE.

Les adapteurs de ressources et logiciels associés sont en géneral vendu par les forunisseurs de systèmes d'information de l'entreprise et ensuite déployés sur les serveurs pour accèder aux données.

Tous les composants J2EE dépendent à l'exécution d'un entité système baptisée conteneur (container).

Les conteneurs fournissent aux composants des services de bases comme la gestion du cycle de vie, la sécurité, le déploiement et l'exécution en thread. Comme cést le conteneur qui gère ces services, la plupart des paramètres de configuration de ces services peuvent être configurés lors du déploiement des omcposants en fonction de la plateforme d'accueil.

Par exemple un fournisseur d'Enterprise JavaBean peut spécifier un nom de base de données auquel le composant doit accéder et c'est seulement lors du déploiement que les informations d'accès à la base (nom d'utilisateur et mot de pase ) seront configurés.

Les sections suivantes donnent un bref apercu des composants, qui seront étudiés plus en détail par la suite.