Plan de l ’exposé

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

2. Plan de l ’exposé • Introduction • Problématique • HTTP tunneling • Comment RMI « tunnelle » des messages • Stratégie utilisée pour une invocation de méthode sur un serveur • Naming Services • L’implémentation d’un servlet pour le HTTP Tunneling • Modifications à apporter au code afin d’utiliser le HTTP Tunneling • Configuration du fichier policy • Exemple de requête RMI

3. Plan de l ’exposé (2) • RMI Proxy • Les objectifs • Les caractérisitiques • Le contrôle d’accès • L’architecture • Fonctionnement de RMI Proxy • L’API côté client et serveur • Limitations du RMI Proxy • Les modifications à apportées au client et au serveur • Les différences entre RMI Proxy et HTTP Tunneling • Conclusion

4. Introduction • RMI (Remote Method Invocation) • est un système distribué • une ou plusieurs applications peuvent s’exécuter sur une ou plusieurs machines • Aucun problème s’il n’y a aucun firewall entre les deux parties communiquantes

5. Problématique • Le problème principal lorsqu’un client veut effectuer un appel RMI sur une machine distante est le firewall. • Firewalls interdisent souvent l’accès à certains ports spécialisés comme ceux qu’on désire utiliser lors d’un appel RMI. • Solutiontechniques de tunneling, RMI Proxy ou encore d’autres peuvent être utilisées.

6. HTTP Tunneling • Principe de baseUtiliser comme protocole de communication des appelles http à travers le Web • Évite les firewalls en utilisant le port HTTP (80), celui-ci n’est en général pas boqué par le firewall et le firewall ne peut pas prendre de décisions en fonction du contenu des paquets. • PrincipeLe client utilise une couche supplémentaire (marshalling layer) qui encode la requête RMI du client en une requête HTTP valide.Le serveur de l’autre coté comprend 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 (dans ce cas un requête RMI).

7. HTTP Tunneling (2) • Le HTTP tunneling est divisé en trois parties : • Le Client Envoie une requête au serveur web • Le servletTransmet la requête à la socket du serveur RMI en préservant la structure HTTP qui a été envoyée par le client • Le serveurTransforme automatiquement l’envoi HTTP en une commande JRMP

8. HTTP Tunneling (3)

9. Comment RMI « tunnelle » des messages • But du mécanisme de RMI’s HTTP tunneling : encode un appel de méthode à distance à la façon d ’une requête POST et ensuite décode la « page web » retournée. • RMI utilise son propre mode de socket (RMIHttpToCGISocketFactory()) quand des connections sont créées. • Ces sockets tentent d’utiliser HTTP tunneling si auparavant elles ont reçu une erreur du serveur.

10. Stratégie utilisée pour une invocation de méthode sur un serveur • Tentent d’établir une connexion JRMP (Java Remote Method Invocation) directe vers le serveur. • é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.

11. Stratégie utilisée pour une invocation de méthode sur un serveur (2) • Utilise 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). • Se connecte 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. • Chaqu’un de ces points a son sens, la connexion est établie selon les privilèges que le firewall accorde.

12. Naming Services • La machine serveur dans la quatrième option est une abstraction, elle n’a pas besoin d’être sur la même machine que l’objet serveur RMI. Permet donc plus de flexibilité au HTTP Tunneling. • Pour ce faire nous devons écrire un servlet qui effectue la redirection de la requête RMI vers le serveur RMI, ensuite le serveur web est configuré pour envoyer toutes les requêtes avec l’URL approprié.

13. Naming Services (2)

14. L’implémentation d’un servlet pour le HTTP Tunneling • La première implémentation, qui permet de transmettre l’invocation de méthodes au serveur RMI, que Sun Microsystems, Inc. Développa était un script CGI (java-rmi.cgi) • 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 convertit en une chaîne de caractères ASCII. • Sun créa ensuite un servlet qui fournit les mêmes fonctionnalités que le script CGI.

15. Le code du servlet • Deux classes principales SimplifiedServletHandler et ServletForwardCommand • SimplifiedServletHandlerCette classe étend HTTPServlet. Elles reçoit les requêtes et effectue un validation préliminaire. • ServletForwardCommandC’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.

16. Le code du servlet (2) • Explication d’une partie de code de SimplifiedServletHandler • Des testes sont effectués afin de contrôlé la validité de l’URL et présence du port, la requête est ensuite transmise à la méthode statique execute() • 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); }

17. Le code du servlet (3) • Explication d’une partie du code de ServletForwardCommand • on utilise des sockets pour transmettre le corps du message HTTP au serveur RMI et ensuite des simples « pipes » que le serveur RMI pour retourner des sortis de type HttpServletResponse (response). • ServletForwardCommand transmet le message sans décoder les données ou comprendre le message • 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(); • OutputStream out = response.getOutputStream();out.write(buffer);out.flush();

18. Modifications à apporter au code afin d’utiliser le HTTP Tunneling • La socket RMI par défaut tentera automatiquement d’utiliser le HTTP tunneling quand les autres connexions auront échouées. • On ne change ni le code du serveur ni le code du client, on ajoute simplement un ligne dans le code du client afin qu’il puisse utiliser le HTTP tunneling.RMISocketFactory.setSocketFactory(new sun.rmi.transport.proxy.RMIHttpTOCGISocketFactory()) ;

