Implementing a simple RMI Application over the Internet (using and comparing HTTP tunneling, RMI Proxy)

Transcription

1 Implementing a simple RMI Application over the Internet (using and comparing HTTP tunneling, RMI Proxy) Abstract Un problème se pose lorsque l on veut effectuer des appels RMI à travers un firewall, car souvent il empêche l accès à certains ports pour cause de sécurité. Une technique peut être le HTTP tunneling où les appels se font sous forme de requête HTTP à l aide d une servlet. Une deuxième technique expliquée dans ce document est le RMIProxy, dans laquel on place un proxy RMI pour chaque firewall, celui-ci effectue un contrôle pour ne laisser passer que les requête RMI, il permet aussi d ajouter d autres contraintes. Ce document permettra de se faire une idée sur ces deux concepts permettant aux requêtes RMI de traverser des firewall. Master Seminar Advanced Software Engineering Topics Prof. Jacques Pasquier-Rocha University of Fribourg, Switzerland Departement of Informatics Software Engineering Group Author : Fabien Pochon fabien.pochon@unifr.ch Supervisor : Patrik Fuhrer patrik.fuhrer@unifr.ch Jun 12, 2003

2 Table des matières 1. Introduction Problématique HTTP Tunneling Comment RMI «tunnelle» des messages Naming services and «the server machine» L implémentation d un servlet pour le HTTP tunneling Le code du servlet Modifications à apporter afin d utiliser le Tunneling Désavantages du HTTP tunneling Configuration du fichier policy Exemple d appel RMI utilisant HTTP tunneling RMIProxy Où trouve-t-on RMIProxy Les objectifs Les caractéristiques Le contrôle d accès L architecture Comment RMIProxy fonctionne L API coté client L API côté serveur Proxies multiple Limitations du RMI Proxy Activation Stubs cachés Socket Factories GetClientHost RMI / IIOP Stubs distants indirectes Les modifications à apporter au client et au serveur Les différences entre RMI Proxy et HTTP tunneling Conclusion Le RMI Proxy est certainement une méthode bien meilleur que le HTTP tunneling, car elle ne comporte que des avantages sur cette dernière. Malheureusement je n ai pas testée Annexes : Configurations Installation du seveur Apache Installation de Tomcat Configuration du serveur Apache Redirection du script CGI Bibliographie

3 1. Introduction RMI (Remote Method Invocation) est un système distribué, ce qui signifie que une ou plusieurs applications peuvent s exécuter sur une ou plusieurs machines. Une caractéristique d un système distribué est le besoin de collaboration entre les différents processus qui composent le système. Ce qui donne l illusion à l utilisateur qu il utilise une application locale, alors que des invocations de méthodes se font dans un autre processus qui peut être sur une machine différente. Il y a donc un échange d informations qui s effectue entre plusieurs machines à l aide du protocole RMI. Ceci peut s effectuer sans aucun problème lorsque il n y a aucun firewall entre les deux parties communiquant via RMI. Lorsque un firewall sépare le client d un serveur il y aura certainement un problème. C est ce problème et la solution pour le contourner qui va donc être traité plus en détail dans ce document. 2. Problématique Le problème principal qui intervient lorsqu un client veut effectuer un appel RMI sur une machine distante est effectivement le firewall qui peut y avoir entre les deux. En effet les firewalls interdisent souvent l accès à certains ports spécialisés comme ceux qu on désire utiliser lors d un appel RMI. Les firewalls sont capables de filtrer des paquets selon : Leur adresse source Leur adresse de destination Le port de destination Le protocole de niveau supérieur (exemple : TCP, UDP) utilisé Cependant les firewalls sont généralement incapables de prendre des décisions en fonction des données contenues dans ces paquets. C est pourquoi les techniques de tunneling, RMI Proxy ou encore d autres peuvent être utilisées. 3

