WO2003005670A1 - Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur - Google Patents

Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur Download PDF

Info

Publication number
WO2003005670A1
WO2003005670A1 PCT/FR2002/002275 FR0202275W WO03005670A1 WO 2003005670 A1 WO2003005670 A1 WO 2003005670A1 FR 0202275 W FR0202275 W FR 0202275W WO 03005670 A1 WO03005670 A1 WO 03005670A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
hyperserver
applications
transfer
ftp
Prior art date
Application number
PCT/FR2002/002275
Other languages
English (en)
Inventor
Elzbieta Cochard Plociennik
Original Assignee
Elzbieta Cochard Plociennik
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Elzbieta Cochard Plociennik filed Critical Elzbieta Cochard Plociennik
Priority to US10/482,667 priority Critical patent/US7440959B2/en
Priority to EP02764936A priority patent/EP1407594A1/fr
Publication of WO2003005670A1 publication Critical patent/WO2003005670A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation

Definitions

  • the present invention relates to a method for controlling data exchanges between two applications, respectively of client type and of server type, according to a protocol of FTP type of TCP / IP (RFC 959 1579) or the like, it being understood that:
  • TCP Transmission Control Protocol
  • Internet Protocol Internet Protocol
  • FTP File Transfer Protocol
  • TCP / IP file transfer protocol used both on the Internet and on corporate Intranet TCP / IP networks whose network protocol is TCP / IP
  • - RFC Request for comments
  • TCP / IP protocols TCP / IP protocols
  • the server and client applications are specific to the FTP protocol or have the capacity to generate a data stream compatible with this protocol.
  • the invention relates more particularly, but not exclusively, to a method implementing a hyperserver application which runs on a host platform and which acts as an intermediary between two applications, one of which is of the FTP type while the other is either an FTP type application, or a compatible application, to conduct the protocol transfer negotiations as well as the data transfers themselves.
  • the Hyperserver application is endowed with means enabling it to have visibility and the ability to interpret and translate the information exchanged. This position of the Hyperserveur application allows it, not only to follow exchanges passively, but also to control them by interfering in these exchanges according to control rules, which will be imposed and defined in its directory databases partner applications and transfer profiles.
  • the method according to the invention can include agent applications on the execution platforms of applications of FTP type (or compatible).
  • FTP type or compatible
  • all or only part of the population of FTP (or compatible) applications can be fully controlled. This population (or part of the population) will be called hereinafter "controlled population”.
  • All applications of the FTP (or compatible) type that do not benefit from the control of the Hyperserver application are referred to as the unmarked population in the rest of this presentation.
  • the two populations can be part of the same IP network or belong to two different networks and, in the second case, the Hyperserver application must reside in the network of the controlled population and be accessible by the applications of the unmarked population.
  • the method according to the invention makes it possible to carry out transfers while ensuring the security and confidentiality of the data hosted in the Intranet network. It also provides the functionality of a powerful centralized execution monitor for exchanging files or other transferable objects.
  • FTP-type applications (or compatible) of the Intranet network constitute in this case the controlled population and the Internet partners play the role of the unmarked population.
  • the security and confidentiality of the entire intranet can be preserved by the method according to the invention since the names of the hosts on this network, the directories of files (or other transferable objects) and their physical names can remain invisible to external partners of the Intranet network.
  • external partners need only know the identifiers of the entries in the transfer profile database files and connection profiles, defined below and, among these identifiers, only those accessible to the identified and authenticated requester.
  • the Hyperserver application is an intermediate application that has visibility and complete control of all the protocol negotiation data and files (or other transferable objects) exchanged by the applications that communicate with each other. Therefore, and regardless of the execution environment, the Hyperserver application has all the information necessary to ensure the functions of a monitor such as monitoring, statistics and interactions with operators or other applications.
  • the method according to the invention can implement
  • the controlled population of hosts with that hosting the Hyperserveur application can be a set of computers and files of a company constituting an Intranet network.
  • the BDP profile database for file transfers with FTP or compatible applications constitutes the file access system for the hyperserver application under the FTP model.
  • the unmarked population can be, in this case, all the computers accessing via the Internet network the Hyperserver application to transfer files with the hosts of the company under its control.
  • the BDH database contains all the information necessary for the Hyperserver application to:
  • the BDP database defines the profiles and scenarios for file transfers or other transferable objects using the following attributes, including:
  • Agent applications provided with a communication interface with the Hyperserver application can retrieve information concerning file transfers from their place of execution and / or receive from the Hyperserver application an order to launch the processes under their own control. at the start or end of these transfers.
  • the databases BDH and BDP can constitute the local directories of LDAP type ("Lightweight Directory Access Protocol") of the network of the controlled population.
  • LDAP Lightweight Directory Access Protocol
  • LDAP is an open and widely distributed protocol that allows access to these directories without additional development for applications running in a highly heterogeneous environment.
  • the following presentation describes the procedures for file transfer operations in the Intranet / Internet environment where the Hyperserver application tracks and "monitors" file transfers on the Intranet side. None prevents us from imagining another hyperserver application located on the Internet network generating the flow compatible with FTP and controlling file transfers of its host population.
  • the FTP type application of the requesting client on the Internet side opens, thanks to a set of connection opening commands, the connection with the hyperserver application by specifying its user name, password and possibly its authentication data as with a conventional FTP server,
  • the information exchanged during this phase of negotiation with the FTP client may be sufficient to determine the entry in this directory defining the connection attributes with the targeted application on the intranet side (otherwise , an additional command, for example FTP SITE, can be used to identify it), - the correlation between the requesting client and the target server allows the Hyperserver application to search the BDH database for all information concerning the access rights of the requester, the possible encryption and its keys, as well as the possible negotiation protocol and the modalities of the connection with the targeted server, - as soon as the protocol and the modalities of connection are known, the Hyperserver application can open the connection with the intended destination application and initiate the exchange of commands, if any, provided for in the protocol,
  • the definition of the determined profile allows the Hyperserver application to verify the direction of transfer, to identify the file to be transferred, its attributes, the possible processes to be executed at the start, during and at the end of the transfer as well as the designation of applications under whose control their execution must take place,
  • the Hyperserveur application will be able to fulfill the transfer request received from the customer, - two "DATA" connections in the FTP sense will be opened: one, between the FTP client and the hyperserver application and the other between the hyperserver application and the targeted application; the data received by the Hyperserver application on one connection will be sent to the other, possibly undergoing the processing of the process "during the transfer",
  • Direct Transfer Request a device of the method according to the invention, called "Direct Transfer Request”.
  • the request must contain all the information necessary to determine both the entry of the BDH directory and that of BDP,
  • the Hyperserver application will initialize, as a client, two connections: one with the FTP type server (or a compatible application) on the intranet side and one with the FTP type server Internet side,
  • the Hyperserveur application will route the data in the file, from its origin to its destination through two DATA type connections in the sense FTP or compatible between themselves and two server applications,
  • the Hyperserver application will allow the Hyperserver application to determine the file names on both sides and all the attributes of the transfer as well as the processes to be triggered at the start, during and at the end of the transfer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

