L’e-business B to B pose un problème à l’informatique distribuée : celui de la sécurisation des échanges interapplicatifs sur Internet. Il convenait donc que les éditeurs de middlewares incorporent à leurs solutions des mécanismes d’authentification et de cryptage, adaptés aux contraintes de l’e-commerce et aux relations interentreprises. Que l’on parle des middlewares transactionnels, procéduraux (les moniteurs transactionnels) et objets (ORB, Object request broker), ou que l’on évoque les messageries interapplicatives de type MOM (Message oriented middleware) et les middlewares qui en dérivent (les Message brokers et les middlewares EAI, Enterprise application integration), toutes ces solutions d’infrastructures sont, depuis longtemps, exploitées pour les développements distribués d’entreprise. Restait cependant à en étendre la portée à Internet, et à garantir leur capacité à sécuriser les échanges à travers le Web.De nombreux efforts technologiques ont été, ou viennent d’être, entrepris en la matière. Ils ont souvent conduit les éditeurs à incorporer des mécanismes de protection SSL au sein même de leurs middlewares.
Des flux IIOP encapsulés au sein de SSL Corba Security
L’adoption de SSL a largement affecté les middlewares transactionnels de type ORB. L’architecture des ORB ?” que l’on peut définir comme un bus régissant les échanges transactionnels au sein d’applications distribuées orientées objets ?” est généralement régie par le modèle architectural Corba (Common object request broker architecture), défini par l’OMG (Object management group). Originellement, Corba ne prenait pas en compte la sécurité Internet. Corba n’a pu faire son entrée sur la scène de l’e-business que depuis 1997, en raison de deux évolutions : la définition d’un mécanisme d’interopérabilité, IIOP (Internet inter-ORB protocol) ; et le rajout de l’extension SSL Corba Security. IIOP constitue désormais la fondation sur laquelle les ORB s’appuient pour communiquer de façon standardisée via Internet, tandis que SSL Corba Security spécifie la façon d’encapsuler les flux IIOP dans une couche de transport protégée en SSL. Nombreuses ont été les applications à exploiter cette extension sécurisée de Corba.Dans la communauté du logiciel libre, on comptera sur les versions préliminaires d’OpenORB, qui est un projet d’ORB Open Source incorporant ses propres services de sécurité compatibles Corba, grâce à SSLIOP extension for OpenORB.Quant aux éditeurs commerciaux de middlewares Corba, ils exploitent systématiquement les services SSL. Parmi les plus connus, Iona (dont l’ORB Orbix a été complété par l’extension OrbixSSL) permet à des infrastructures applicatives construites sur Orbix d’utiliser une couche de transport sécurisée en SSL. Citons aussi Borland, dont l’ORB Visigenic s’appuie sur les composants VisiBroker SSL Pack pour C++ et Java, afin d’établir des dialogues IIOP sécurisés entre serveurs et clients Visigenic.Cette nécessaire évolution vers la sécurité e-business a naturellement touché les éditeurs de middlewares asynchrones de type messageries interapplicatives, ces solutions jouant le rôle de “tuyauteries” des plates-formes d’intégration e-commerce.IBM et Microsoft, éditeurs respectifs de MQSeries ?” le leader du marché ?” et du challenger MSMQ ?” Microsoft Message Queuing intégré dans Windows 2000 Data Center ?”, n’ont pas été épargnés par cette ouverture au commerce électronique. IBM avait déjà doté les MQSeries de mécanismes d’encryptage propriétaires tels que ceux fournis par MQSeries Everyplace, utilisé pour connecter des postes mobiles à des sites d’entreprise. E-business oblige, MQSeries Everyplace a été complété par une extension au nom évocateur de MQSeries Internet Pass Through (MQIPT). Grâce à ses protections SSL, elle autorise des canaux de communication MQSeries sécurisés. Quant à MSMQ, de Microsoft, il est en mesure, depuis son portage en version 3, de véhiculer des messages MSMQ via des échanges HTTP. Ce qui, a priori, l’autorise aussi à s’appuyer sur HTTPS, la version sécurisée SSL de HTTP.La sécurisation des échanges e-business a directement profité d’évolutions récemment apportées aux outils de développement Java. La sécurité Java est, d’ailleurs, devenue la spécialité de certains éditeurs, tel Phaos, dont le kit de développement SSLava permet aux applications Java compatibles Corba-IIOP, LDAP, JDBC, etc. de supporter les échanges HTTPS.Mais ce n’est finalement qu’avec certaines améliorations apportées par SunSoft à ses kits de développement Java 2 qu’un progrès décisif a été accompli. SunSoft avait déjà facilité l’émergence d’une offre middleware Java de type messagerie applicative, en complétant ses kits Java de l’extension JMS (Java message services). Mais, alors que JMS propose des fonctions génériques de création, envoi, réception, etc. de messages applicatifs, ils ne répondent en rien aux besoins de sécurisation des contenus. Il revenait donc aux éditeurs de middlewares Java de développer des mécanismes d’authentification et d’encryptage, en s’appuyant sur leur expertise propre ou en faisant, éventuellement, appel à d’autres technologies SunSoft. De fait, ce dernier s’était aussi intéressé à la sécurité SSL, ce qui l’avait conduit à développer les services JSSE (Java secure socket extension).
Les outils Java supportent SSL
Originellement fournis en tant que composants à part entière, les JSSE sont en passe d’être intégrés dans la version 1.4 du kit de développement Java 2 Enterprise Edition. Ils constitueront pour les développeurs un moyen standardisé de sécuriser leurs applications TCP-IP. Avec JSSE, SunSoft prétend affranchir les développeurs d’applets Java des contraintes de natures propriétaire et fonctionnelle qu’implique l’usage des fonctions SSL standards des navigateurs Web commerciaux. Entre autres finalités, JSSE permet donc à des applets Java d’établir des connexions IIOP sécurisées avec des serveurs d’applications Web.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