4 3. HTTP Tunneling Le principe de base du http tunneling est d utiliser comme protocole de communication des appelles http à travers le Web pour des application qui ne se font pas par le Web. Le requête originale émise n est pas envoyé par un Web browser mais par une instance d une URLClassLoader, et la réponse n est pas une page html mais le code binaire d une classe. HTTP tunneling est utilisé pour deux raisons essentielles, qui sont les deux très pragmatiques. Premièrement il permet au développeur d applications d utiliser les composants et l infrastructure qui existe déjà pour les applications web, il est alors facile de définir un protocole utilisant ces composants. De plus il rend aussi facilement possible aux développeurs d applications d incorporer de multiples langages. Depuis que presque chaque langage moderne a sa librairie permettant de traiter et de générer du XML, utiliser HTTP et XML pour définir un protocole permet au client d être écrit dans un langage et le serveur dans un autre. La seconde raison d utiliser HTTP tunneling est qu il est possible pour des applications distribuées d éviter les firewalls. Pour comprendre pourquoi il suffit de regarger la figure 1. Figure 1 : HTTP tunneling en action (tirée de O Reilly, Java RMI) Le point clé dans cette architecture est que le client utilise une couche supplémentaire (marshalling layer) qui encode la requête du client en une requête HTTP valide. Le serveur de l autre coté possède aussi une couche supplémentaire (layer of demarshalling code), laquelle transforme une requête HTTP en une requête correspondant à celle attendue par le serveur. Le HTTP tunneling est divisé en trois parties : 4

5 Le client : Envoie une requête au serveur web Le servlet : Transmet la requête à la socket du serveur RMI en préservant la structure HTTP qui a été envoyée par le client Le serveur : Transforme automatiquement l envoi HTTP en une commande JRMP (Java Remote Method Invocation) 3.1 Comment RMI «tunnelle» des messages Maintenant le but du mécanisme de RMI HTTP tunneling devrait être clair : il encode un appel de méthode à distance à la façon d une requête HTTP POST, et ensuite décode la «page web» retournée en une réponse du type approprié. RMI accomplit ceci de la même manière en utilisant un type élaboré de socket, dans laquelle une sérialisation est faite pour générer aussi bien les requêtes que les réponses HTTP. Bien qu un différent mode de socket est utilisé, RMI va utiliser par défaut son propre mode de socket quand des connections seront créées. Les sockets par défauts retournées par RMI tentent d utiliser HTTP tunneling si auparavant elles ont reçu une erreur du serveur. Les sockets par défaut emploient la stratégie suivante quand elles tentent une invocation de méthode sur un serveur : 1. Tentent d établir une connexion JRMP directe vers le serveur. 2. Si la connexion échoue, elles tentent d établir une connexion HTTP directe avec le serveur. Ainsi elles créent une connexion par socket vers le port sur lequel le serveur est en train d écouter et ensuite communique en encapsulant les méthodes demandées dans des requêtes HTTP. La première chose que le «RMI demarshalling» effectue est de déterminer si la requête a été encodée en utilisant JRMP ou HTTP. 3. Si la requête échoue encore, elles tentent d utiliser le firewall comme un serveur proxy (demandant au firewall de transmettre la requête au port approprié du serveur). Le firewall transmettra la requête comme une requête HTTP (le firewall ne va pas traduire la requête en appel RMI). 4. Si il y a encore un échec, elles tentent de se connecter sur le port 80 de la machine serveur et lui envoie la requête selon un URL commençant avec /cgi-bin/java-rmi.cgi. Cet URL signifie que la requête doit être transmise vers un programme qui interprète les requêtes HTTP et qui la transmet, comme une requête HTTP, vers le port approprié du serveur. Cette façon de communiquer peut paraître plutôt complexe. Ces points sont classés dans l ordre décroissant de leur privilège. De plus ces points sont indépendants les uns des autres, il est possible d imaginer un scénario pour lequel le quatrième point soit l unique possibilité d établir une communication. Par exemple supposons qu un firewall ait été installé pour ne permettre qu uniquement les connexions HTTP vers un serveur et qu un serveur RMI soit derrière le firewall. Un client qui essaye de communiquer avec le serveur aura besoin 5