Le procédé selon l'invention assure le contrôle des échanges de fichiers ou autres objets transférables entre deux applications, respectivement de type client et de type serveur, selon un protocole de type FTP de TCP/IP ou analogue, l'une des deux applications étant de type FTP, tandis que l'autre est soit une application de type FTP, soit une application compatible. Il met en oeuvre une application Hyperserveur qui s'exécute sur une plateforme hôte et joue le rôle d'intermédiaire entre les deux applications dans des négociations protocolaires de transferts ainsi que dans des transferts de fichiers ou autres objets transférables eux-mêmes.

Description

PROCEDE POUR LE CONTROLE D'ECHANGES DE DONNEES ENTRE DEUX APPLICATIONS. RESPECTIVEMENT DE TYPE CLIENT ET DE TYPE SERVEUR.
La présente invention concerne un procédé pour le contrôle d'échanges de données entre deux applications, respectivement de type client et de type serveur, selon un protocole de type FTP de TCP/IP (RFC 959 1579) ou analogue, étant entendu que :
- TCP/IP ("Transmission Control Protocol") / ("Internet Protocol") est un ensemble de protocoles de transmission utilisé sur le réseau Internet,
- FTP ("File Transfert Protocol") est un protocole de transfert de fichiers de TCP/IP utilisé aussi bien sur Internet que sur des réseaux TCP/IP d'entreprise Intranet dont le protocole de réseau est TCP/IP, - RFC ("Request for comments") est une nomination des protocoles TCP/IP,
- les applications serveur et client sont spécifiques du protocole FTP ou ont la capacité de générer un flux de données compatibles avec ce protocole.
L'invention a plus particulièrement pour objet, mais non exclusivement, un procédé mettant en œuvre une application Hyperserveur qui s'exécute sur une plateforme hôte et qui joue le rôle d'intermédiaire entre deux applications dont l'une est de type FTP tandis que l'autre est soit une application de type FTP, soit une application compatible, pour conduire les négociations protocolaires de transferts ainsi que les transferts de données elles-mêmes. Indépendamment de l'environnement d'exécution de ces applications, l'application Hyperserveur est dotée de moyens lui permettant d'avoir la visibilité et la faculté d'une interprétation et d'une traduction des informations échangées. Cette position de l'application Hyperserveur lui permet, non seulement de suivre les échanges de façon passive, mais aussi de les contrôler en interférant dans ces échanges en fonction des règles de contrôle, qui lui seront imposées et définies dans ses bases de données des annuaires des applications-partenaires et des profils de transfert.
Pour renforcer et élargir ces capacités de suivi et de contrôle au-delà de sa propre plateforme d'exécution, le procédé selon l'invention peut comprendre des applications agents sur les plateformes d'exécution des applications de type FTP (ou compatibles). En fonction des règles de contrôle et du déploiement des applications agents, tout ou seulement une partie de la population des applications de type FTP (ou compatible) peut être pleinement contrôlée. Cette population (ou partie de population) sera appelée ci-après "population contrôlée". L'ensemble des applications de type FTP (ou compatible) ne bénéficiant pas du contrôle de l'application Hyperserveur est dénommé population banalisée dans la suite de cette présentation. Les deux populations peuvent faire partie d'un même réseau IP ou appartenir à deux réseaux différents et, dans le deuxième cas, l'application Hyperserveur devra résider dans le réseau de la population contrôlée et être accessible par les applications de la population banalisée.
S'exécutant sur un hôte Intranet et étant le point de passage unique et obligatoire dans les échanges Intra/Internet, le procédé selon l'invention permet d'effectuer les transferts en assurant la sécurité et la confidentialité des données abritées dans le réseau Intranet. Il assure par ailleurs les fonctionnalités d'un puissant moniteur d'exécution centralisé d'échanges de fichiers ou autres objets transférables. Les applications de type FTP (ou compatibles) du réseau Intranet constituent dans ce cas-là la population contrôlée et les partenaires Internet jouent le rôle de la population banalisée.
Dans cet environnement, la sécurité et la confidentialité de l'ensemble du réseau Intranet peuvent être préservées par le procédé selon l'invention puisque les noms des hôtes de ce réseau, les annuaires de fichiers (ou autres objets transférables) et leurs noms physiques peuvent rester invisibles pour les partenaires extérieurs du réseau Intranet. En fonction des règles d'attribution de noms physiques des fichiers (objets transférables) et des hôtes serveurs de type FTP ou compatibles FTP, les partenaires extérieurs n'ont besoin de connaître que les identificateurs des entrées de la base de données des profils de transfert de fichiers et des profils de connexion, définie ci-dessous et, parmi ces identificateurs, seulement ceux accessibles au demandeur identifié et authentifié.
L'application Hyperserveur est une application intermédiaire qui a la visibilité et le contrôle complet de toutes les données de négociations protocolaires et des fichiers (ou autres objets transférables) échangées par les applications qui communiquent entre-elles. De ce fait, et indépendamment de l' environnement de son exécution, l'application Hyperserveur a toutes les informations nécessaires pour assurer les fonctions d'un moniteur telles que le suivi, les statistiques et les interactions avec des opérateurs ou d'autres applications.
D'une façon plus précise, le procédé selon invention pourra mettre en œuvre
- une population banalisée des hôtes résidant dans un réseau IP ayant accès à l'application Hyperserveur et hébergeant :
- des applications de type FTP ou capables de générer un flux de données compatibles avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications, - une application Hyperserveur s'exécutant sur un hôte ayant accès aux applications de type FTP ou compatibles mentionnées ci-dessus et disposant de :
- une base de données d'annuaire des hôtes contrôlés et banalisés désignant les applications communicantes avec leurs adresses IP et des listes des utilisateurs autorisés à y accéder ainsi que les attributs d'autorisation, si nécessaire (BDH),
- une base de données d'annuaire des profils de transfert de fichiers ou autres objets transférables (BDP), - un fichier "LOG" central de l'application Hyperserveur (LGH), contenant les enregistrements de suivi de transferts,
- un fichier journal central de l'application Hyperserveur (JRH), contenant les enregistrements récapitulatifs des transferts,
- une population contrôlée d'hôtes résidant dans un réseau IP et hébergeant : - des applications de type FTP ou capables de générer un flux de données compatible avec le protocole FTP,
- des fichiers ou autres objets transférables identifiables et visibles pour ces applications,
- des applications agents de l'application Hyperserveur disposant éventuellement de leurs propres fichiers "LOG" et journal.
Il convient de noter que la population contrôlée des hôtes avec celui hébergeant l'application Hyperserveur peut être un ensemble d'ordinateurs et de fichiers d'une entreprise constituant un réseau Intranet. La base BDP de profil des transferts de fichiers avec les applications FTP ou compatibles constituent pour l'application hyperserveur le système d'accès aux fichiers aux termes du modèle de FTP. La population banalisée peut être, dans ce cas-là, l'ensemble des ordinateurs accédant via le réseau Internet à l'application Hyperserveur pour transférer des fichiers avec les hôtes de l'entreprise sous son contrôle. La base de données BDH contient toutes les informations nécessaires à l'application Hyperserveur pour :
- identifier et/ou authentifier chaque demandeur de transfert, - identifier et/ou accéder à l'application destinatrice en respectant ses règles d'authentifications,
- déteπniner éventuellement les règles de cryptage à utiliser en fonction des demandeurs et des destinataires identifiés,
- identifier et localiser l'application agent de l'application Hyperserveur assignée pour la partie de la connexion dans l'environnement contrôlé,
- identifier éventuellement les processus à exécuter au début et/ou à la fin de la connexion, etc.
La base de données BDP définit les profils et scénarios des transferts de fichiers ou autres objets transférables à l'aide des attributs suivants, notamment :
- l'emplacement des fichiers ou autres objets à émettre ou recevoir, et/ou
- leur nom ou leur méthode de dénomination, et/ou - leur méthode d'accès, et/ou le type de données et/ou le code,
et, éventuellement :
- les processus et scénarios à exécuter au début et/ou pendant et/ou à la fin des transferts et/ou leur lieu d'exécution, et/ou
- les critères et attributs d'autorisation d'accès au fichier ou objets à transférer.
Il est à noter que, à part des applications de type FTP qui sont les partenaires des échanges, la seule application ayant accès aux données de fichiers (autre objet) transférés est l'application Hyperserveur. Cette capacité lui permet d'agir éventuellement sur ces données en exécutant des processus en cours de transfert.
La mise en place d'un agent de l'application Hyperserveur sur chaque hôte de la population contrôlée permet d'effectuer un suivi local des transferts des fichiers. Les applications agents pourvues d'une interface de communication avec l'application Hyperserveur peuvent récupérer les informations concernant les transferts de fichiers de leur lieu d'exécution et/ou de recevoir de l'application Hyperserveur un ordre de lancer sous leur propre contrôle les processus en début ou en fin de ces transferts.
Dans une version préférée de l'invention, les bases de données BDH et BDP peuvent constituer les annuaires locaux de type LDAP ("Lightweight Directory Access Protocol") du réseau de la population contrôlée. LDAP est un protocole ouvert et largement diffusé qui permet d'accéder à ces annuaires sans un développement supplémentaire pour les applications s'exécutant dans un environnement fortement hétérogène.
A titre d'exemple, la présentation qui suit décrit les déroulements des opérations de transfert de fichiers dans l'environnement Intranet/Internet où l'application Hyperserveur assure le suivi et le "monitoring" des transferts de fichiers côté Intranet. Rien n'empêche par ailleurs d'imaginer une autre application Hyperserveur située sur le réseau Internet générant le flux compatible à FTP et contrôlant des transferts de fichiers de sa population d'hôtes.
Dans cet environnement, le déroulement des opérations lors d'une demande de transfert à partir du réseau Internet est le suivant :
- l'application de type FTP du client demandeur côté Internet ouvre, grâce à un jeu de commandes d'ouverture de connexion, la connexion avec l'application Hyperserveur en spécifiant son nom d'utilisateur, son mot de passe et éventuellement ses données d'authentifîcation comme avec un serveur FTP classique,
- en fonction de règles définies dans l'annuaire BDH, les informations échangées pendant cette phase de la négociation avec le client FTP peuvent être suffisantes pour déterminer l'entrée de cet annuaire définissant les attributs de connexion avec l'application visée côté Intranet (sinon, une commande supplémentaire, par exemple SITE de FTP, peut être utilisée pour l'identifier), - la corrélation entre le client demandeur et le serveur visé permet à l'application Hyperserveur de rechercher dans la base de données BDH toutes les informations concernant les droits d'accès du demandeur, le cryptage éventuel et ses clés, ainsi que le protocole éventuel de négociation et les modalités de la connexion avec le serveur visé, - dès que le protocole et les modalités de connexion sont connus, l'application Hyperserveur peut ouvrir la connexion avec l'application destinatrice visée et entamer l'échange de commandes éventuellement prévues par le protocole,
- la poursuite de la négociation et le contenu d'une des commandes de transfert FTP du type "store", "store unique", "retrive" etc.. reçu par l'application Hyperserveur doivent lui permettre d'identifier un profil de transfert de fichier ou d'autres objets transférables qui constitue une entrée dans l'annuaire BDP,
- la définition du profil déterminé permet à l'application Hyperserveur de vérifier le sens de transfert, d'identifier le fichier à transférer, ses attributs, les processus éventuels à exécuter au début, pendant et à la fin du transfert ainsi que la désignation des applications sous contrôle desquelles leurs exécutions doivent avoir lieu,
- qu'ayant achevé les éventuelles négociations de transfert induites par le profil de transfert avec l'application visée, l'application Hyperserveur pourra acquitter la demande du transfert reçu du client, - deux connexions "DATA" au sens FTP seront ouvertes : une, entre client FTP et application Hyperserveur et l'autre entre l'application Hyperserveur et l'application visée ; les données reçues par l'application Hyperserveur sur une connexion seront envoyées sur l'autre en subissant éventuellement le traitement du processus "pendant le transfert",
- l'exécution des éventuels processus au début et/ou à la fin du transfert s'effectuera sous le contrôle de l'agent de l'application Hyperserveur de l'hôte de l'application visée en synchronisme avec le dialogue entre cette application et l'application Hyperserveur à l'ordre de ce dernier, - les enregistrements LOG (fichiers dans lesquels sont enregistrés tous les événements des connexions, des négociations et des transferts) et journal (fichier de statistiques) générés par l'application Hyperserveur seront effectués dans des fichiers LGH et JRH et leurs copies seront envoyées vers l'agent de l'application Hyperserveur concerné pour être mises dans les fichiers "LOG" et journal locaux.
Dans le cas où une demande de transfert provient d'un hôte du réseau Intranet donc de la population contrôlée, le déroulement de la procédure de transfert peut s'effectuer de manière symétrique. On sait cependant que la négociation d'un transfert entre l'application client et l'application serveur FTP ne laisse pas passer au serveur le nom de fichier à transmettre utilisé côté client. Lorsque la demande provient donc dune application client FTP côté Intranet, cette particularité du protocole FTP réduit les possibilités de supervision des échanges de fichiers qui peuvent être demandées à l'application Hyperserveur, puisqu'il ne dispose d'aucune information concernant le fichier (ou l'objet à transmettre) de son propre domaine de contrôle.
Il est préférable, dans ce cas, d'utiliser un dispositif du procédé selon l'invention, dénommé "Demande Directe de Transfert". Dans ce fonctionnement, lorsqu'une Demande Directe de Transfert est déposée par un utilisateur auprès de l'application Hyperserveur, le déroulement des opérations est le suivant :
- la demande doit contenir toutes les informations nécessaires pour déterminer aussi bien l'entrée de l'annuaire BDH que celui de BDP,
- en utilisant les informations trouvées dans l'entrée BDH déterminée, l'application Hyperserveur initialisera, en tant que client, deux connexions : une avec le serveur de type FTP (ou une application compatible) côté Intranet et une avec le serveur de type FTP côté Internet,
- il va négocier deux transferts selon les informations trouvées dans le(s) entrée(s) BDP et dans la demande elle-même ; un des transferts sera une réception et l'autre une émission de fichiers (ou d'un autre objet transférable), - l'application Hyperserveur acheminera les données du fichier, de son origine à sa destination à travers deux connexions de type DATA au sens FTP ou compatibles entre elles-mêmes et deux applications serveurs,
- le(s) profil(s) de transfert et autres paramètres de la Demande Directe de Transfert permettra à l'application Hyperserveur de déterminer les noms de fichiers des deux côtés et tous les attributs du transfert ainsi que les processus à déclencher au début, pendant et à la fin du transfert.

