WO2005034468A1 - Systeme d'acces a un reseau adapte pour la mise en oeuvre d'un procede a signature simplifiee, et serveur pour sa realisation - Google Patents

Systeme d'acces a un reseau adapte pour la mise en oeuvre d'un procede a signature simplifiee, et serveur pour sa realisation Download PDF

Info

Publication number
WO2005034468A1
WO2005034468A1 PCT/FR2004/002272 FR2004002272W WO2005034468A1 WO 2005034468 A1 WO2005034468 A1 WO 2005034468A1 FR 2004002272 W FR2004002272 W FR 2004002272W WO 2005034468 A1 WO2005034468 A1 WO 2005034468A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
server
user
service provider
module
Prior art date
Application number
PCT/FR2004/002272
Other languages
English (en)
Inventor
Etienne Annic
Anne Boutroux
Cédric Goutard
Rym Sahnoun
Patrick Bauban
Original Assignee
Orangefrance
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 Orangefrance filed Critical Orangefrance
Priority to US10/572,949 priority Critical patent/US7823188B2/en
Priority to EP04787325A priority patent/EP1668868A1/fr
Publication of WO2005034468A1 publication Critical patent/WO2005034468A1/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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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/104—Grouping of entities
    • 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/2866—Architectures; Arrangements
    • H04L67/2876—Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • Network access system suitable for implementing a simplified signature process, and server for carrying it out.
  • the invention relates to a network access system suitable for implementing a simplified signature process, and a server for carrying it out. More specifically, the invention relates to a system comprising: - at least one user station equipped with an internet browser, - a proxy server through which pass all the information flows exchanged between the or each user station and said network, - several service providers connected to said network, each service provider being able to send an authentication request to the station of the user who contacts him to identify and / or authenticate this user before providing him with personalized services and / or secure, the response to be provided by the same user to this authentication request may be different depending on the service provider contacted, - at least one authentication server capable of storing at least one authentication information for each user and transmitting in response to an authentication request an authentication response containing information authentication function both of the service provider who issued the authentication request, and of the identity of the user who contacted this service provider, and - a simplified signature module capable of processing automatically instead of the or each user station the authentication requests sent by the service providers contacted, this module being suitable for each
  • SSO Single Sign On
  • STEM Sign On Single Sign On
  • SSO processes aim to simplify the identification and / or authentication of a user on the world spider web better known under the terms of WEB (World Wide Web). In the remainder of this description, the world spider web will be simply designated by the term internet network.
  • the invention aims to remedy this drawback by proposing an access system to a packet switched network suitable for implementing an SSO method in which the modifications to be made to the proxy server are minor and the consequences on the charges to be treated are minor.
  • the invention therefore relates to a system as described above, characterized in that it comprises an additional server independent of the proxy server, the simplified signature module being implemented in this additional server, and in that the proxy server is equipped with an interface making it possible to connect the additional server and to transmit at least the authentication requests sent by the service providers contacted to said additional server for processing of these requests by the simplified signature module.
  • the simplified signature module includes a sub-module capable of identifying the user from his network address and of adding an identifier of the user to the authentication requests directed to the authentication servers;
  • Said at least one authentication information stored for each user comprises information on an authentication level available for this user, in that each authentication request sent by a service provider specifies characteristics on the authentication level required by this service provider to be able to access the services it offers, in that the or each authentication server is able to compare the characteristics on the required level of authentication specified by the information authentication request on the level of authentication available, so as to determine whether the level of authentication required corresponds to the level of authentication available for this user, and in that the or each authentication server is capable of transmitting to the user a active authentication request capable of activating an interactive process on the user's computer identification and / or authentication of the user if the required authentication level does not correspond to the available authentication level;
  • the additional server includes a sub-module capable of directing the user's response to active authentication requests to
  • the additional server is only able to communicate with service providers via the HTTP flow transfer protocol implemented between it and the proxy server; - the additional server also implements a server and / or an HTTP (Hyper Text Transfer Protocol) client to communicate directly with the or each service provider and / or the or each authentication server only using the HTTP protocol; - It includes an access provider to said network to which the or each user station must be connected to be able to access said network, this access provider being equipped with the proxy server; - said network is the world spider web.
  • HTTP Hyper Text Transfer Protocol
  • FIG. 1 represents a system, designated by the general reference
  • the system 2 comprises numerous user stations having functionalities similar to each other as well as several internet service providers, also having functionalities similar to each other.
  • a user station 10 and an access provider 12 have been shown.
  • the station 10 is able to navigate on the network 4.
  • it is formed, for example, of a conventional computer 14 equipped with a screen and a keyboard as well as an internet browser 16 better known as the English term for "browser".
  • System 2 also includes many service provider systems as well as several authentication servers.
  • only two service provider systems 20, 22, designated providers, as well as two authentication servers 24, 26 are represented in the figure.
  • the service providers 20, 22 are intended to render services to the user of the station 10.
  • the provider 20 is a computer server capable of establishing pay slips as a function of the information communicated to it by the user of the station 10.
  • the server 20 comprises a module 32 suitable for identifying and authenticating the user of the station 10 so as to personalize and secure the service which it renders to this user.
  • the supplier 20 is associated with a memory 30 in which is recorded a list 34 of authentication servers known to the supplier 20 as well as a level 36 of authentication required by this supplier.
  • List 34 includes identifiers of the authentication servers containing authentication information specific to identify and authenticate a user with this service provider. Such information is, for example, an authentication level currently available for a given user.
  • the authentication level recorded in the memory 30 defines the quality of the authentication required by the supplier 20.
  • each authentication level can take any of the integer values between "1" and "5".
  • the lower the value of the authentication level the lower the quality of authentication.
  • the authentication level 36 is equal to "2".
  • the functions performed by the module 32 are described in more detail with reference to FIGS. 3 and 4 and the advantage of the list 34 as well as of the level of authentication will appear on reading the remainder of this description. We will simply mention here the fact that the module 32 is capable of transmitting an HTTP authentication request included in an HTTP response to authenticate the user to the station 10 of this user.
  • the supplier 22 allows, for example, the user of the station 10 to remotely manage his bank accounts and also to carry out bank transactions.
  • the supplier 22 includes the same elements as those described with regard to the supplier 20 with the exception that the authentication level 36 is replaced by an authentication level 38 equal to "4".
  • the authentication servers 24 and 26 are intended to respond to the authentication requests sent by the service providers. To this end, the servers 24 and 26 are each associated with a memory 40, 41 in which is recorded for each user known to this server, authentication information 42, 43. Each authentication information contains the authentication level available for the corresponding user.
  • Each authentication server 24, 26 also includes an access control module 44. This module allows the servers 24 and 26 to issue an active authentication request so as to interrogate the user of the station 10 so that he provides a set of information making it possible to identify and authenticate him with a desired authentication level. An information set is, for example, an identifier of the user and his password.
  • the access provider 12 is capable of performing the conventional functions of an internet access provider, that is to say in particular of assigning a network address to the station 10 so that the latter can browse the network 4
  • the access provider 12 includes an HTTP proxy server (Hyper Text Transfer Protocol) and an access control server 52.
  • the existing HTTP protocol is a communication protocol used for the exchange of data between HTTP clients and HTTP servers known as web servers.
  • the proxy server is placed in flow cutoff between the station 10 and the network 4, that is to say that all of the information flows exchanged between the browser 16 of the station 10 and the network 4 passes through the proxy server 50. Thus, the proxy server 50 sees all of the HTTP requests and responses sent by the station 10 or to the station 10.
  • the access control server 52 is capable of identifying and authenticate the user of station 10 before authorizing this station 10 to connect to network 4 and to navigate on it.
  • the user of the station 10 identifies himself to the server 52 by providing a set of information containing an identifier known by the English term of "login" and a password. If the user is correctly identified and authenticated, that is to say that the set of information which he has provided corresponds to a valid subscription with this access provider, the server 52 assigns to this user a network address, that is to say here an IP address (Internet Protocol) for browsing the network 4. Otherwise, the server 52 prohibits any connection to the network 4.
  • IP address Internet Protocol
  • the server 52 is also capable of recording in a memory 54 with which there is associated a list 56 containing for each IP address assigned to a user, the identifier of the corresponding user. This list is updated automatically by the server 52.
  • the access provider 12 includes an iCAP server 60 (Internet
  • the existing iCAP protocol is standardized by the IETF organization (Internet Engineering Task Force) for the systematic transformation of content on the Internet.
  • the server 60 and the server 50 are able to communicate with each other by implementing the iCAP protocol.
  • the server 50 is able to communicate to the server 60 HTTP requests or responses present in the information flows exchanged between the station 10 and the network 4 and the server 60 is also capable of transmitting HTTP requests or responses after having modified them at the server 50.
  • the proxy server 50 is equipped with an iCAP 64 interface comprising a connector making it possible to connect it to the server 60.
  • the interface 64 is here configured for transmitting to the server 60 only the HTTP requests or responses which must be modified for the implementation of the SSO method.
  • the server 60 is equipped with an SSO module 66 capable of supporting all the specific processing required by the implementation of the method
  • This module 66 comprises three sub-modules 68, 70 and 72 each corresponding to an iCAP service. These sub-modules will be described in more detail with reference to each of FIGS. 3 and 4.
  • the server 60 is associated with the memory 54 which also contains a list 76 of the authentication servers known by each user. This list 76 groups together for each user, the identifiers of the various authentication servers in which authentication information for this user is stored.
  • the server 60 also implements an HTTP client. To this end, it is connected to the network 4 via an additional HTTP proxy server 74 which can be independent and distinct from the proxy server 50. All the servers of the system 2 are produced from conventional programmable electronic computers. capable of executing instructions recorded on an information recording medium.
  • the memories 30, 40, 41 and 54 include instructions for the execution of the SSO method of FIGS. 2 to 4 when said instructions are executed by these computers.
  • the operation of the system 2 will now be described with reference to FIGS. 2 to 4.
  • an identifier of the server 24 is recorded in the list 76 of the authentication servers known to the user.
  • the lists 34 of the service providers are updated.
  • the user of the station 10 connects, during a step 94, to the network 4.
  • the user enters, during an operation 96, a set of information making it possible to identify it and to authenticate it with the server 52.
  • the server 52 assigns an IP address to it and records the relationship between this network address and the identifier of this user in the list 56. Then, the server 52 informs, during an operation 100, the different authentication servers known to this user that the user has been correctly identified and authenticated. This identification and authentication performed by the server 52 is here associated with an authentication level equal to
  • the authentication servers memorize that the level of authentication available is equal to "2".
  • the user connects, for example, during a step 104, to the service provider 20.
  • the module 32 of the provider 20 then sends in response, during an operation 106, an HTTP authentication request included in an HTTP response to the station
  • This request is intercepted by the proxy server 50 then processed by the iCAP server 60 and finally transmitted to the authentication server 24.
  • This authentication request comprises the authentication level 36.
  • the server 24 verifies, during a step 108, that the authentication level available for this user is at least equal to "2".
  • the authentication level available being equal to that required by the supplier 20
  • the server 24 transmits, during a step 110, an authentication response containing an authentication certificate to the supplier 20.
  • This certificate informs the supplier 20 that the required level of authentication is available.
  • the supplier 20 having received the certificate then offers, during a step 112, to this user a personalized and / or secure service without the user needing to identify himself to the supplier 20.
  • the supplier 20 suggests printing a pay sheet with his name.
  • the user 10 connects at 14 to the service provider 22. This provider 22 then performs the operation 106.
  • the authentication server 24 finds that the level authentication required by the provider 22 is greater than that currently available for this user.
  • the server access control module 44 then proceeds to an active authentication step 120 during which it interrogates the user, so as to identify and authenticate the latter with an authentication quality corresponding to the level d authentication "4". For example, module 44 asks the user to enter personal information such as his date of birth. If the user of the station 10 has been correctly identified and authenticated with an authentication level "4", the server 24 records the new authentication level available in its memory 40 and proceeds to step 110. Then, the supplier 22 offers, during a step 122, a personalized and / or secure service to this user.
  • the browser 16 of the station 10 sends an HTTP request to the module 32 of a service provider, for example the provider 20.
  • This request is routed, during an operation 130, to the proxy server 50.
  • the interface 64 intercepts this request and transmits it, during an operation 132, to the server 60 and more precisely to the submodule 68.
  • the submodule 68 adds a header to the HTTP request indicating that the system 2 supports a method SSO and retransmits, during an operation 134 this HTTP request thus modified to the proxy server 50.
  • the proxy server then transmits the modified HTTP request to the service provider during an operation 136.
  • the module 32 of the service provider detects the presence of the header added by the sub-module 68 and, in response, sends, during an operation 138, an authentication request to the browser 16.
  • the authentication request is, for example, SOAP compliant (Singl e Object Access Protocol) standardized by the W3C (World Wide Web Consortium) organization.
  • This authentication request comprises in particular an identifier of the service provider, a copy of the list 34 of known authentication servers, the level of authentication required by this provider and, for example, an instruction known under the English terms "set cookie "intended to record an identifier of the authentication request on computer 10 or, as a variant, directly an identifier of the request.
  • the interface 64 of the proxy server 50 intercepts this authentication request and directs it, during an operation 140, to the submodule 70 of the server 60.
  • the sub-module 70 compares, during an operation 142, the list 34 received to the list 56 to select the authentication server to be contacted, for example, here the server 24. If there is no server authentication common to the list 34 received and to the list 56, the sub-module 70 sends an incompatibility message to the service provider that issued the authentication request.
  • This incompatibility message includes the identifier of the authentication request, so that the module 32 can link this response to the corresponding authentication request.
  • the identifier of the authentication request is, for example, that contained in the "set cookie" instruction.
  • the sub-module 70 determines, during an operation 144, the identity of the user of the station 10 by comparing the network address of the station 10 to the list 76. This address will have been provided by the proxy server 50 to the submodule 70 during operation 140 via a field in the HTTP header. Once the user has been identified, the sub-module 70 performs an operation 148 for transmitting the authentication request received associated with the identifier of the user obtained during operation 144, to the authentication server selected during of operation 142. The server 24 compares, during an operation 150, the level of authentication available to the user with that required by the service provider. In the case where the required authentication level is higher than that currently registered by the server 24, the latter proceeds as described with reference to FIG. 4.
  • the server 24 sends during an operation 152, an authentication response to the server 60.
  • the submodule 70 receives the authentication response and transmits it, during an operation 156, to the service provider via the proxy server 74 and using the HTTP protocol .
  • This authentication response includes, if necessary, a user identifier.
  • the service provider responds to this authentication response by transmitting to the server 60, during an operation 158, for example, a personalized home page.
  • This response is transmitted via the proxy server 74 to the server 60 using the HTTP protocol.
  • the sub-module 70 redirects, during an operation 160, this response to the proxy server 50 using the iCAP protocol which in turn redirects it, during an operation 162, to the browser 16 using the HTTP protocol.
  • FIG. 4 represents the circulation of information between the various devices of the system 2 in the particular case where the level of authentication required by the contacted service provider is higher than that currently stored in the memory 40 of the server 24.
  • the devices and the operations already described opposite Figures 1 and 3 bear the same references and the new operations are shown in bold lines.
  • the server 24 has established that the required authentication level is higher than that currently available to the user. Consequently, it proceeds to an operation 180 during which the module 44 transmits an active authentication request to the server 60 contained in an HTTP response and using the HTTP protocol.
  • the active authentication request is intended to activate on the browser 16 an interactive authentication process.
  • this request here includes a form to be completed by the user.
  • the sub-module 70 retransmits during an operation 182, this active authentication request to the proxy server 50 using the iCAP protocol, then the proxy server 50 retransmits it, during an operation 184, to the browser 16 in using the HTTP protocol.
  • the browser 16 displays the form which allows the user to identify and authenticate with a higher authentication level, for example, equal to "4" in the case of the service provider 22.
  • the browser 16 sends, during an operation 186, the response in an HTTP request.
  • This response is intercepted by the interface 64 of the server 50 and transmitted, during an operation 188, to the sub-module 72 using the protocol iCAP.
  • the sub-module 72 then retransmits, during an operation 190, the response of the user using the HTTP protocol to the server 24.
  • the server 24 stores, during an operation 192, the new authentication level available in the memory 40 and then proceeds to operation 152.
  • the following operations are identical to those described with reference to FIG. 2 except that the operations 152, 156, 158 and 160 involve the submodule 72 in place of the submodule 70.
  • Most of the existing proxy servers include already an iCAP interface.
  • the iCAP server 60 communicates directly using the HTTP protocol with the service provider (s) during operations 156 and 158.
  • the iCAP server communicates with service providers only through the iCAP protocol. For example, in this variant, the HTTP requests sent to the service provider during operation 156 are first transmitted by the server 60 to the proxy server 50 using the iCAP protocol and then the proxy server 50 transmits these requests to the service provider using the HTTP protocol.
  • the HTTP response sent by the service provider during operation 158 follows the reverse path of the request sent during operation 156.
  • the server 60 never communicates directly with the service providers so that those -these are not aware of the existence of the server 60.
  • the use of the server 60 is then completely transparent for these service providers.
  • This variant has the advantage that from the point of view of the service provider, all the exchanges of information take place between him and the user without being aware of the existence of the server 60.
  • This variant also has the advantage that the HTTP requests issued and received during operations 156 and 158 are directly exchanged with the proxy server 50 and no longer via the sub-module 70 which accelerates the processing of these operations.
  • the sub-modules 68 to 72 have been described in the particular case where they are all implemented in the same iCAP server 60.
  • these sub-modules are each implemented in an iCAP server independent of the others.
  • the interface 64 is configured to intercept only HTTP requests which must be processed by the iCAP server.
  • the interface 64 is configured to redirect all the HTTP information flows to the iCAP server and the iCAP server implements a filtering module capable of sending to the processing module 66 only the HTTP requests which must be processed by this module .
  • the interception of HTTP requests is not carried out by the proxy server 50 but by the iCAP server.
  • the system 2 has been shown in the particular case where the authentication servers are connected to the internet service provider via the network 4.
  • At least one of these authentication servers is housed at the internet access provider and connected to it via a local network independent of network 4.
  • This advantageous mode of implementation will allow it to benefit from all the identifications / authentications carried out by the access provider and which cannot be shared with external authentication providers for security reasons;
  • the iCAP server is connected to the proxy server 50 via a long distance network and no longer via a link or a local network.
  • the system 2 has been described in the particular case where the first authentication of each user is carried out by the internet service provider 12. As a variant, this first authentication is no longer performed by the internet service provider 12 but, by for example, by the first service provider contacted by the user.
  • the identification and authentication of the user have been described in the particular case where this is done from a terminal 10 equipped with a screen and a keypad which allows entering a set of identification and authentication information.
  • the first identification and authentication of the user is carried out automatically, for example, by identifying the terminal used by this user. More specifically, when the terminal 10 is replaced by a mobile telephone, the identification and authentication of the user is done automatically by acquiring the telephone number of the terminal. In this case, the authentication is said to be transparent.
  • the system 2 has also been described in the particular case where the authentication servers memorize only the authentication level available for each user, which reinforces the security of the system since it is not desirable for all of the words of password and other secret user information are saved in one place.
  • these authentication servers also memorize as authentication information the set or sets of identification and authentication information that each user is likely to use to identify and authenticate themselves. with each service provider.
  • the authentication response includes the set of identification and authentication information to be transmitted to the service provider so that the latter identifies and authenticates the user.
  • This set of identification and authentication information is transmitted to the service provider in a similar manner to what has been described for the authentication certificate.
  • the system 2 has been described in the particular case where the authentication request sent by each service provider includes an authentication level. Alternatively, the authentication request sent by one of the service providers does not include an authentication level.
  • the contacted authentication server provides, in response, an authentication certificate simply indicating that the user has been authenticated.
  • the user will have access to the services of the service provider from the moment when he has been authenticated at least once and this regardless of the level of this authentication.
  • the system 2 has been described in the particular case where the network 4 is the internet network. However, as a variant, this network 4 is any information transmission network such as a local area network, any packet switched network or a circuit switched network.
  • the system 2 has been described in the particular case where the authentication servers are able to issue active authentication requests when these do not have a satisfactory authentication for the user. As a variant, the authentication servers are not able to issue these active authentication requests.
  • system 2 has been described in the particular case where the HTTP stream transfer protocol is the iCAP protocol.
  • the iCAP protocol can be replaced by any other HTTP flow transfer protocol such as for example the OCP protocol (OPES Call Out Protocol) with OPES (Open Pluggable Edge Services).
  • OCP protocol OPES Call Out Protocol
  • OPES Open Pluggable Edge Services

Landscapes

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

Abstract

Ce système d'accès à un réseau (4) à commutation de paquets adapté pour la mise en oeuvre d'un procédé à signature simplifiée, comporte un serveur supplémentaire (60) indépendant d'un serveur proxy (50) d'un fournisseur d'accès (12) et un module à signature simplifiée (60) implémenté dans ce serveur supplémentaire (60). Le serveur proxy (50) est équipé d'une interface (64) permettant de le raccorder au serveur supplémentaire (60), et de transmettre au moins des requêtes d'authentification émises par des fournisseurs de services contactés audit serveur supplémentaire (60) pour traitement de ces requêtes par le module à signature simplifiée (60).

Description

Système d'accès à un réseau adapté pour la mise en œuyre d'un procédé à signature simplifiée, et serveur pour sa réalisation.
L'invention concerne un système d'accès à un réseau adapté pour la mise en œuvre d'un procédé à signature simplifiée, et un serveur pour sa réalisation. Plus précisément, l'invention concerne un système comportant : - au moins un poste d'utilisateur équipé d'un navigateur internet, - un serveur proxy par lequel passent tous les flux d'informations échangés entre le ou chaque poste d'utilisateur et ledit réseau, - plusieurs fournisseurs de services raccordés audit réseau, chaque fournisseur de services étant apte à émettre une requête d'authentification vers le poste de l'utilisateur qui le contacte pour identifier et/ou authentifier cet utilisateur avant de lui fournir des services personnalisés et/ou sécurisés, la réponse à fournir par un même utilisateur à cette requête d'authentification pouvant être différente en fonction du fournisseur de services contacté, - au moins un serveur d'authentification propre à mémoriser au moins une information d'authentification pour chaque utilisateur et à transmettre en réponse à une requête d'authentification une réponse d'authentification contenant une information d'authentification fonction à la fois du fournisseur de services ayant émis la requête d'authentification, et de l'identité de l'utilisateur ayant contacté ce fournisseur de services, et - un module à signature simplifiée apte à traiter automatiquement en lieu et place du ou de chaque poste d'utilisateur les requêtes d'authentification émises par les fournisseurs de services contactés, ce module étant apte pour chaque utilisateur : - à diriger les requêtes d'authentification vers le serveur d'authentification approprié, et - à retransmettre au fournisseur de services la réponse d'authentification correspondante transmise par le serveur d'authentification approprié. Ces systèmes permettent de mettre en œuvre un procédé à signature simplifiée plus connu sous les termes de procédé SSO ("Single Sign On" ou "Simplified Sign On"). Des renseignements plus précis sur un exemple de procédé SSO peuvent être obtenus à la lecture des recommandations définies par le consortium d'entreprises appelé Liberty Alliance, dont le but est le développement des transactions sur Internet. Ces recommandations peuvent par exemple, être obtenues à partir du site Internet http://www.projectliberty.org. Les procédés SSO visent à simplifier l'identification et/ou l'authentification d'un utilisateur sur la toile d'araignée mondiale plus connue sous les termes de WEB (World Wide Web). Dans la suite de cette description, la toile d'araignée mondiale sera simplement désignée par le terme réseau internet. Les procédés SSO et notamment ceux conformes aux recommandations de Liberty Alliance, implémentent le module à signature simplifiée dans le serveur proxy. Toutefois, cette solution présente l'inconvénient qu'elle implique des modifications substantielles des serveurs proxy existants et qu'elle suppose une augmentation des traitements à réaliser par les serveurs proxy existants. L'invention vise à remédier à cet inconvénient en proposant un système d'accès à un réseau à commutation de paquets adapté pour la mise en œuvre d'un procédé SSO dans lequel les modifications à apporter au serveur proxy sont mineures et les conséquences sur la charge à traiter sont mineures. L'invention a donc pour objet un système tel que décrit ci-dessus, caractérisé en ce qu'il comporte un serveur supplémentaire indépendant du serveur proxy, le module à signature simplifiée étant implérnenté dans ce serveur supplémentaire, et en ce que le serveur proxy est équipé d'une interface permettant de raccorder le serveur supplémentaire et de transmettre au moins les requêtes d'authentification émises par les fournisseurs de services contactés audit serveur supplémentaire pour traitement de ces requêtes par le module à signature simplifiée. Suivant d'autres caractéristiques du système conforme à l'invention, celui-ci se caractérise en ce que : - le module à signature simplifiée comporte un sous-module propre à identifier l'utilisateur à partir de son adresse réseau et à ajouter un identificateur de l'utilisateur aux requêtes d'authentification dirigées vers les serveurs d'authentification ; - ladite au moins une information d'authentification mémorisée pour chaque utilisateur comprend une information sur un niveau d'authentification disponible pour cet utilisateur, en ce que chaque requête d'authentification émise par un fournisseur de services spécifie des caractéristiques sur le niveau d'authentification requis par ce fournisseur de services pour pouvoir accéder aux services qu'il propose, en ce que le ou chaque serveur d'authentification est apte à comparer les caractéristiques sur le niveau d'authentification requis spécifié par la requête d'authentification à l'information sur le niveau d'authentification disponible, de manière à déterminer si le niveau d'authentification requis correspond au niveau d'authentification disponible pour cet utilisateur, et en ce que le ou chaque serveur d'authentification est apte à émettre vers l'utilisateur une requête d'authentification active propre à activer sur le poste de l'utilisateur un processus interactif d'identification et/ou d'authentification de l'utilisateur si le niveau d'authentification requis ne correspond pas au niveau d'authentification disponible ; - le serveur supplémentaire comporte un sous-rnodule propre à diriger la réponse de l'utilisateur aux requêtes d'authentification active vers le serveur d'authentification qui l'a émise ; - le serveur supplémentaire comporte un sous module propre à diriger la requête d'authentification active vers le poste de l'utilisateur ; - le module à signature simplifiée comporte un sous-module capable d'ajouter aux requêtes transmises par le poste d'utilisateur vers un fournisseur de services un signal d'identification de service à signature simplifiée en réponse auquel le fournisseur de services émet la requête d'authentification ; - le serveur supplémentaire et le serveur proxy sont aptes à communiquer l'un avec l'autre en mettant en œuvre un protocole de transfert de flux HTTP (Hyper Text Transfer Protocol) ; - le protocole de transfert de flux HTTP est le protocole iCAP (Internet Content Adaptation Protocol) ou le protocole OCP (OPES Call Out Protocol). - le serveur supplémentaire est uniquement apte à communiquer avec les fournisseurs de services par l'intermédiaire du protocole de transfert de flux HTTP mis en œuvre entre lui et le serveur proxy ; - le serveur supplémentaire implémente également un serveur et/ou un client HTTP (Hyper Text Transfer Protocol) pour communiquer directement avec le ou chaque fournisseur de services et/ou le ou chaque serveur d'authentification uniquement à l'aide du protocole HTTP ; - il comporte un fournisseur d'accès audit réseau auquel doit se connecter le ou chaque poste d'utilisateur pour pouvoir accéder audit réseau, ce fournisseur d'accès étant équipé du serveur proxy ; - ledit réseau est la toile d'araignée mondiale. L'invention sera mieux comprise à la lecture de la description qui va suivre donnée uniquement à titre d'exemple et faite en se référant aux dessins sur lesquels : - la figure 1 est une illustration schématique de l'architecture d'un système conforme à l'invention, - la figure 2 est un organigramme d'un procédé à signature simplifiée mis en œuvre dans le système de la figure 1, et - les figures 3 et 4 sont des illustrations schématiques de la circulation des flux d'informations entre les différents équipements du système de la figure 1. La figure 1 représente un système, désigné par la référence générale
2, d'accès à un réseau 4 à commutation de paquets adapté pour la mise en œuvre d'un procédé SSO conforme aux recommandations définies par Liberty Alliance. Les recommandations établies par Liberty Alliance définissent l'organisation et les fonctionnalités des différents équipements ou groupes d'équipements du système 2 avec une précision suffisante pour que l'homme du métier à la lecture de ces recommandations puisse fabriquer ses équipements. Ces recommandations ne décrivent pas la réalisation détaillée de chacun de ces équipements. Par conséquent, dans la suite de la description, on ne décrira de façon détaillée que le bloc d'équipement représenté par un rectangle en pointillé sur la figure 1, les autres équipements du système 2 étant réalisés de façon conventionnelle à partir des recommandations de Liberty Alliance. Le système 2 sera ici décrit dans le cas particulier où le réseau 4 est le réseau internet. Le système 2 comporte de nombreux postes d'utilisateurs ayant des fonctionnalités similaires les unes aux autres ainsi que plusieurs fournisseurs d'accès internet, ayant également des fonctionnalités similaires les unes aux autres. Ici pour simplifier l'illustration de la figure 1 , seul un poste d'utilisateur 10 et un fournisseur d'accès 12 ont été représentés. Le poste 10 est apte à naviguer sur le réseau 4. A cet effet, il est formé, par exemple, d'un ordinateur conventionnel 14 équipé d'un écran et d'un clavier ainsi que d'un navigateur internet 16 plus connu sous le terme anglais de "browser". Le système 2 comporte également de nombreux systèmes fournisseurs de services ainsi que plusieurs serveurs d'authentification. Ici, seuls deux systèmes fournisseurs de services 20, 22, désignés fournisseurs, ainsi que deux serveurs d'authentification 24, 26 sont représentés sur la figure
1 pour simplifier l'illustration. Les fournisseurs de services 20, 22 sont destinés à rendre des services à l'utilisateur du poste 10. Par exemple, ici, le fournisseur 20 est un serveur informatique propre à établir des fiches de paye en fonction des informations qui lui sont communiquées par l'utilisateur du poste 10. Pour cela, le serveur 20 comporte un module 32 propre à identifier et à authentifier l'utilisateur du poste 10 de manière à personnaliser et à sécuriser le service qu'il rend à cet utilisateur. Plus précisément, le fournisseur 20 est associé à une mémoire 30 dans laquelle est enregistrée une liste 34 de serveurs d'authentification connus du fournisseur 20 ainsi qu'un niveau 36 d'authentification requis par ce fournisseur. La liste 34 comporte des identificateurs des serveurs d'authentification contenant des informations d'authentification propres à identifier et authentifier un utilisateur auprès de ce fournisseur de services. Une telle information est, par exemple, un niveau d'authentification disponible actuellement pour un utilisateur donné. Le niveau d'authentification enregistré dans la mémoire 30 définit la qualité de l'authentification requise par le fournisseur 20. Dans le système 2, à titre d'exemple, chaque niveau d'authentification peut prendre l'une quelconque des valeurs entières comprises entre "1" et "5". Plus la valeur du niveau d'authentification est petite, plus la qualité de l'authentification est faible. Ici, à titre d'exemple, le niveau d'authentification 36 est égal à "2". Les fonctions réalisées par le module 32 sont décrites plus en détail en regard des figures 3 et 4 et l'intérêt de la liste 34 ainsi que du niveau d'authentification apparaîtra à la lecture de la suite de cette description. On mentionnera ici simplement le fait que le module 32 est capable d'émettre une requête d'authentification HTTP incluse dans une réponse HTTP pour authentifier l'utilisateur vers le poste 10 de cet utilisateur. Le fournisseur 22 permet, par exemple, à l'utilisateur du poste 10 de gérer à distance ses comptes bancaires et d'effectuer également des transactions bancaires. Le fournisseur 22 comporte les mêmes éléments que ceux décrits en regard du fournisseur 20 à l'exception du fait que le niveau d'authentification 36 est remplacé par un niveau d'authentification 38 égal à "4". Les serveurs d'authentification 24 et 26 sont destinés à répondre aux requêtes d'authentification émises par les fournisseurs de services. A cet effet, les serveurs 24 et 26 sont associés chacun à une mémoire 40, 41 dans laquelle est enregistrée pour chaque utilisateur connu de ce serveur, une information 42, 43 d'authentification. Chaque information d'authentification contient le niveau d'authentification disponible pour l'utilisateur correspondant. Chaque serveur d'authentification 24, 26 comporte également un module 44 de contrôle d'accès. Ce module permet aux serveurs 24 et 26 d'émettre une requête d'authentification active de manière à interroger l'utilisateur du poste 10 pour que celui-ci fournisse un jeu d'informations permettant de l'identifier et de l'authentifier avec un niveau d'authentification souhaité. Un jeu d'informations est, par exemple, un identificateur de l'utilisateur et son mot de passe. Ces serveurs d'authentification sont connus sous les termes anglais "Identity provider". Le fournisseur d'accès 12 est capable de remplir les fonctions classiques d'un fournisseur d'accès internet, c'est-à-dire notamment d'affecter une adresse réseau au poste 10 pour que celui-ci puisse naviguer sur le réseau 4. A cet effet, il comporte un serveur proxy HTTP (Hyper Text Transfer Protocol) et un serveur 52 de contrôle d'accès. Le protocole HTTP existant est un protocole de communication utilisé pour les échanges de données entre des clients HTTP et des serveurs HTTP connus sous les termes de serveur web. Le serveur proxy est placé en coupure de flux entre le poste 10 et le réseau 4, c'est-à-dire que l'ensemble des flux d'informations échangés entre le navigateur 16 du poste 10 et le réseau 4 passe par l'intermédiaire du serveur proxy 50. Ainsi, le serveur proxy 50 voit passer l'ensemble des requêtes et des réponses HTTP émises par le poste 10 ou vers le poste 10. Le serveur de contrôle d'accès 52 est capable d'identifier et d'authentifier l'utilisateur du poste 10 avant d'autoriser ce poste 10 à se connecter au réseau 4 et à naviguer sur celui-ci. Typiquement, l'utilisateu r du poste 10 s'identifie auprès du serveur 52 en fournissant un jeu d'informations contenant un identificateur connu sous le terme anglais de "login" et un mot de passe. Si l'utilisateur est correctement identifié et authentifié, c'est-à-dire que le jeu informations qu'il a fourni correspond à un abonnement valide auprès de ce fournisseur d'accès, le serveur 52 affecte à cet utilisateur une adresse réseau, c'est-à-dire ici une adresse IP (Internet Protocol) pour naviguer sur le réseau 4. Dans le cas contraire, le serveur 52 interdit toute connexion au réseau 4. Le serveur 52 est également capable d'enregistrer dans une mémoire 54 à laquelle il est associé une liste 56 contenant pour chaque adresse IP affectée à un utilisateur, l'identificateur de l'utilisateur correspondant. Cette liste est mise à jour automatiquement par le serveur 52. Le fournisseur d'accès 12 comporte un serveur iCAP 60 (Internet
Content Adaptation Protocol) placé à côté du serveur 50 et raccordé à celui-ci par l'intermédiaire d'une liaison filaire 62 ou d'un réseau local. Le protocole iCAP existant est normalisé par l'organisme IETF (Internet Engineering Task Force) pour la transformation systématique de contenus sur Internet. Ainsi, le serveur 60 et le serveur 50 sont capables de communiquer l'un avec l'autre en mettant en œuvre le protocole iCAP. Plus précisément, le serveur 50 est apte à communiquer au serveur 60 des requêtes ou des réponses HTTP présentes dans les flux d'informations échangés entre le poste 10 et le réseau 4 et le serveur 60 est également capable de transmettre des requêtes ou des réponses HTTP après les avoir modifiées au serveur 50. De manière à implémenter un client iCAP dans le serveur proxy 50 celui-ci est équipé d'une interface iCAP 64 comportant un connecteur permettant de le raccorder au serveur 60. L'interface 64 est ici configurée pour transmettre au serveur 60 uniquement les requêtes ou les réponses HTTP qui doivent être modifiées pour la mise en œuvre du procédé SSO. Le serveur 60 est équipé d'un module SSO 66 propre à prendre en charge tous les traitements spécifiques requis par la mise en œuvre du procédé
SSO. Ce module 66 comporte trois sous-modules 68, 70 et 72 correspondant chacun à un service iCAP. Ces sous-modules seront décrits plus en détail en regard de chacune des figures 3 et 4. Le serveur 60 est associé à la mémoire 54 qui contient également une liste 76 des serveurs d'authentification connus par chaque utilisateur. Cette liste 76 regroupe pour chaque utilisateur, les identificateurs des différents serveurs d'authentification dans lesquels sont mémorisées des informations d'authentification pour cet utilisateur. Le serveur 60 implémente aussi un client HTTP. A cet effet, il est raccordé au réseau 4 par l'intermédiaire d'un serveur proxy HTTP supplémentaire 74 qui peut être indépendant et distinct du serveur proxy 50. L'ensemble des serveurs du système 2 sont réalisés à partir de calculateurs électroniques conventionnels programmables aptes à exécuter des instructions enregistrées sur un support d'enregistrement d'informations. A cet effet, les mémoires 30, 40, 41 et 54 comportent des instructions pour l'exécution du procédé SSO des figures 2 à 4 lorsque lesdites instructions sont exécutées par ces calculateurs. Le fonctionnement du système 2 va maintenant être décrit en regard des figures 2 à 4. Initialement, lors d'une étape 90, un identificateur du serveur 24 est enregistré dans la liste 76 des serveurs d'authentification connus par l'utilisateur. Parallèlement, lors d'une étape 92, les listes 34 des fournisseurs de services sont mises à jour. Ensuite, l'utilisateur du poste 10 se connecte, lors d'une étape 94, au réseau 4. Lors de cette étape, l'utilisateur saisit, lors d'une opération 96, un jeu d'informations permettant de l'identifier et de l'authentifier auprès du serveur 52. Une fois que l'utilisateur 10 a été identifié et authentifié, le serveur
52, lors d'une opération 98, lui affecte une adresse IP et enregistre la relation entre cette adresse réseau et l'identificateur de cet utilisateur dans la liste 56. Ensuite, le serveur 52 informe, lors d'une opération 100, les différents serveurs d'authentification connus par cet utilisateur que celui-ci a été correctement identifié et authentifié. Cette identification et authentification réalisée par le serveur 52 est ici associée à un niveau d'authentification égal à
"2" de sorte que les serveurs d'authentification mémorisent que le niveau d'authentification disponible est égal à "2". Une fois autorisé à naviguer sur le réseau 4, l'utilisateur se connecte, par exemple, lors d'une étape 104, au fournisseur de services 20. Le module 32 du fournisseur 20 émet alors en réponse, lors d'une opération 106, une requête d'authentification HTTP incluse dans une réponse HTTP à destination du poste
10. Cette requête est interceptée par le serveur proxy 50 puis traitée par le serveur iCAP 60 et enfin transmise jusqu'au serveur d'authentification 24. Cette requête d'authentification comporte le niveau d'authentification 36. Le serveur
24 vérifie, lors d'une étape 108, que le niveau d'authentification disponible pour cet utilisateur est au moins égal à "2". Ici, le niveau d'authentification disponible étant égal à celui requis par le fournisseur 20, le serveur 24 transmet, lors d'une étape 110, une réponse d'authentification contenant un certificat d'authentification au fournisseur 20. Ce certificat informe le fournisseur 20 que le niveau d'authentification requis est disponible. Le fournisseur 20 ayant reçu le certificat propose alors, lors d'une étape 112, à cet utilisateur un service personnalisé et / ou sécurisé sans que l'utilisateur ait besoin de s'identifier auprès du fournisseur 20. Par exemple, le fournisseur 20 lui propose l'impression d'une feuille de paye comportant son nom. Ensuite, toujours lors de la même connexion, l'utilisateur 10 se connecte en 14 au fournisseur de services 22. Ce fournisseur 22 exécute alors l'opération 106. Toutefois, contrairement au cas précédent, le serveur d'authentification 24 constate que le niveau d'authentification requis par le fournisseur 22 est supérieur à celui actuellement disponible pour cet utilisateur. Le module 44 de contrôle d'accès du serveur 24 procède alors à une étape 120 d'authentification active lors de laquelle il interroge l'utilisateur, de manière à identifier et à authentifier celui-ci avec une qualité d'authentification correspondant au niveau d'authentification "4". Par exemple, le module 44 demande à l'utilisateur de saisir des informations personnelles telles que sa date de naissance. Si l'utilisateur du poste 10 a été correctement identifié et authentifié avec un niveau d'authentification "4", le serveur 24 enregistre le nouveau niveau d'authentification disponible dans sa mémoire 40 et procède à l'étape 110. Ensuite, le fournisseur 22 propose lors d'une étape 122 un service personnalisé et / ou sécurisé à cet utilisateur. Le procédé ci-dessus décrit dans le cas particulier des fournisseurs 20, 22, est alors réitéré au fur et à mesure que l'utilisateur du poste 10 contacte de nouveaux fournisseurs de services. Ainsi, grâce à ce procédé, l'authentification de l'utilisateur est simplifiée puisque celui-ci ne doit s'identifier et s'authentifier que lors de la connexion au réseau 4 puis ensuite à chaque fois qu'il contacte un fournisseur de services exigeant un niveau d'authentification supérieur à celui disponible. Ce procédé permet donc d'éviter à l'utilisateur de saisir, à chaque fois qu'il contacte un nouveau fournisseur de services, un jeu d'informations d'identification et d'authentification correspondant à ce fournisseur de services. Les flux d'informations échangés entre les équipements du système 2 lors des étapes 104 à 122 vont maintenant être décrits plus en détails en regard des figures 3 et 4. Sur les figures 3 et 4 les blocs rectangulaires représentent des équipements ou des listes mémorisées déjà décrites en regard de la figure 1 et portent donc les mêmes références. Les flèches entre ces équipements représentent à la fois le sens de circulation des informations et les opérations correspondantes. Initialement, le navigateur 16 du poste 10 envoie une requête HTTP vers le module 32 d'un fournisseur de services, par exemple le fournisseur 20. Cette requête est acheminée, lors d'une opération 130, jusqu'au serveur proxy 50. L'interface 64 intercepte cette requête et la transmet, lors d'une opération 132, au serveur 60 et plus précisément au sous-module 68. Le sous-module 68 ajoute un en-tête à la requête HTTP indiquant que le système 2 supporte un procédé SSO et retransmet, lors d'une opération 134 cette requête HTTP ainsi modifiée vers le serveur proxy 50. Le serveur proxy transmet alors la requête HTTP modifiée jusqu'au fournisseur de services lors d'une opération 136. Le module 32 du fournisseur de services détecte la présence de l'en- tête ajouté par le sous-module 68 et, en réponse, envoie, lors d'une opération 138, une requête d'authentification vers le navigateur 16. La requête d'authentification est, par exemple, conforme au protocole SOAP (Single Object Access Protocol) normalisé par l'organisme W3C (World Wide Web Consortium). Cette requête d'authentification comporte notamment un identifiant du fournisseur de services, une copie de la liste 34 de serveurs d'authentification connus, le niveau d'authentification requis par ce fournisseur et, par exemple, une instruction connue sous les termes anglais "set cookie" destinée à enregistrer un identificateur de la requête d'authentification sur le poste 10 ou, en variante, directement un identifiant de la requête. L'interface 64 du serveur proxy 50 intercepte cette requête d'authentification et la dirige, lors d'une opération 140, vers le sous-module 70 du serveur 60. Le sous-module 70 compare, lors d'une opération 142, la liste 34 reçue à la liste 56 pour sélectionner le serveur d'authentification à contacter, par exemple, ici le serveur 24. S'il n'existe aucun serveur d'authentification commun à la liste 34 reçue et à la liste 56, le sous-module 70 envoie un message d'incompatibilité au fournisseur de services ayant émis la requête d'authentification. Ce message d'incompatibilité comporte l'identificateur de la requête d'authentification, de manière à ce que le module 32 puisse relier cette réponse à la requête d'authentification correspondante. L'identificateur de la requête d'authentification est, par exemple, celui contenu dans l'instruction "set cookie". Ensuite, le sous-module 70 détermine, lors d'une opération 144, l'identité de l'utilisateur du poste 10 en comparant l'adresse réseau du poste 10 à la liste 76. Cette adresse aura été fournie par le serveur proxy 50 au sous- module 70 lors de l'opération 140 par l'intermédiaire d'un champ de l'en-tête HTTP. Une fois l'utilisateur identifié, le sous-module 70 procède à une opération 148 de transmission de la requête d'authentification reçue associée à l'identificateur de l'utilisateur obtenu lors de l'opération 144, au serveur d'authentification sélectionné lors de l'opération 142. Le serveur 24 compare, lors d'une opération 150, le niveau d'authentification disponible pour l'utilisateur à celui requis par le fournisseur de services. Dans le cas où le niveau d'authentification requis est supérieur à celui actuellement enregistré par le serveur 24, celui-ci procède comme décrit en regard de la figure 4. Dans le cas contraire, le serveur 24 envoie lors d'une opération 152, une réponse d'authentification au serveur 60. Le sous-module 70 reçoit la réponse d'authentification et la transmet, lors d'une opération 156, vers le fournisseur de services par l'intermédiaire du serveur proxy 74 et en utilisant le protocole HTTP. Cette réponse d'authentification comporte si nécessaire un identificateur de l'utilisateur. Le fournisseur de services répond à cette réponse d'authentification en transmettant vers le serveur 60, lors d'une opération 158, par exemple, une page d'accueil personnalisée. Cette réponse est transmise par l'intermédiaire du serveur proxy 74 au serveur 60 en utilisant le protocole HTTP. Le sous-module 70 redirige, lors d'une opération 160, cette réponse vers le serveur proxy 50 en utilisant le protocole iCAP qui la redirige, à son tour, lors d'une opération 162, vers le navigateur 16 en utilisanMe protocole HTTP. Ainsi, une page d'accueil personnalisée s'affiche sur le navigateur 16 de l'utilisateur du poste 10 sans même que cet utilisateur ait eu besoin de s'identifier auprès, par exemple, du fournisseur 20. La figure 4 représente la circulation des informations entre les différents équipements du système 2 dans le cas particulier où le niveau d'authentification requis par le fournisseur de services contacté est supérieur à celui actuellement mémorisé dans la mémoire 40 du serveur 24. Sur cette figure, les équipements et les opérations déjà décrits en regard des figures 1 et 3 portent les mêmes références et les nouvelles opérations sont représentées en traits gras. Lors de l'opération 150, le serveur 24 a établi que le niveau d'authentification requis est supérieur à celui actuellement disponible pour l'utilisateur. Par conséquent, il procède à une opération 180 lors de laquelle le module 44 transmet une requête d'authentification active vers le serveur 60 contenue dans une réponse HTTP et en utilisant le protocole HTTP. La requête d'authentification active est destinée à activer sur le navigateur 16 un processus d'authentification interactif. A cet effet, cette requête comporte ici un formulaire à compléter par l'utilisateur. Le sous-module 70 retransmet lors d'une opération 182, cette requête d'authentification active vers le serveur proxy 50 en utilisant le protocole iCAP, puis le serveur proxy 50 la retransmet, lors d'une opération 184, vers le navigateur 16 en utilisant le protocole HTTP. Le navigateur 16 affiche le formulaire qui permet à l'utilisateur de s'identifier et de s'authentifier avec un niveau d'authentification supérieur, par exemple, égal à "4" dans le cas du fournisseur de services 22. Une fois que le formulaire a été complété, le navigateur 16 envoie, lors d'une opération 186, la réponse dans une requête HTTP. Cette réponse est interceptée par l'interface 64 du serveur 50 et transmise, lors d'une opération 188, au sous-module 72 en utilisant le protocole iCAP. Le sous-module 72 retransmet alors, lors d'une opération 190, la réponse de l'utilisateur en utilisant le protocole HTTP au serveur 24. Si le formulaire a correctement été complété par l'utilisateur, c'est-à-dire que le jeu d'informations d'identification et d'authentification est correcte, le serveur 24 mémorise, lors d'une opération 192, le nouveau niveau d'authentification disponible dans la mémoire 40 et procède ensuite à l'opération 152. Les opérations suivantes sont identiques à celles décrites en regard de la figure 2 à l'exception du fait que les opérations 152, 156, 158 et 160 font intervenir le sous-module 72 à la place du sous-module 70. La plupart des serveurs proxy existant comportent déjà une interface iCAP. Ainsi, le système de la figure 2 simplifie la mise en œuvre du procédé SSO puisque la seule modification à apporter au serveur proxy consiste à le configurer de manière à ce que l'interface iCAP intercepte les requêtes HTTP nécessaires à la mise en œuvre de ce procédé. La circulation des flux d'informations entre les différents éléments du système 2 a été décrite dans le cas particulier où le serveur iCAP 60 communique directement en utilisant le protocole HTTP avec le ou les fournisseurs de services lors des opérations 156 et 158. En variante, le serveur iCAP communique avec les fournisseurs de services uniquement par l'intermédiaire du protocole iCAP. Par exemple, dans cette variante, les requêtes HTTP émises à destination du fournisseur de services lors de l'opération 156 sont d'abord transmises par le serveur 60 jusqu'au serveur proxy 50 en utilisant le protocole iCAP puis le serveur proxy 50 transmet ces requêtes au fournisseur de services en utilisant le protocole HTTP. La réponse HTTP émise par le fournisseur de services lors de l'opération 158 suit le chemin inverse de la requête émise lors de l'opération 156. Dans cette variante, le serveur 60 ne communique jamais directement avec les fournisseurs de services de sorte que ceux-ci ne sont pas au courant de l'existence du serveur 60. L'utilisation du serveur 60 est alors totalement transparente pour ces fournisseurs de services. Cette variante présente l'avantage que du point de vue du fournisseur de services, tous les échanges d'informations se font entre lui et l'utilisateur sans avoir connaissance de l'existence du serveur 60. Cette variante présente également l'avantage que les requêtes HTTP émises et reçues lors des opérations 156 et 158 sont directement échangées avec le serveur proxy 50 et non plus par l'intermédiaire du sous-module 70 ce qui accélère le traitement de ces opérations. Les sous-modules 68 à 72 ont été décrits dans le cas particulier où ils sont tous implémentés dans le même serveur iCAP 60. En variante, ces sous-modules sont chacun implémentés dans un serveur iCAP indépendant des autres. Ici, l'interface 64 est configurée pour n'intercepter que les requêtes HTTP qui doivent être traitées par le serveur iCAP. En variante, l'interface 64 est configurée pour rediriger tous les flux d'informations HTTP vers le serveur iCAP et le serveur iCAP implémente un module de filtrage propre à envoyer au module de traitement 66 uniquement les requêtes HTTP qui doivent être traitées par ce module. Ainsi, dans cette variante, l'interception des requêtes HTTP n'est pas réalisée par le serveur proxy 50 mais par le serveur iCAP. Le système 2 a été représenté dans le cas particulier où les serveurs d'authentification sont raccordés au fournisseur d'accès internet par l'intermédiaire du réseau 4. En variante, au moins l'un de ces serveurs d'authentification est logé chez le fournisseur d'accès internet et raccordé à celui-ci par l'intermédiaire d'un réseau local indépendant du réseau 4. Ce mode de mise en œuvre avantageux lui permettra de bénéficier de toutes les identifications / authentifications réalisées par le fournisseur d'accès et qui ne pourraient être partagées avec des fournisseurs d'authentification externes pour des raisons de sécurité; De même, en variante, le serveur iCAP est raccordé au serveur proxy 50 par l'intermédiaire d'un réseau grande distance et non plus par l'intermédiaire d'une liaison ou d'un réseau local. Le système 2 a été décrit dans le cas particulier où la première authentification de chaque utilisateur est réalisée par le fournisseur d'accès internet 12. En variante, cette première authentification n'est plus réalisée par le fournisseur d'accès internet 12 mais, par exemple, par le premier fournisseur de services contacté par l'utilisateur. L'identification et l'authentification de l'utilisateur ont été décrites dans le cas particulier où celle-ci se fait à partir d'un terminal 10 équipé d'un écran et d'un clavier ce qui permet de saisir un jeu d'informations d'identification et d'authentification. En variante, la première identification et authentification de l'utilisateur est réalisée automatiquement, par exemple, en identifiant le terminal utilisé par cet utilisateur. Plus précisément, lorsque le terminal 10 est remplacé par un téléphone mobile, l'identification et l'authentification de l'utilisateur se font automatiquement en procédant à l'acquisition du numéro de téléphone du terminal. Dans ce cas, l'authentification est dite transparente. Le système 2 a également été décrit dans le cas particulier où les serveurs d'authentification mémorisent uniquement le niveau d'authentification disponible pour chaque utilisateur ce qui renforce la sécurité du système puisqu'il n'est pas désirable que l'ensemble des mots de passe et autres informations secrètes de l'utilisateur soient enregistrés dans un même lieu. Toutefois, en variante, ces serveurs d'authentification mémorisent également en tant qu'informations d'authentification le ou les jeux d'informations d'identification et d'authentification que chaque utilisateur est susceptible d'utiliser pour s'identifier et s'authentifier auprès de chaque fournisseur de services. Ainsi, dans cette variante, la réponse d'authentification comporte le jeu d'informations d'identification et d'authentification à transmettre au fournisseur de services pour que celui-ci identifie et authentifie l'utilisateur. Ce jeu d'informations d'identification et d'authentification est transmis au fournisseur de services de façon similaire a ce qui a été décrit pour le certificat d'authentification. Le système 2 a été décrit dans le cas particulier où la requête d'authentification émise par chaque fournisseur de services comporte un niveau d'authentification. En variante, la requête d'authentification émise par l'un des fournisseurs de services ne comporte pas de niveau d'authentification. Dans cette variante, en réponse à cette requête d'authentification, le serveur d'authentification contacté fournit, en réponse, un certificat d'authentification indiquant simplement que l'utilisateur a été authentifié. Ainsi, dans cette variante, l'utilisateur aura accès aux services du fournisseur de services à partir du moment où il a été authentifié au moins une fois et ceci quel que soit le niveau de cette authentification. Le système 2 a été décrit dans le cas particulier où le réseau 4 est le réseau internet. Toutefois en variante, ce réseau 4 est un réseau de transmission d'informations quelconque tel qu'un réseau local, un réseau à commutation de paquets quelconque ou un réseau à commutation de circuits. Le système 2 a été décrit dans le cas particulier où les serveurs d'authentification sont aptes à émettre des requêtes d'authentification actives lorsque ceux-ci ne disposent pas d'une authentification satisfaisante pour l'utilisateur. En variante, les serveurs d'authentification ne sont pas aptes à émettre ces requêtes d'authentification actives. Dès lors, dans cette variante, lorsqu'un serveur d'authentification est contacté alors qu'il ne possède, par exemple, aucune information d'authentification sur l'utilisateur, il est apte à émettre un message d'erreur à la place d'une requête d'authentification active. Finalement, le système 2 a été décrit dans le cas particulier où le protocole de transfert de flux HTTP est le protocole iCAP. En variante, le protocole iCAP peut être remplacé par tout autre protocole de transfert de flux HTTP tel que par exemple le protocole OCP (OPES Call Out Protocol) avec OPES (Open Pluggable Edge Services). Le système 2 a été défini en faisant référence aux recommandations établies par Liberty Alliance. Toutefois, l'invention revendiquée n'est pas limitée aux systèmes et aux procédés conformes aux recommandations de Liberty Alliance et s'applique à tout système ou procédé présentant des fonctionnalités similaires à celles décrites ici.

Claims

REVENDICATIONS
1. Système d'accès à un réseau (4) à commutation de paquets adapté pour la mise en œuvre d'un procédé à signature simplifiée, ce système comportant : - un serveur proxy (50) par lequel passent tous les flux d'informations échangés entre un utilisateur et ledit réseau, - plusieurs fournisseurs (20, 22) de services raccordés audit réseau (4), chaque fournisseur de services étant apte à émettre une requête d'authentification vers l'utilisateur qui le contacte pour identifier et/ou authentifier cet utilisateur avant de lui fournir des services personnalisés et/ou sécurisés, la réponse à fournir par un même utilisateur à cette requête d'authentification pouvant être différente en fonction du fournisseur de services contacté, - au moins un serveur d'authentification (24, 26) propre à mémoriser au moins une information d'authentification pour chaque utilisateur et à transmettre en réponse à une requête d'authentification une réponse d'authentification contenant une information d'authentification fonction à la fois du fournisseur de services ayant émis la requête d'authentification, et de l'identité de l'utilisateur ayant contacté ce fournisseur de services, et - un module (66) à signature simplifiée apte à traiter automatiquement en lieu et place de l'utilisateur les requêtes d'authentification émises par les fournisseurs de services contactés, ce module étant apte pour chaque utilisateur : - à diriger les requêtes d'authentification vers le serveur d'authentification (24, 26) approprié, et - à retransmettre au fournisseur de services la réponse T d'authentification correspondante transmise par le serveur d'authentification approprié, caractérisé en ce qu'il comporte un serveur supplémentaire (60) indépendant du serveur proxy (50), le module à signature simplifiée (66) étant implémente dans ce serveur supplémentaire (60), et en ce que le serveur proxy (50) est équipé d'une interface (64) permettant de le raccorder au serveur supplémentaire (60) et de transmettre au moins les requêtes d'authentification émises par les fournisseurs de services contactés audit serveur supplémentaire (60) pour traitement de ces requêtes par le module à signature simplifiée (66).
2. Système selon la revendication 1 , caractérisé en ce que le module à signature simplifiée (66) comporte un sous-module (70) propre à identifier l'utilisateur à partir de son adresse réseau et à ajouter un identificateur de l'utilisateur aux requêtes d'authentification dirigées vers les serveurs d'authentification.
3. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une information d'authentification mémorisée pour chaque utilisateur comprend une information sur un niveau d'authentification disponible pour cet utilisateur, en ce que chaque requête d'authentification émise par un fournisseur de services (20, 22) spécifie des caractéristiques sur le niveau d'authentification requis par ce fournisseur de services pour pouvoir accéder aux services qu'il propose, en ce que le ou chaque serveur d'authentification (24, 26) est apte à comparer les caractéristiques sur le niveau d'authentification requis spécifié par la requête d'authentification à l'information sur le niveau d'authentification disponible, de manière à déterminer si le niveau d'authentification requis correspond au niveau d'authentification disponible pour cet utilisateur, et en ce que le ou chaque serveur d'authentification (24, 26) est apte à émettre vers l'utilisateur une requête d'authentification active propre à activer un processus interactif d'identification et/ou d'authentification de l'utilisateur si le niveau d'authentification requis ne correspond pas au niveau d'authentification disponible.
4. Système selon la revendication 3, caractérisé en ce que le serveur supplémentaire (60) comporte un sous-module (72) propre à diriger la réponse de l'utilisateur aux requêtes d'authentification active vers le serveur d'authentification qui l'a émise.
5. Système selon la revendication 3 ou 4 caractérisé en ce que le serveur supplémentaire comporte un sous modu le (70) propre à diriger la requête d'authentification active vers l'utilisateur.
6. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le module à signature simplifiée (66) comporte un sous- module (68) capable d'ajouter aux requêtes transmises par l'utilisateur vers un fournisseur de services un signal d'identification de service à signature simplifiée en réponse auquel le fournisseur de services émet la requête d'authentification.
7. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur supplémentaire (60) et le serveur proxy (50) sont aptes à communiquer l'un avec l 'autre en mettant en œuvre un protocole de transfert de flux HTTP (Hyper Text Transfer Protocol).
8. Système selon la revendication 7, caractérisé en ce que le protocole de transfert de flux HTTP est le protocole iCAP (Internet Content Adaptation Protocol) ou le protocole OCP (OPES Call Out Protocol).
9. Système selon la revendication 7 ou 8, caractérisé en ce que le serveur supplémentaire (60) est uniquement apte à communiquer avec les fournisseurs de services par l'intermédiaire du protocole de transfert de flux HTTP mis en œuvre entre lui et le serveur proxy (50).
10. Système selon l'une quelconque des revendications 1 à 8, caractérisé en ce que le serveur supplémentaire (60) implémente également un serveur et/ou un client HTTP (Hyper Text Transfer Protocol) pour communiquer directement avec le ou chaque fournisseur de services et/ou le ou chaque serveur d'authentification uniquement à l'aide du protocole HTTP.
11. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte un fournisseur d'accès (12) audit réseau (4) auquel doit se connecter l'utilisateur pour pouvoir accéder audit réseau, ce fournisseur d'accès étant équipé du serveur proxy (50).
12. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit réseau est la toile d'araignée mondiale.
13. Serveur supplémentaire apte à être mis en œuvre dans un système conforme à l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte le module à signature simplifiée (66) apte à traiter automatiquement en lieu et place de l'utilisateur les requêtes d'authentification émises par le ou chaque fournisseur de services contacté, et est apte à communiquer avec un serveur proxy (50) pour recevoir au moins les requêtes d'authentification émises par les fournisseurs de services.
PCT/FR2004/002272 2003-09-23 2004-09-07 Systeme d'acces a un reseau adapte pour la mise en oeuvre d'un procede a signature simplifiee, et serveur pour sa realisation WO2005034468A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/572,949 US7823188B2 (en) 2003-09-23 2004-09-07 Network access system which is adapted for the use of a simplified signature method, and server used to implement same
EP04787325A EP1668868A1 (fr) 2003-09-23 2004-09-07 Systeme d acces a un reseau adapte pour la mise en oeuvre d'un procede a signature simplifiee, et serveur pour sa realisation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0311153 2003-09-23
FR0311153A FR2860111A1 (fr) 2003-09-23 2003-09-23 Systeme d'acces a un reseau adapte pour la mise en oeuvre d'un procede a signature simplifiee, et serveur pour sa realisation

Publications (1)

Publication Number Publication Date
WO2005034468A1 true WO2005034468A1 (fr) 2005-04-14

Family

ID=34224427

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/002272 WO2005034468A1 (fr) 2003-09-23 2004-09-07 Systeme d'acces a un reseau adapte pour la mise en oeuvre d'un procede a signature simplifiee, et serveur pour sa realisation

Country Status (4)

Country Link
US (1) US7823188B2 (fr)
EP (1) EP1668868A1 (fr)
FR (1) FR2860111A1 (fr)
WO (1) WO2005034468A1 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2893208A1 (fr) * 2005-11-09 2007-05-11 France Telecom Procede et dispositif de fourniture d'un alias de federation d'identite reseau a un fournisseur de service
DE102007007345A1 (de) * 2007-02-14 2008-08-21 Siemens Enterprise Communications Gmbh & Co. Kg Verfahren und Anordnung zum Bereitstellen eines drahtlosen Mesh-Netzwerks
US20090064291A1 (en) * 2007-08-28 2009-03-05 Mark Frederick Wahl System and method for relaying authentication at network attachment
US8353052B2 (en) * 2007-09-03 2013-01-08 Sony Mobile Communications Ab Providing services to a guest device in a personal network
US8856908B2 (en) * 2009-02-12 2014-10-07 Comcast Cable Communications, Llc Management and delivery of profile data
US20100228987A1 (en) * 2009-03-06 2010-09-09 Sony Corporation System and method for securing information using remote access control and data encryption
US8327434B2 (en) * 2009-08-14 2012-12-04 Novell, Inc. System and method for implementing a proxy authentication server to provide authentication for resources not located behind the proxy authentication server
US10079864B2 (en) * 2012-01-06 2018-09-18 Microsoft Technology Licensing, Llc Communicating media data
US9369282B2 (en) * 2014-01-29 2016-06-14 Red Hat, Inc. Mobile device user authentication for accessing protected network resources
GB2524010A (en) * 2014-03-10 2015-09-16 Ibm User authentication
CN114065186A (zh) * 2021-11-17 2022-02-18 四川启睿克科技有限公司 基于es6实现单点登录和子系统登录自动切换的方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001080067A1 (fr) * 2000-04-14 2001-10-25 Yodlee.Com, Inc. Procede et appareil pour assurer l'acces des services d'enregistrement automatique a des sites internet pour des abonnes a des portails internet
US6317838B1 (en) * 1998-04-29 2001-11-13 Bull S.A. Method and architecture to provide a secured remote access to private resources
US20020007460A1 (en) * 2000-07-14 2002-01-17 Nec Corporation Single sign-on system and single sign-on method for a web site and recording medium

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5923756A (en) * 1997-02-12 1999-07-13 Gte Laboratories Incorporated Method for providing secure remote command execution over an insecure computer network
US6584505B1 (en) * 1999-07-08 2003-06-24 Microsoft Corporation Authenticating access to a network server without communicating login information through the network server
EP1104133A1 (fr) * 1999-11-29 2001-05-30 BRITISH TELECOMMUNICATIONS public limited company Configuration d'accès à un réseau
JP4626784B2 (ja) * 2000-05-19 2011-02-09 ソニー株式会社 通信装置および通信方法、並びに記録媒体
KR100461734B1 (ko) * 2000-07-24 2004-12-13 유미특허법인 인터넷을 통한 컨텐츠 제공 시스템 및 그 방법
JP2003016295A (ja) * 2001-06-28 2003-01-17 Nec Corp オンラインショッピング方法及びそのシステム並びにプログラム
US20030115142A1 (en) * 2001-12-12 2003-06-19 Intel Corporation Identity authentication portfolio system
US7234158B1 (en) * 2002-04-01 2007-06-19 Microsoft Corporation Separate client state object and user interface domains
JP4309629B2 (ja) * 2002-09-13 2009-08-05 株式会社日立製作所 ネットワークシステム
US7240192B1 (en) * 2003-03-12 2007-07-03 Microsoft Corporation Combining a browser cache and cookies to improve the security of token-based authentication protocols

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6317838B1 (en) * 1998-04-29 2001-11-13 Bull S.A. Method and architecture to provide a secured remote access to private resources
WO2001080067A1 (fr) * 2000-04-14 2001-10-25 Yodlee.Com, Inc. Procede et appareil pour assurer l'acces des services d'enregistrement automatique a des sites internet pour des abonnes a des portails internet
US20020007460A1 (en) * 2000-07-14 2002-01-17 Nec Corporation Single sign-on system and single sign-on method for a web site and recording medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Liberty Architecture Overview, Version 1.1", LIBERTY PROJECT, 15 January 2003 (2003-01-15), XP002246163, Retrieved from the Internet <URL:http://projectliberty.org/specs/archive/v1_1/liberty-architecture-ove rview-v1.1> [retrieved on 20030702] *

Also Published As

Publication number Publication date
US7823188B2 (en) 2010-10-26
US20070056021A1 (en) 2007-03-08
FR2860111A1 (fr) 2005-03-25
EP1668868A1 (fr) 2006-06-14

Similar Documents

Publication Publication Date Title
US9438633B1 (en) System, method and computer program product for providing unified authentication services for online applications
EP3008872B1 (fr) Procédé d&#39;authentification d&#39;un terminal par une passerelle d&#39;un réseau interne protégé par une entité de sécurisation des accès
CN112468481B (zh) 一种基于CAS的单页和多页web应用身份集成认证方法
EP1909462B1 (fr) Procédé de mise à disposition cloisonnée d&#39;un service électronique
EP1891771A1 (fr) Procede de traduction d&#39;un protocole d&#39;authentification
EP1668868A1 (fr) Systeme d acces a un reseau adapte pour la mise en oeuvre d&#39;un procede a signature simplifiee, et serveur pour sa realisation
WO2006010810A2 (fr) Procede et systeme de certification de l’identite d’un utilisateur
EP1227640B1 (fr) Procédé et système de communication d&#39;un certificat entre un module de sécurisation et un serveur
EP1649665A2 (fr) PROCEDE ET SYSTEME DE DOUBLE AUTHENTIFICATION SECURISEE D UN UTILISATEUR LORS DE L ACCES A UN SERVICE PAR L&amp;rsquo;INTERM EDIAIRE D UN RESEAU DE TRANSMISSION DE DONNEES.
FR2844943A1 (fr) Procede de production d&#39;un premier identifiant isolant un utilisateur se connectant a un reseau telematique
CA2403383C (fr) Systeme, procede et produit de programme informatique pour fournir des services d&#39;authentification unifies pour applications en ligne
EP4128700A1 (fr) Procede et dispositif d&#39;authentification d&#39;un utilisateur aupres d&#39;une application
EP4362391A1 (fr) Procédé de gestion d&#39;accès d&#39;un utilisateur à au moins une application, programme d&#39;ordinateur et système associés
FR3017729A1 (fr) Procede d&#39;authentification a distance
FR2862170A1 (fr) Procede de transfert de donnees confidentielles en coeur de reseaux
FR3076638A1 (fr) Procede de gestion d&#39;un acces a une page web d&#39;authentification
WO2002096061A2 (fr) Dispositif de communication electronique securise
FR2825214A1 (fr) Dispositif de communication electronique securise, notamment d&#39;acces electronique securise
WO2007012786A2 (fr) Procede de mise en oeuvre d&#39;une sequence d&#39;authentifications
WO2002089447A2 (fr) Systeme et procede de communication entre stations traitant des dossiers communs
WO2017060624A1 (fr) Moyens de gestion d&#39;accès à des données
FR2741219A1 (fr) Procede de realisation de transfert securise de donnees sur un reseau a serveurs multiples
FR2937816A1 (fr) Procede et fonctionnement d&#39;identification convergente d&#39;utilisateur de reseau de communication

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 BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG 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 NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA 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 HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

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: 2004787325

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007056021

Country of ref document: US

Ref document number: 10572949

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2004787325

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10572949

Country of ref document: US