6 d utiliser une stratégie différente selon si il se trouve derrière le firewall (il se trouve dans un intranet) ou en dehors du firewall (il se situe n importe où ailleurs sur l Internet). Si il se trouve à l intérieur du firewall, la première stratégie de connexion (direct JRMP) sera disponible et aura donc un sens. Si le client est à l extérieur du firewall, il y aura deux options qui dépendront du «firewall policy». Si le firewall permet les connexions HTTP sur n importe quel port et n insiste pas sur un trafic sur le port 80, la seconde option d envoyer une information HTTP directement sur le port sur lequel le serveur écoute est plus efficace. Cependant si le firewall insiste sur le fait que tout trafic HTTP doit être envoyé sur le port 80, alors la quatrième option sera la seule façon d établir une connexion. 3.2 Naming services and «the server machine» Un point important, qui n a pas encore été traité est que «la machine serveur» dans la quatrième option est une abstraction, elle n est pas nécessairement sur la même machine que l objet serveur actuel. C est simplement un nom de machine stocké dans le stub. Ce niveau supplémentaire d indirection permet au HTTP tunneling d être implémenté de façon flexible. Prenons par exemples un firewall qui réduit toutes les connexions entrantes à être des requêtes HTTP sur le port 80. Si nous mettons le «naming service» à l extérieur du firewall et la valeur du java.rmi.server.hostname prend le nom du server web, alors la quatrième option devra être utilisée. De cette façon, RMI tentera d envoyer des messages à notre serveur en appelant un URL commançant par /cgi-bin/java-rmi.cgi. Ceci ne force pas le serveur RMI à fonctionner sur la même machine que le serveur web. Cela signifie simplement que nous avons besoin d écrire une classe servlet qui effectue l étape finale dans la redirection de la requête RMI et qui ensuite configure le serveur web afin qu il envoye toutes les requêtes avec l URL approprié au servlet. Figure 2 : Le cheminement des messages (tirée de O Reilly, Java RMI) 6