Claims

Revendications
1. Procédé pour le contrôle des échanges de fichiers ou autres objets transférables entre des applications de type FTP ou compatibles, appartenant à une population contrôlée, et des applications de type FTP appartenant à une population banalisée s'exécutant sur différentes plates-formes , caractérisé en ce qu'il met en œuvre une application Hyperserveur qui s'exécute sur une plateforme hôte qui peut communiquer avec des applications des deux populations pouvant appartenir au même ou à différents réseaux IP et qui intervient dans les négociations protocolaires de transfert entre chaque paire d'applications partenaires des échanges, une étant client et l'autre serveur et même dans certains cas jouant le rôle d'un client intermédiaire de deux serveurs ainsi que dans les transferts de fichiers ou autres objets transférables eux-mêmes, en fonction d'une interprétation et/ou d'une traduction des informations échangées, indépendamment de l'environnement d'application de chaque paire d'applications, en interférant dans les échanges en fonction de règles de contrôle qui lui sont imposées et définies dans les bases de données des annuaires des applications partenaires et des profils de transferts.
2. Procédé selon la revendication 1 , caractérisé en ce que des applications agents disposant éventuellement de leurs propres fichiers "LOG" et journal sont mises en œuvre sur les plateformes d'exécution des susdites applications de type FTP (ou compatibles) de manière à pouvoir interagir avec l'application Hyperserveur pour contrôler tout ou partie de la population des applications de type FTP ou compatibles, la population des applications de type FTP (ou compatible) contrôlée et la population de l'ensemble des applications de type FTP (ou compatible) ne bénéficiant pas du contrôle de l'application Hyperserveur pouvant faire partie d'un même réseau IP ou appartenir à des réseaux différents, l'application Hyperserveur résidant alors dans le réseau de la population contrôlée et étant accessible par les applications de la population banalisée, les applications agents étant pourvues d'une interface de communication avec l'application Hyperserveur pour récupérer les informations concernant les transferts de fichiers de leur lieu d'exécution et/ou de recevoir de l'application Hyperserveur un ordre de lancer sous leur propre contrôle les processus en début et/ou en fin des connexions et/ou des transferts.
3. Procédé selon la revendication 2, caractérisé en ce que les applications de type FTP (ou compatibles) du réseau Intranet constituent la population contrôlée et les partenaires du réseau Internet jouent le rôle de la population banalisée.
4. Procédé selon la revendication 3, caractérisé en ce que l'application Hyperserveur s'exécute sur un hôte d'un réseau Intranet, et en ce qu'il constitue, dans ce cas là, le point de passage unique et obligatoire entre ce réseau Intranet et le réseau Internet pour les transferts de fichiers en mode FTP.
5. Procédé selon la revendication 4, caractérisé en ce que la susdite application Hyperserveur comprend les moyens assurant le cryptage et le décryptage des informations échangées côté Internet et/ou Intranet.
6. Procédé selon les revendications 4 et 5, caractérisé en ce que la susdite application Hyperserveur comprend des moyens rendant invisible l'identification des hôtes du réseau Intranet ainsi que ses annuaires de fichiers et tout autre objet transférable aux partenaires extérieurs du réseau Intranet, chaque utilisateur n'ayant à connaître que les identificateurs des entrées de la base de données des profils de transfert de fichiers et des profils de connexion de l'application Hyperserveur et, parmi ces identificateurs, uniquement ceux accessibles au demandeur identifié et authentifié.
7. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il met en œuvre :
- une population banalisée des hôtes résidant dans un réseau IP ayant accès à l'application Hyperserveur et hébergeant :
- des applications de type FTP ou capables de générer un flux de données, cryptées ou non, compatibles avec le protocole FTP,
- des fichiers ou autres objets transférables identifiables et visibles pour ces applications,
- une application Hyperserveur s' exécutant sur un hôte ayant accès aux susdites applications de type FTP ou compatibles disposant de :
- une Base de Données d'annuaire des Hôtes contrôlés et banalisés (BDH) désignant les applications communicantes avec leurs adresses IP et des listes des utilisateurs autorisés à y accéder, ainsi que des moyens pour obtenir les attributs d'autorisation, si nécessaire,
- une Base de Données d'annuaire des Profils de transferts de fichiers ou autres objets transférables (BDP),
- un fichier "LOG" central de l'application Hyperserveur (LGH), contenant les enregistrements de suivi de transferts,
- un fichier journal central de l'application Hyperserveur (JRH), contenant les enregistrements récapitulatifs des transferts,
- une population contrôlée d'hôtes résidant dans un réseau IP et hébergeant : - des applications de type FTP ou capables de générer un flux de données compatible avec le protocole FTP,
- des fichiers ou autres objets transférables identifiables et visibles pour ces applications,
- des applications agents de l'application Hyperserveur disposant éventuellement de leurs propres fichiers "LOG" et journal.
8. Procédé selon la revendication 7, caractérisé en ce que la base de données BDH contient toutes les informations nécessaires à l'application Hyperserveur pour :
- identifier et/ou authentifier chaque demandeur de transfert, et/ou
- identifier et/ou accéder à l'application destinatrice en respectant ses règles d'authentification, et/ou
- déterminer éventuellement les règles de cryptage à utiliser en fonction des demandeurs et des destinataires identifiés, et/ou - identifier et localiser l'application agent de l'application Hyperserveur assignée pour la partie de la connexion dans l'environnement contrôlé, et/ou
- éventuellement, identifier et localiser les processus à exécuter au début et/ou à la fin de la connexion.
9. Procédé selon l'une des revendications 7 et 8, caractérisé en ce que la base de données BDP définit les profils et scénarios des transferts de fichiers ou autres objets transférables à l'aide des attributs suivants :
- l'emplacement des fichiers ou autres objets à émettre ou recevoir, et/ou
- leur nom ou leur méthode de dénomination, et/ou
- leur méthode d'accès, et/ou le type de données et/ou le code,
et, éventuellement :
- les processus et scénarios à exécuter au début et/ou pendant et/ou à la fin des transferts et/ou leur lieu d'exécution, et/ou
- les critères et attributs d'autorisation d'accès au fichier ou objets à transférer.
10. Procédé selon la revendication 7, caractérisé en ce que les bases de données BDP constituent des annuaires locaux de type LDAP ("Lightweight Directory Access Protocol") du réseau de la population contrôlée.
11. Procédé selon la revendication 7, caractérisé en ce que, dans le cas d'une demande de transfert à partir du réseau Internet, il comprend la séquence opératoire suivante :
- l'ouverture par le client demandeur du réseau Internet de la connexion avec l'application Hyperserveur grâce à un jeu de commandes d'ouverture d'une connexion comprenant un nom d'utilisateur, un mot de passe et éventuellement des données d'authentifîcation,
- la détermination par l'application Hyperserveur de l'entrée de l'annuaire BDH définissant les attributs de connexion avec l'application visée du réseau Intranet dans le cas où lesdites informations sont suffisantes compte tenu des règles définies dans l'annuaire BDH, sinon l'utilisation d'une commande FTP supplémentaire pour permettre de le faire,
- la recherche par l'application Hyperserveur, dans la base de données BDH de toutes les informations concernant les droits d'accès du demandeur, le protocole de transfert, les modalités de connexion avec le serveur visé, l'identification du processus à exécuter au début de la connexion, ainsi que l'éventuel déclenchement dudit ou des processus,
- l'ouverture par l'application Hyperserveur de la connexion avec l'application destinatrice et l'échange de commandes éventuellement prévu dès que celui-ci ainsi que les modalités de connexion sont connus, -
- la poursuite de la négociation entre le client demandeur et l'application Hyperserveur jusqu'à réception d'une commande type "store", "store unique", "retrieve", - l'identification par l'application Hyperserveur d'un profil de transfert de fichier ou d'autre objet transférable qui constitue une entrée dans l'annuaire BDP, à la suite de la réception par l'application Hyperserveur d'une commande de transfert,
- la vérification par l'application Hyperserveur du sens de transfert, de même que l'identification par celle-ci du fichier à transférer, de ses attributs, des processus éventuels à exécuter au début, pendant et à la fin du transfert ainsi que la désignation des applications sous contrôle desquelles leurs exécutions doivent avoir lieu, grâce à la définition du profil déteirniné,
- l'acquittement, par l'application Hyperserveur, de la demande du transfert reçu du client à la fin des éventuelles négociations de transferts induites par le profil de transfert avec l'application visée,
- l'ouverture de deux connexions "DATA" au sens FTP à savoir : une connexion entre client FTP et l'application Hyperserveur, et l'autre connexion entre l'application Hyperserveur et l'application visée, les données reçues par l'application Hyperserveur sur une connexion étant ensuite envoyées sur l'autre application en subissant éventuellement un traitement dit "pendant le transfert",
- l'exécution d'éventuels processus en fin de transfert sous le contrôle de l'agent de l'application Hyperserveur de l'hôte de l'application visée en synchronisme avec le dialogue entre cette application et l'application Hyperserveur,
- la fermeture des connexions en cours avec le déclenchement d'éventuels processus de fin de connexion,
- l'enregistrement des événements apportés au cours de la séquence dans des fichiers correspondants (fichier LOG) ainsi que les informations de statistiques dans le fichier journal de l'application Hyperserveur et la transmission des copies de ces enregistrements à l'agent de l'application Hyperserveur concerné pour leurs enregistrements dans des fichiers locaux appropriés.
12. Procédé selon la revendication 7, caractérisé en ce que dans le cas d'une demande de transfert provenant d'un hôte du réseau Intranet, la demande contient toutes les informations nécessaires pour déterminer les entrées aussi bien l'annuaire BDH que celui de BDP, et en ce qu'il comprend la séquence opératoire suivante :
- l'initialisation par l'application Hyperserveur, en tant que client, de deux connexions à savoir : une première connexion avec le serveur de type FTP (ou une application compatible) du réseau Intranet et une deuxième connexion avec un serveur de type FTP situé sur le réseau Internet, cette initialisation utilisant les informations trouvées dans l'entrée BDH déterminée en respectant les règles d'identification, d'autorisation en appliquant les fonctions de cryptage nécessaire et en exécutant le(s) éventuel(s) processus au début de la connexion,
- la négociation de deux transferts FTP selon les informations trouvées dans le(s) entrée(s) BDP et dans la demande elle-même, l'un des transferts étant une réception et l'autre une émission de fichiers ou d'un autre objet transférable,
- le déclenchement de(s) évenruel(s) processus au début du transfert, la détermination par l'application Hyperserveur, des noms de fichiers des deux côtés et de tous les attributs du transfert ainsi que les processus à déclencher au début, pendant et à la fin du transfert, grâce au profil de transfert et autres paramètres de la demande.
- l'acheminement par l'application Hyperserveur des données de fichier, de son origine à sa destination, à travers deux connexions de type DATA, si nécessaire, au sens FTP ou compatibles, entre l'application Hyperserveur et deux applications serveurs, en appliquant les processus dits "pendant le transfert".
l'exécution d'éventuels processus en fin de transfert, sous le contrôle de l'agent de l'application Hyperserveur de l'hôte de l'application visée en synchronisme avec le dialogue entre cette application et l'application
Hyperserveur, fermeture des connexions en cours avec le déclenchement d'éventuels processus de fin de connexion, - l'enregistrement des événements apportés au cours de la séquence dans des fichiers correspondants (fichier LOG) ainsi que les informations de statistiques dans le fichier journal de l'application Hyperserveur et la transmission des copies de ces enregistrements à l'agent de Implication Hyperserveur concerné pour leurs enregistrements dans des fichiers locaux appr
PCT/FR2002/002275 2001-07-03 2002-07-01 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur WO2003005670A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/482,667 US7440959B2 (en) 2001-07-03 2002-07-01 Method of controlling exchanges of data between two applications, namely a client-type application and a server-type application respectively
EP02764936A EP1407594A1 (fr) 2001-07-03 2002-07-01 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR01/08974 2001-07-03
FR0108974A FR2827104B1 (fr) 2001-07-03 2001-07-03 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur

Publications (1)

Publication Number Publication Date
WO2003005670A1 true WO2003005670A1 (fr) 2003-01-16

Family

ID=8865189

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/002275 WO2003005670A1 (fr) 2001-07-03 2002-07-01 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur

Country Status (4)

Country Link
US (1) US7440959B2 (fr)
EP (1) EP1407594A1 (fr)
FR (1) FR2827104B1 (fr)
WO (1) WO2003005670A1 (fr)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110040730A1 (en) * 2007-10-23 2011-02-17 Eugen Adrian Belea System and method for backing up and restoring email data
WO2011128501A1 (fr) * 2010-04-15 2011-10-20 Nokia Corporation Procédé et appareil pour compatibilité et transfert de gadgets logiciels
US9021017B2 (en) * 2011-09-03 2015-04-28 Barracuda Networks, Inc. Configuring a plurality of diverse devices/services from an adaptive configuration control hyper-server apparatus
US9251360B2 (en) * 2012-04-27 2016-02-02 Intralinks, Inc. Computerized method and system for managing secure mobile device content viewing in a networked secure collaborative exchange environment
US9253176B2 (en) 2012-04-27 2016-02-02 Intralinks, Inc. Computerized method and system for managing secure content sharing in a networked secure collaborative exchange environment
EP2842070B1 (fr) 2012-04-27 2020-08-05 Intralinks, Inc. Procédé et système informatisés de gestion d'échanges participatifs sécurisés en réseau
US9553860B2 (en) 2012-04-27 2017-01-24 Intralinks, Inc. Email effectivity facility in a networked secure collaborative exchange environment
US9514327B2 (en) 2013-11-14 2016-12-06 Intralinks, Inc. Litigation support in cloud-hosted file sharing and collaboration
WO2015164521A1 (fr) 2014-04-23 2015-10-29 Intralinks, Inc. Systèmes et procédés d'échange de données sécurisé
US10033702B2 (en) 2015-08-05 2018-07-24 Intralinks, Inc. Systems and methods of secure data exchange
CN112883009B (zh) * 2019-11-29 2024-05-07 北京百度网讯科技有限公司 用于处理数据的方法和装置
US12081979B2 (en) * 2020-11-05 2024-09-03 Visa International Service Association One-time wireless authentication of an Internet-of-Things device
CN112383612B (zh) * 2020-11-11 2022-06-14 成都卫士通信息产业股份有限公司 一种文件传输方法、装置、设备及可读存储介质
CN115150207B (zh) * 2022-09-06 2022-11-29 北京六方云信息技术有限公司 工业网络设备识别方法、装置、终端设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998004971A1 (fr) * 1996-07-25 1998-02-05 Tradewave Corporation Procede et systeme de mise en application d'un protocole generalise sur des connexions de communications client/serveur

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4605414A (en) 1984-06-06 1986-08-12 John Czajka Reconstruction of a cruciate ligament
JPH0563749A (ja) * 1991-09-02 1993-03-12 Hitachi Ltd マルチプロトコル通信制御装置
JP2519390B2 (ja) * 1992-09-11 1996-07-31 インターナショナル・ビジネス・マシーンズ・コーポレイション デ―タ通信方法及び装置
AU702628B2 (en) 1995-04-12 1999-02-25 Smith & Nephew, Inc. Improved process for knee reconstruction
US6170008B1 (en) * 1998-12-07 2001-01-02 Mediaone Group, Inc. On-the-fly trivial file transfer protocol
US20030149601A1 (en) * 2000-12-14 2003-08-07 Cabral Anthony J. Network billboard system and method thereof
US7171668B2 (en) * 2001-12-17 2007-01-30 International Business Machines Corporation Automatic data interpretation and implementation using performance capacity management framework over many servers
US7724281B2 (en) * 2002-02-04 2010-05-25 Syniverse Icx Corporation Device facilitating efficient transfer of digital content from media capture device
CA2391719A1 (fr) * 2002-06-26 2003-12-26 Ibm Canada Limited-Ibm Canada Limitee Edition de fichiers de systemes eloignes dans un environnement de developpement integre

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998004971A1 (fr) * 1996-07-25 1998-02-05 Tradewave Corporation Procede et systeme de mise en application d'un protocole generalise sur des connexions de communications client/serveur