19. Configuration du fichier policy • Chaque servlet est obligatoirement exécutée sous le contrôle d’un gestionnaire de sécurité. • Les politiques de sécurité appliquées par la JVM ne permettent pas du téléchargement de code sans permission explicite. Donc dans le fichier policiy du client et du serveur les permissions suivantes doivent être ajoutées : • permission java.net.SocketPermission "*:1024-65535","connect,accept"; • permission java.net.SocketPermission "*:80", "connect"; • Chez le client il y a encore une permission de plus affin que celui-ci puisse utiliser la « RMISocketFactory » : • permission java.lang.RuntimePermission "setFactory";

20. Exemple de requête RMI

21. Seconde technique RMI Proxy

22. Les objectifs • Eliminer les problèmes de sécurités de RMI à travers HTTP pour l’administrateur réseau, via une application firewall qui ne supporte uniquement le protocole RMI/JRMP. • Réduction des overhead comparé au HTTP tunneling lors du passage à travers un firewall. • Permettre un accès contrôlé des appels du coté client derrière un firewall. • Préserver toutes les propriétés de RMI • Requérir un minimum de modifications de code chez le client et le serveur RMI • Reprendre le maximum d’avantages existants dans les classes java.

23. Les caractéristiques • RMI Proxy est une application Java et une API permettant le contrôle de la pénétration dans un firewall en approuvant les clients et les serveurs RMI. • 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’identificateur de l’hôte client. • Permettre ou refuser le transfert de code par le service du codebase RMI, dans les deux directions

24. Le contrôle d’accès • Il est fournit par les fichiers Java policy, lesquels contrôle la communication à travers les firewalls. • Le contrôle d’accès s’effectue selon l’adresse IP ou le nom du client voulant passer le firewall et de l’action qu’il veut effectuer. Classe spécialisée : « FirewallPermission » • Le contrôle est capable d’être contre les actions suivantes : • L’accès à certain objet • Bind, rebind ou unbind certain nom • L’exécution de certaines méthodes distantes • Chercher certains noms dans la proxy registry

25. L’architecture • Composants importants : • Le programme RMI Proxy, lequel s’exécute dans les machines proxy désignées. • La classe ProxyNaming, une classe Naming modifiée, appelée par les clients et serveurs RMI. • Sous-composants • La proxy registry • RMI registry normale qui est soumise aux règles de contrôles d’accès fournis par l’implémentation du serveur RMIProxy • Un protocole RMI • 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

26. 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érieur du proxy du client est capable de communiquer par RMI avec la partie extérieur du proxy serveur. Les proxies RMI servent d’intermédiaires entre les entrés vers le serveur et les sorties du client. Fonctionnement de RMI Proxy

27. 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. Chacun doit ouvrir un port au trafique RMI, lequel est ensuite manipulé d’un manière sécurisée par le RMI proxy associé. RMI Proxy (2)

28. L’API côté client et serveur • Le client est derrière plusieurs firewall -> délègue le lookup au proxy final coté client (grace à la propriété rmi.proxyHost) puis un stub est obtenu. • Le serveur exécute un bind dans la chaîne de registry des proxy en déléguant le bind. Il est donc lié à la registry locale et aux registry de toute la chaîne des proxy

29. Limitations du RMI Proxy • Activation • L’implémentation actuelle réécrit les stubs activables comme des stubs unicast normaux • Stubs cachés • N’effectue pas d’arrangement proxying pour les stubs cachés (Stubs à l’intérieur de MarshalledObjects) • Socket Factories • Socket factories ne sont actuellement pas supportées • GetClientHost • RmoteServer.getClientHost retourne l’InetAddress du RMI Proxy le plus proche et non le vrai client RMI • RMI/IIOP (Internet Inter-Orb Protocol) • Ne supporte pas les stubs RMI/IIOP • Stubs distants indirectes • Petite modification nécessaire dans la classe sun.rmi.MarshalOutputStream pour traiter les stubs distants indirectes

30. Les modifications à apportées au client et au serveur • Du coté serveur la classe com.rmiproxy.ProxyNaming doit être utilisée à la place de la classe java.rmi.Naming. • Exemple de code :ProxyNaming.bind(« rmi://localhost/ » + RemoteEcho.class.getName()) ; • Du coté client le même principe doit être utilisé on remplace la classe java.rmi.Naming par la classe com.rmiproxy.ProxyNaming. • Exemple de code :RemoteEcho echoObject = (RemoteEcho)ProxyNaming.lookup(« rmi://rmi.server.com/ »+RemoteEcho.class.getName()) ; • Définir les propriétés du système rmi.proxyHost • Exemple : Rmi.proxyHost=rmi://proxy.clientlan0.client.com • Configurer le fichier policy du client et du serveur. • Installer ProxyBoot.jar, ProxyMain.jar et RMIProxy.policy sur chaque machine proxy.

31. HTTP tunneling RMI Proxy Il n’est pas très fiable. Si on modifie le firewall il est possible que le tunneling ne fonctionne plus. Plus robuste au changement du firewall. Ces performances sont faibles.Il encode beaucoup d’informations dans chaque message de requête. Il doit créer une nouvelle socket pour chaque requête qu’il effectue. Les requêtes sont des requêtes RMI sans information supplémentaire. Il ne fonctionne pas à travers tous les types de firewall. Fonctionne avec tout type de firewall. Inefficacité de la connexion, il ne peut pas créer un connexion et la laisser ouverte pour pouvoir la réutiliser, il doit créer une nouvelle socket pour chaque requête qu’il effectue. Connexion ne se referme pas après chaque requête. Les différences entre RMI Proxy et HTTP Tunneling

32. 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.

33. QUESTION?