7 L architecture résultante ressemble au diagramme de la figure 2. Les nombres montrent le cheminement des messages. 3.3 L implémentation d un servlet pour le HTTP tunneling Pour le déroulement de la quatrième stratégie, il y a une manière de transmettre l invocation de méthode au serveur RMI. La première implémentation de cette méthode que Sun Microsystems, Inc. développa était un script CGI. Les points suivants sont requis : Chaque invocation distante de méthodes est envoyée comme une requête HTTP POST L URL complet utilisé est de la forme /cgi-bin/java-rmi.cgi?forward=[port number] Le corps du POST contient toutes les données de la requête distante comme un objet sérialisé qui est ensuite converti en une chaîne de caractères ASCII. Après que la spécification des servlets fut défini, Sun créa un servlet qui fournit les mêmes fonctionnalités que le script CGI Le code du servlet Le code du servlet développé consiste en deux classes principales et en une liste de classes d exceptions. Les deux classes principales sont SimplifiedServletHandler et ServletForwardCommand. Elles ont les rôles suivants : SimplifiedServletHandler : Cette classe étend HTTPServlet. Elles reçoit les requêtes et effectue un validation préliminaire. ServletForwardCommand : C est une liste de méthodes statiques qui sait comment interpréter un HTTP POST et renvoyer ceci au serveur RMI qui tourne sur la même machine. Le code de SimplifiedServletHandler : public class SimplifiedServletHandler extends HttpServlet { public void init(servletconfig config) throws ServletException { super.init(config); System.out.println("Simplified RMI Servlet Handler loaded sucessfully."); public void dopost(httpservletrequest req, HttpServletResponse res) throws ServletException, IOException { try { String querystring = req.getquerystring(); String command, param; 7

8 int delim = querystring.indexof("="); if (delim == -1) { command = querystring; param = ""; else { command = querystring.substring(0, delim); param = querystring.substring(delim + 1); if (command.equalsignorecase("forward")) { try { LoggingServletForwardCommand.execute(req, res, param); catch (ServletClientException e) { returnclienterror(res, "client error: " + e.getmessage()); e.printstacktrace(); catch (ServletServerException e) { returnservererror(res, "internal server error: " + e.getmessage()); e.printstacktrace(); else { returnclienterror(res, "invalid command: " + command); catch (Exception e) { returnservererror(res, "internal error: " + e.getmessage()); e.printstacktrace(); public void doget(httpservletrequest req, HttpServletResponse res) throws ServletException, IOException { returnclienterror(res, "GET Operation not supported: " + "Can only forward POST requests."); public void doput(httpservletrequest req, HttpServletResponse res) throws ServletException, IOException { returnclienterror(res, "PUT Operation not supported: " + "Can only forward POST requests."); public String getservletinfo() { return "RMI Call Forwarding Servlet Servlet.<br>\n"; private static void returnclienterror(httpservletresponse res, String message) throws IOException { res.senderror(httpservletresponse.sc_bad_request, "<HTML><HEAD>" + "<TITLE>Java RMI Client Error</TITLE>" + "</HEAD>" + "<BODY>" + "<H1>Java RMI Client Error</H1>" + message + "</BODY></HTML>"); System.err.println(HttpServletResponse.SC_BAD_REQUEST + "Java RMI Client Error" + message); private static void returnservererror(httpservletresponse res, String message) 8

9 throws IOException { res.senderror(httpservletresponse.sc_internal_server_error, "<HTML><HEAD>" + "<TITLE>Java RMI Server Error</TITLE>" + "</HEAD>" + "<BODY>" + "<H1>Java RMI Server Error</H1>" + message + "</BODY></HTML>"); System.err.println(HttpServletResponse.SC_INTERNAL_SERVER_ERROR + "Java RMI Server Error: " + message); Presque tout du processus logique de SimplifiedServletHandler est contenu à l intérieur de la méthode dopost(). La méthode dopost() parcourt l URL pour déterminer le port sur lequel le serveur écoute. Si l URL est un URL valide et contient le port, la requête est ensuite transmise à la méthode statique execute() du ServletForwardCommand. Le ServletForwardCommand comprends une série de méthodes statiques présentées ci-dessous : public class ServletForwardCommand { public static void execute(httpservletrequest request, HttpServletResponse response, String stringifiedport) throws ServletClientException, ServletServerException, IOException { int port = convertstringtoport(stringifiedport); Socket connectiontolocalserver = null; try { connectiontolocalserver = connecttolocalserver(port); forwardrequest(request, connectiontolocalserver); forwardresponse(response, connectiontolocalserver); finally { if (null!= connectiontolocalserver) { connectiontolocalserver.close(); private static int convertstringtoport(string stringfiedport) throws ServletClientException { int returnvalue; try { returnvalue = Integer.parseInt(stringfiedPort); catch (NumberFormatException e) { throw new ServletClientException("invalid port number: " + stringfiedport); if (returnvalue <= 0 returnvalue > 0xFFFF) { throw new ServletClientException("invalid port: " + returnvalue); if (returnvalue < 1024) { throw new ServletClientException("permission denied for port: " + returnvalue); 9

10 return returnvalue; private static Socket connecttolocalserver(int port) throws ServletServerException { Socket returnvalue; try { returnvalue = new Socket(InetAddress.getLocalHost(), port); catch (IOException e) { throw new ServletServerException("could not connect to " + "local port"); return returnvalue; private static void forwardrequest(httpservletrequest request, Socket connectiontolocalserver) throws IOException, ServletClientException, ServletServerException { byte buffer[]; DataInputStream clientin = new DataInputStream(request.getInputStream()); buffer = new byte[request.getcontentlength()]; try { clientin.readfully(buffer); catch (EOFException e) { throw new ServletClientException("unexpected EOF " + "reading request body"); catch (IOException e) { throw new ServletClientException("error reading request" + " body"); DataOutputStream socketout = null; // send to local server in HTTP try { socketout = new DataOutputStream(connectionToLocalServer.getOutputStream()); socketout.writebytes("post / HTTP/1.0\r\n"); socketout.writebytes("content-length: " + request.getcontentlength() + "\r\n\r\n"); socketout.write(buffer); socketout.flush(); catch (IOException e) { throw new ServletServerException("error writing to server"); private static void forwardresponse(httpservletresponse response, Socket connectiontolocalserver) throws IOException, ServletClientException, ServletServerException { byte[] buffer; DataInputStream socketin; try { socketin = new DataInputStream(connectionToLocalServer.getInputStream()); catch (IOException e) { throw new ServletServerException("error reading from " + "server"); String key = "Content-length:".toLowerCase(); boolean contentlengthfound = false; String line; int responsecontentlength = -1; 10

11 do { try { line = socketin.readline(); catch (IOException e) { throw new ServletServerException("error reading from server"); if (line == null) { throw new ServletServerException("unexpected EOF reading server response"); if (line.tolowercase().startswith(key)) { responsecontentlength = Integer.parseInt(line.substring(key.length()).trim()); contentlengthfound = true; while ((line.length()!= 0) && (line.charat(0)!= '\r') && (line.charat(0)!= '\n')); if (!contentlengthfound responsecontentlength < 0) throw new ServletServerException("missing or invalid content length in server response"); buffer = new byte[responsecontentlength]; try { socketin.readfully(buffer); catch (EOFException e) { throw new ServletServerException("unexpected EOF reading server response"); catch (IOException e) { throw new ServletServerException("error reading from server"); response.setstatus(httpservletresponse.sc_ok); response.setcontenttype("application/octet-stream"); response.setcontentlength(buffer.length); try { OutputStream out = response.getoutputstream(); out.write(buffer); out.flush(); catch (IOException e) { throw new ServletServerException("error writing response"); Il y a trois points importants à relever dans ServletForwardCommand. Premièrement, on utilise des sockets pour transmettre le corps du message HTTP au serveur RMI et ensuite des simples «pipes» que le serveur RMI retourne dans des sorties HttpServletResponse. Le second point important est que ServletForwarder transmet le message sans décoder les données ou comprendre le message. Même si le corps de la requête HTTP contient des instances de classes sérialisées, ServletForwarder n a pas besoin d avoir ces classes dans son classpath ou de traiter les instances sérialisées, il s occupe simplement de copier des bytes d un endroit vers un autre. 11

12 3.4 Modifications à apporter afin d utiliser le Tunneling La socket RMISocketFactory tentera par défaut automatiquement d utiliser le HTTP tunneling quand les autres connexions auront échouées. Il n y a pas besoin de changer ni le code du serveur ni le code du client, il suffit simplement d ajouter un ligne dans le code du client afin qu il puisse utiliser le HTTP tunneling. Cette ligne est la suivante : RMISocketFactory.setSocketFactory( new sun.rmi.transport.proxy.rmihttptocgisocketfactory()) ; 3.5 Désavantages du HTTP tunneling HTTP est souvent considéré comme une mauvaise idée à cause des quatres raisons suivantes : Sécurité Le HTTP tunneling évite délibérément un mécanisme de sécurité qui a été mis en place par une autre personne qui le jugeait nécessaire. L inefficacité de la bande passante RMI est déjà à la base un protocole gourmand, il encode beaucoup d informations dans chaque message de requête. Donc prendre le message RMI et l insérer dans un envoi HTTP utilisera une plus grande largeur de bande. L inefficacité de la connexion HTTP tunneling ne peut pas créer une connexion puis la laisser ouverte et la réutiliser, il devra créer une nouvelle socket pour chaque requête qu il effectuera. La fragilité de l application L application entière est vulnérable à des changements dans la configuration du firewall ou du la topologie du réseau. 3.6 Configuration du fichier policy Chaque servlet est obligatoirement exécutée sous le contrôle d un gestionnaire de sécurité (Security Manager). Celui-ci s interpose entre la servlet et les ressources du système afin d empêcher toutes tentatives d accès illégales aux ressources du client. Les permissions d accès sont définies par la politique de sécurité (Security Policy) installée sur le poste de travail. Lorsque aucune politique de sécurité n est définie explicitement sur le client, le gestionnaire utilise alors la politique par défaut qui s appelle le bac à sable (Sandbox). Le bac à sable interdit aux servlets tout accès (lecture et écriture) aux ressources de la machine locale. Quand une servlet tente d accéder à une ressource du système, le gestionnaire de sécurité vérifie si le code exécuté a la permission d accéder à cette ressource en 12

13 consultant la politique de sécurité. Si la permission est accordée, tout se passe normalement. Dans le cas contraire, une exception est levée. Les fichiers «.policy» servent à paramétrer la politique de sécurité du système local. Un fichier «.policy» contient un ensemble de répertoires auxquels sont attribués individuellement un ensemble de permissions. Avant de lancer le serveur web il est important de noter que dans Java 2 (jdk1.2 et versions ultérieures) les politiques de sécurité appliquées par la JVM ne permettent pas du téléchargement du code sans permission explicite. Pour cela nous avons besoin, du côté client comme du côté serveur d'un fichier de politique de sécurité qu'on nommera java.policy et contenant les lignes suivantes : permission java.net.socketpermission "*: ","connect,accept"; permission java.net.socketpermission "*:80", "connect"; Le fichier «.policy» utilisé pour pouvoir effectuer un HTTP tunneling doit contenir une ligne de plus chez le client afin de lui permettre l utilisation de la «RMISocketFactory». Cette ligne est la suivante : permission java.lang.runtimepermission "setfactory"; 3.7 Exemple d appel RMI utilisant HTTP tunneling Le serveur Apache, Tomcat et le serveur RMI tourne sur la même machine (ip : ) à l intérieur du firewall. Afin de pouvoir effectuer un appel RMI à travers le firewall nous devons nous connecter au serveur Apache depuis une machine extérieur au firewall. Si l on a à disposition uniquement une machine à l intérieur du réseau local, on peut utiliser comme illustré dans la figure 3 un programme s appelant VNC qui permet de prendre le contrôle d une machine distante (dans ce cas nous prendrons le contrôle d une machine à l extérieur du firewall). Déroulement des étapes : Le client fait un appel RMI au serveur sous forme de requête HTTP grâce au socket factory utilisé. Un message de la forme /cgi-bin/javarmi.cgi?forward=[port number] sera envoyé au serveur Apache (dans le cas présent le port 80 sera utilisé car c est celui qui est à disposition par le firewall). Dans un premier temps une servlet (fonctionnant sur le serveur grâce à Tomcat) contrôlera la syntaxe de ce message. Puis l enverra sous forme HTTP POST au serveur RMI. Le serveur RMI la traitera et enverra au serveur Apache une réponse de type HttpServletResponse. Le servlet transmettra cette réponse au client sous la forme d une réponse HTTP à l aide de la socket factory utilisée. 13

14 Figure 3 : Déroulement d un appel RMI utilisant HTTP tunneling 14

15 4. RMIProxy Une seconde technique permettant le passage des appels RMI à travers un firewall est la méthode RMIProxy. Dans cette technique le client doit être configuré afin de pouvoir utiliser des sockets qui traversent le firewall. 4.1 Où trouve-t-on RMIProxy La version d évaluation de RMIProxy peut être téléchargé sur le site Les objectifs Les objectifs de RMI Proxy sont les suivants : 1. Eliminer les problèmes de sécurités de RMI à travers HTTP pour l administrateur réseau en fournissant des contrôles des exportations et des importations des services RMI, via une application firewall qui ne supporte uniquement le protocole RMI/JRMP. Aucune autre solution que RMIProxy existe. 2. Fournir une grande réduction des overhead dans le passage à travers un firewall comparé au HTTP tunneling. 3. Permettre un accès contrôlé vers le serveur RMI derrière le firewall. Aucune autre solution que RMIProxy existe. 4. Permettre un accès contrôlé des appels du côté client derrière un firewall. Aucune autre solution que RMIProxy existe. 5. Permettre au client RMI se trouvant derrière un firewall de contrôler l accès vers un serveur RMI de l autre côté du firewall. Les seules solutions existantes à ce problème sont les SOCKS et le HTTP tunneling. 6. Préserver toutes les propriétés de RMI. 7. Requérant un minimum de changement de code chez le client et le serveur RMI. 8. Reprendre le maximum d avantages existants dans les classes java, les packages, et la configuration et les dispositifs de sécurité. 4.3 Les caractéristiques RMI Proxy est une application Java et une API qui permet le contrôle de la pénétration dans un firewall en approuvant les clients et les serveurs RMI. 15

16 RMI Proxy fournit un protocole RMI intermédiaire qui remplace RMI/HTTP tunneling, avec un haut degré de contrôle d accès pour l administrateur réseau. RMI Proxy est capable de : bloquer l accès aux protocoles non-jrmp contrôler les écritures vers la RMI Proxy registry selon l identification de l hôte client. permettre ou refuser l accès et l exécution de méthodes distantes au client RMI, selon l identification de l hôte client. Permettre ou refuser le transfert de code par le service du codebase RMI, dans les deux directions. RMI Proxy fournit donc une grande réduction des overhead par rapport au HTTP tunneling. La durée de la connexion TCP est identique à une connexion RMI directe. L overhead découlant de tout RMI Proxy dans la chaîne de proxy est moindre qu une indirection RMI supplémentaire par proxy. RMI Proxy supporte entièrement : Les firewalls coté client Les firewalls coté serveur Les appels du client derrière le firewall client RMI Proxy préserve toutes les propriétés de RMI excepté l activation (les stubs activables sont séparés comme des stubs unicast), RMI/IIOP, et l exactitude des valeurs retournées par le RemoteServer.getClientHost. L utilisation de RMI Proxy nécessite uniquement un changement d utilisation de la classe Naming en ProxyNaming, et modifier les propriétés du rmi.proxyhost chez le client, le serveur et les proxy intermédiaires. RMI Proxy utilise le mécanisme Java de security-policy existant pour contrôler la configuration, et utilise la java.rmi.accessexception existante pour le rapport des erreurs. RMI Proxy est une solution 100% Java. Les composants firewall RMI Proxy implémentent une RMI registry standard. 4.4 Le contrôle d accès Le contrôle d accès est fournit par les fichiers Java policy, lesquels contrôlent la communication à travers les firewalls. Le contrôle d accès s effectuent selon l adresse IP ou le nom d un client voulant passé le firewall et selon l action que celui-ci veut effectuer, à l aide d une classe spéciale FirewallPermission. Le contrôle d accès est capable d être contre les actions suivantes : L accès à certains objets reçus ou envoyés implémentant l interface distant Bind, rebind ou unbind certains noms L exécution de certaines méthodes distantes Chercher certains noms dans la proxy registry 16

17 4.5 L architecture RMI Proxy comprend les composants importants suivants : 1. le programme RMI Proxy, lequel s exécute dans les proxy machines désignées 2. la classe ProxyNaming, une classe Naming modifiée, appelée par les clients et serveurs RMI. RMI Proxy comprend les sous-composants suivants : 1. Le Proxy Registry : une RMI Registry normale qui est soumise aux règles de contrôles d accès fournis par l implémentation du serveur RMIProxy. 2. Un protocole RMI qui négocie entre les flux descendants du serveur RMI et les flux montants du client RMI, effectuant la validation du protocole et le contrôle d accès dans le processus. Le système compte sur deux faits élémentaires de RMI : une référence distante peut seulement être obtenue par un paramètre ou le résultat d un appel de méthode distante, et la référence distante initiale est amorcée par un naming service (la RMI Registry). 4.6 Comment RMIProxy fonctionne Un serveur RMI derrière un firewall utilise le plus proche RMI Proxy afin d avoir son RMI Registry. Le coté extérieur du serveur RMI Proxy rend disponible un objet distant aux clients extérieurs. Pour le client RMI, une opération «lookup» sur un objet distant doit être dirigée vers le serveur proxy. Si le client est aussi lui-même derrière un firewall, le «lookup» est délégué à son RMI Proxy. La partie extérieure du proxy du client est capable de communiquer par RMI avec la partie extérieure du proxy serveur. Les proxies RMI servent d intermédiaires entre les entrées vers le serveur et les sorties du client. Ils effectuent la validation du protocole RMI et transmet les appels RMI de l un vers l autre. 17

18 Figure 4 : Exemple de configuration réseau RMI (tirée du guide de RMIProxy) Le RMI Proxy comprend trois composants : RMI proxy Registry un serveur RMI Proxying une API utilisée par les client et les serveurs Le RMI proxy Registry et les composants serveur sont installés en association avec chaque firewall qui existe entre le client RMI et le serveur RMI. Il peut y avoir un nombre quelconque de firewall. Chacun doit ouvrir son port au trafique RMI, lequel est ensuite manipulé d un manière sécurisée par le RMI proxy associé. La propriété système rmi.proxyhost, placée sur chaque hôte impliqué, dicte s il faut déléguer la requête du coté client (comme par exemple : lookup), ou s il faut la propager à la registry du coté serveur (par exemple : bind ou rebind), vers le prochain RMI Proxy dans la chaîne. Chaque RMI proxy a le droit de restreindre l accès à l aide d un fichier policy. Des Restrictions peuvent être imposées comme nous l avons vu plus haut par l adresse IP ou le nom de l hôte, par le nom du service distant, ou par l interface distant et les noms de méthodes. 4.7 L API coté client Quand un client RMI obtient une référence, il utilise normalement la méthode naming.lookup, avec un URL RMI de la forme : rmi://host/name où le host est le nom de l hôte sur lequel la RMI Registry tourne, et le name est le nom de l objet distant se trouvant dans la registry. 18

19 Dans l API de RMIProxy, le client utilise ProxyNaming à la place de Naming, Si un proxy est présent du coté client, les propriétés du système rmi.proxyhost spécifient son emplacement comme une URL RMI. Si cette propriété est présente, le client fonctionne dans un environnement RMI Proxy, donc le lookup est délégué au RMI Proxy, lequel est moins restrictif vers l extérieur que le client original. Si ce Proxy fonctionne avec un autre Proxy le lookup est redélégué et ainsi de suite jusqu au Proxy final atteint à l extérieur du firewall coté client, à ce point le Naming.lookup standard est exécuté, comme si aucun Proxy n avait été entre deux. Ce lookup, soit il réussi soit il échoue. Si il échoue, une exception RMI est propagé en retour vers le client original, et rien de remarquable se produit (l objet distant n a pas été trouvé). Si le lookup réussit, le stub obtenu (le flux descendant du stub) vérifie l accès au RMI Proxy. Cela peut encore échouer avec une java.rmi.accessexception ; autrement un stub se référant à l hôte RMI Proxy est retourné au client (le flux montant du stub). Le RMI Proxy maintient un lien entre le flux montant et descendant du stub, et transmet les appels RMI de l un à l autre, sujet du contrôle d accès. Du point de vue du client, l existence de RMI Proxy est invisible. Tout ce que le client sait, c est qu il a demandé un naming service (en utilisant ProxaNaming) pour une référence distante et qu il la obtenu ; le référence distante est du type expected, et le travail de la référence est de communiquer avec l objet distant. 4.8 L API côté serveur Un serveur RMI accessible par internet est lié avec la méthode ProxyNaming.bind à la place de Naming.bind ou Registry.bind, avec une URL RMI de la forme : rmi://host/name où host est le nom de l hôte sur lequel tourne la RMI Registry, et name est le nom de l objet distant dans cette registry. Avec les règles normales de RMI, un serveur RMI peut seulement être lié à un nom dans la RMI Registry par un processus tournant sur la même machine que la Registry. RMI Proxy modifie ces contraintes (le sujet du contrôle d accès pour le proxy). Les propriétés système rmi.proxhost nomment un hôte accessible où un RMI Proxy tourne. Si cette propriété est présente, la JVM tourne dans un environnement RMI Proxy, donc l opération ProxyNaming.bind est exécutée en même temps dans la registry locale et dans le RMI Proxy. Si il y a un autre proxy pour ce proxy, l opération est redéléguée et ainsi de suite jusqu à ce que le proxy final soit atteint. Dans l hôte original et dans chaque proxy incluant le dernier, le standard Naming.bind est exécuté par le ProxyNaming.bind. Ceci force le binding à se produire dans toutes les registry exécutées dans la chaîne des proxy. Le serveur est donc lié à la registry locale et aux registries de la chaîne des proxy. Une opération lookup de chaque proxy registries retourne un stub de flux montant se référant à un RMI Proxy, lequel transmet vers le stub de flux descendant après avoir effectué un contrôle d accès, exactement comme dans le cas de l API coté client, éventuellement en atteignant le serveur RMI original. 19

20 A l instar de l appel Naming.unbind ou Registry.unbind, un proxied RMI serveur est délié par ProxyNaming.unbind. Cette action d abord appelée Naming.unbind et ensuite délégué à la chaîne de proxy, entraîne unbinding de toutes les registries de la chaîne de proxy. De cette manière, chaque RMI serveur se lie vers une registry se trouvant dernière un ou plusieurs firewalls, et chaque serveur RMI accessible du serveur initial, sont rendus accessibles depuis internet, en étant rendus visibles par le plus proche RMI Proxy, et ainsi de suite récursivement. Un client RMI peut maintenant rechercher un serveur RMI à l extérieur du proxy côté serveur et obtenir un stub de flux descendant lequel finalement il se réfère, en passant par une chaîne de RMI Proxies, vers un serveur à l intérieur du firewall. Ce serveur n est donc pas directement accessible par le client. 4.9 Proxies multiple Si le client est derrière un ou plusieurs firewalls, ses propres RMI Proxies côté client feront leurs propre délégations, ainsi le client reçoit un stub qu il peut utiliser. Le dernier stub de flux montant pointe à l intérieur du proxy côté client, lequel pointe lui-même vers le suivant, lequel pointe éventuellement à l extérieur du proxy côté serveur, lequel pointe à l intérieur vers le suivant, lequel finalement point vers le serveur de flux descendant, comme illustré dans la figure 4. Figure 5 : multiples proxies côté client et serveur (tirée des «white paper» de RMIProxy) 20