Also Published As

Publication number Publication date
FR2827104A1 (fr) 2003-01-10
US7440959B2 (en) 2008-10-21
US20040216128A1 (en) 2004-10-28
EP1407594A1 (fr) 2004-04-14
FR2827104B1 (fr) 2004-01-30

Similar Documents

Publication Publication Date Title
EP1407594A1 (fr) Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur
EP1645971B1 (fr) Procede de controle d'acces a une base de donnees, controleur d'acces a une base de donnees, serveur de traitement d'agent, programme de controle d'acces a une base de donnees, et support d'enregistrement de ce programme
JP2002529856A5 (fr)
CN103583030B (zh) 在分布式云计算环境中实现数据安全性的方法及装置
US7349974B2 (en) Method for coordinating actions among a group of servers
US20060143301A1 (en) Systems and methods for establishing and validating secure network sessions
US20080189393A1 (en) Remote Access to Secure Network Devices
US20020111996A1 (en) Method, system and apparatus for networking devices
US20070192614A1 (en) System and method for authenticating a storage device for use with driver software in a storage network
US6738909B1 (en) Method and apparatus for automatic configuration for internet protocol security tunnels in a distributed data processing system
US20090193127A1 (en) Systems and Methods for Establishing and Validating Secure Network Sessions
JPWO2009019925A1 (ja) 通信方法、中継サーバ装置、プログラム及び記録媒体
JP2003518820A (ja) 循環暗号化および復号化プロセスのための方法および装置
JP4358795B2 (ja) Ｔｌｓセッション情報の引継ぎ方法及びコンピュータシステム
KR100953093B1 (ko) 이종 ＵＰｎＰ네트워크를 통한 멀티미디어 서비스 방법 및 시스템
JP3877388B2 (ja) 情報提供システム
EP2537114B1 (fr) Procede de verrouillage/deverrouillage a distance d'une machine
CN100559769C (zh) 访问远程应用的方法和基础设施
EP2235881A2 (fr) Préservation de système client-serveur d'informations d'état mis en réseau par l'intermédiaire d'un protocole sans état
Tobarra et al. Formal verification of the secure sockets layer protocol
WO2016116702A1 (fr) Contrôle d'accès aux équipements d'un site sécurise par authentification biométrique
TWI255124B (en) System and method of managing users based on IP
FR3136075A1 (fr) Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés.
FR2778290A1 (fr) Procede et dispositif d'interconnexion securisee entre des ordinateurs, organises en reseau, par pilotage d'un module de filtrage residant dans la couche de communication ip
Davis et al. Protocols, Sessions, and State

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 10482667

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2002764936

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002764936

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2002764936

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP