EP3643035A1 - Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration - Google Patents

Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration

Info

Publication number
EP3643035A1
EP3643035A1 EP18749431.5A EP18749431A EP3643035A1 EP 3643035 A1 EP3643035 A1 EP 3643035A1 EP 18749431 A EP18749431 A EP 18749431A EP 3643035 A1 EP3643035 A1 EP 3643035A1
Authority
EP
European Patent Office
Prior art keywords
terminal
configuration file
request
management server
obtaining
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP18749431.5A
Other languages
German (de)
English (en)
Inventor
Stéphane CAZEAUX
Julien ZIMMERMANN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP3643035A1 publication Critical patent/EP3643035A1/fr
Pending legal-status Critical Current

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos

Definitions

  • the invention relates to the general field of telecommunications.
  • Such a configuration file typically comprises the technical elements enabling a user to take advantage of the communication service via his terminal such as, in particular, a login and a password assigned to the user to connect to the communication service, user parameters (ex. address book, telephone number assigned to it, etc.), and technical parameters intended to be implemented by the terminal during a communication service session (eg audio / video codecs, parameters voice over IP, etc.).
  • the terminal can be fixed or mobile, hardware or software; it may be for example a smartphone (or “smartphone”), a computer, a digital tablet, or a software application (eg "softphone”) seeking access to a service voice over IP, video service, etc.
  • a smartphone or “smartphone”
  • a computer or a digital tablet
  • a software application eg "softphone” seeking access to a service voice over IP, video service, etc.
  • the configuration of a terminal to access a communication service offered by a network is done via the download by the terminal of a configuration file hosted on a remote configuration server (ex. SFST (Secure Shell File Transfer Protocol) or HTTP (HyperText Transfer Protocol) server, using an access address to this file that is configured at the factory in the terminal, this address includes, generically, the address (ex. URL (Uniform Resource Locator)) of the remote server, and the name of the configuration file, which is generated from a technical parameter of the terminal, typically its MAC (Medium Access Control) address.This address is very easy to generate once you know the MAC address of the terminal.
  • SFST Secure Shell File Transfer Protocol
  • HTTP HyperText Transfer Protocol
  • the security measures implemented by the network of Access is usually sufficient to ensure that only a given terminal of a user accesses the configuration file intended for him and no other.
  • a first technique may consist in particular of implementing, prior to obtaining the configuration file by the terminal, mutual authentication between the terminal and the communication service provider, via, for example, the TLS protocol.
  • TLS Transport Layer Security
  • a TLS certificate can be supplied at the factory to the terminal.
  • this TLS certificate can be easily extracted from the terminal and thus compromised for use by a malicious third party device.
  • a second technique may consist in imposing the entry by the user of the terminal, for example at the start of the terminal and prior to its configuration, an identifier and a password specific to the communication service and the user. This second technique, however, imposes a constraint of use on the user which may be difficult to accept in practice by the latter.
  • the invention makes it possible to respond in particular to this need by proposing an automatic configuration mechanism of a terminal which advantageously relies on the existing procedures and reinforces their security via the generation of a secure token specifically for the terminal, triggered as soon as possible. when it is clearly associated with a user, this token used to define a secure address from which the terminal can access its configuration file.
  • the invention relates, according to a first aspect, to a method of controlling the obtaining by a terminal of a configuration file enabling it to access a service, this method being intended to be implemented by a server service management and comprising:
  • the service is a communication service.
  • the invention also relates to a management server of a service, configured to control the obtaining by a terminal of a configuration file allowing it to access the service, the management server comprising:
  • An application module of a default configuration according to which the management server rejects any request to obtain a configuration file by a terminal as long as this terminal is not associated with a user in a database the management server;
  • Modules activated on receipt of a first request for obtaining the configuration file by a terminal comprising a first access address to the configuration file, and comprising:
  • a first verification module configured to check whether the terminal is associated with a user in the database
  • Modules activated upon receipt of a second request from the terminal for obtaining the configuration file comprising the second address, and comprising:
  • a second verification module configured to check whether the secure token included in the second address included in the second obtaining request is valid
  • the terminal attempts a first time to access its configuration file in a conventional manner, by sending a request to the predefined address, "generic" (first address in the sense of the invention) with which it has been previously configured.
  • This first predefined address is for example configured with the MAC (Medium Access Control) address of the terminal, as in the current state of the art.
  • this first predefined address is closed by default: the management server rejects all access requests to its configuration file formulated by the terminal to this address until it has been declared and associated with a user in the management server database, that is, as long as the management server is not able to ensure the legitimacy of the terminal that sends him a request to obtain a configuration file.
  • the management server detects that the terminal is assigned to an identified user in its database, it specifically allocates a secure token from which it advantageously generates a second address, this time specific and therefore also secure that the terminal can then use to access its configuration file.
  • the second address depends on the secure token that has been generated specifically by the management server for the terminal: the very way it is generated, from a secure parameter kept secret except the terminal concerned and not from a deterministic parameter such as the MAC address of the terminal, is enough to secure access to the configuration file.
  • the invention is therefore very simple to implement.
  • the security mechanism proposed by the invention comes in "overlay" of the existing configuration mechanism which consists of the terminal to fetch its configuration file to a predefined address with which it was previously configured.
  • the invention does not require any additional configuration of the terminals.
  • the second address is provided on the fly to the terminal once it has been checked that it was the terminal concerned by the required configuration file.
  • the invention is therefore compatible with any existing industrial solution and does not require any proprietary evolution of the terminals.
  • the implementation of the invention is transparent to the users of the terminals.
  • the secure token is generated for the terminal if the terminal is associated in the database with a parameter allowing access to the configuration file by the terminal.
  • Obtaining a configuration file is necessary when acquiring a new terminal by a user, but it can also be useful during the lifetime of the terminal (for example after a complete reset).
  • An additional parameter provided in the database and allowing or not access to the configuration file by the terminal can easily handle such a situation.
  • the token generated for a terminal is secure.
  • the token can be unpredictably generated. No limitation is attached to how the token is generated unpredictably.
  • an Advanced Encryption Standard (AES) symmetric encryption algorithm can be used which, applied to a string containing for example the MAC address of the terminal and a random key, makes it possible to generate a random and unpredictable token.
  • AES Advanced Encryption Standard
  • the unpredictability of the token also ensures that the second address generated from the token and allowing the terminal to access its configuration file.
  • the generated secure token can advantageously be self-contained (or "self-contained” in the sense that it contains various information making it possible to process the request for obtaining the configuration file, for example a reference time, a user ID, etc.
  • the secure token generated for the terminal may have a predetermined period of validity.
  • the method further comprises following the triggering step, a step of rejecting any new request to obtain the received configuration file comprising the secure token.
  • the management server is configured to accept only one access request to the configuration file. Any subsequent request is rejected. This further increases the security of the configuration mechanism implemented.
  • a parameter denying the terminal access to the configuration file can be positioned in the database.
  • this embodiment makes it possible to guard against attacks that would consist of repeatedly sending the same request to the second address.
  • the triggering step comprises a step of sending a message to a reverse proxy server placed between the terminal and the management server, this message comprising an address of a configuration server adapted to generating or hosting the configuration file, this message being able to trigger a redirection by the inverse proxy server of the second obtaining request to the configuration server to make the configuration file available to the terminal.
  • the reverse proxy server makes it possible to protect the management server and the configuration server, particularly when the terminal uses an unsecured network, such as the public Internet network, to access its configuration file. It is advantageously in a flow cut between the terminal and the management and configuration servers, and intercepts in this respect in particular all requests issued by the terminal.
  • the inverse proxy server also manages access to the configuration file by interacting on the request. the management server, with the configuration server that hosts the terminal configuration file. This avoids direct access to the management server and the configuration server by the terminal, and this in a manner completely transparent to the terminal.
  • the use of such a proxy proxy also makes it easy to implement load balancing solutions for the automatic configuration of the terminals: the inverse proxy may, depending on the unavailability of such or such a configuration server, redirect the terminal's request to a more available and less loaded configuration server.
  • the triggering step comprises redirecting the second obtaining request to a configuration server adapted to generate or hosting the configuration file to make available to the terminal said configuration file.
  • the redirection of the request to the configuration server is performed directly by the management server of the service, without the intervention of the reverse proxy server.
  • the security mechanism proposed by the invention is based, as it is clear from the foregoing, on the service management server which implements the control method according to the invention, but also on the terminal and , in some embodiments, on a reverse proxy server located between the terminal and the management server.
  • the invention also relates to a method for obtaining by a terminal a configuration file enabling it to access a service, this method comprising:
  • the invention also provides a terminal comprising:
  • a first transmission module configured to transmit at least a first request for obtaining a configuration file to access a service, said at least one first obtaining request comprising a first access address to the configuration file;
  • a second transmission module activated on reception in response to the first request for obtaining a second configuration file access address including a token secure generated for the terminal by a service management server, and configured to issue a second request to obtain the configuration file including the second address;
  • a receiving module adapted to receive the configuration file from a configuration server capable of generating or hosting the configuration file.
  • the invention relates to a method of processing requests for obtaining by a terminal of a configuration file to access a service, this method being intended to be implemented by a reverse proxy server placed between the terminal and a service management server, the method comprising:
  • a second step of redirecting a second request from the terminal for obtaining the configuration file comprising a second configuration file access address provided by the management server to the terminal by the intermediate of the reverse proxy server and including a secure token generated by the management server for the terminal.
  • the invention also proposes a reverse proxy server placed between a terminal and a management server of a service, this inverse proxy server comprising:
  • a first redirection module configured to redirect to the management server at least a first request from a terminal for obtaining a configuration file intended to enable said terminal to access the service, said at least a first request for access to the service; obtaining comprising a first access address to the configuration file; and a second redirection module, configured to redirect to the management server a second request from the terminal for obtaining the configuration file, said second obtaining request comprising a second configuration file access address provided by the server; management server to the terminal through the reverse proxy server and including a secure token generated by the management server for the terminal.
  • the inverse proxy server is configured to manage two separate access addresses to the configuration file of the terminal, and redirect the requests relating to these two addresses to the service management server.
  • the method of processing comprises a third step of redirecting the second obtaining request to a configuration server adapted to generate or hosting the configuration file, said third redirection step being triggered following reception. a message from the management server triggering provision of the terminal of the configuration file and including a configuration server address.
  • This third redirection step is totally transparent for the terminal.
  • the server further comprises a third redirection module configured to redirect the second obtaining request to a configuration server adapted to generate or hosting the configuration file, this third redirection module being activated on receiving a message from the management server triggering provision of the terminal of the configuration file and including an address of the configuration server.
  • the invention also aims at a system for controlling the obtaining of a configuration file by a terminal for accessing a service, said system comprising:
  • a service management server according to the invention.
  • An inverse proxy server according to the invention placed between the terminal and the management server;
  • a configuration server capable of generating or hosting the configuration file, and configured to supply the configuration file to the terminal on receipt of a message from the management server or the inverse proxy server.
  • the terminal, the inverse proxy server, the processing method, the method of obtaining and the system according to the invention have advantages similar to those described above for the control method and the management server according to the invention.
  • the different steps of the control method, and / or the method of obtaining and / or the processing method are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a management server or more generally in a computer, this program comprising instructions adapted to the implementing the steps of a control method as described above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a terminal or more generally in a computer, this program comprising instructions adapted to the implementation of the steps a method of obtaining as described above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a reverse proxy server or more generally in a computer, this program comprising instructions adapted to the implementation steps of a method of treatment as described above.
  • Each of the aforementioned programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any what other form is desirable.
  • the invention also relates to a computer readable information or recording medium, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information or recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • control method the processing method, the method of obtaining, the management server, the terminal, the inverse proxy server and the system according to the invention in combination all or some of the aforementioned features.
  • FIG. 1 shows, in its environment, a control system according to the invention
  • FIG. 2 schematically illustrates the hardware architecture of the various elements of the control system represented in FIG. 1;
  • FIG. 3 represents, in the form of a flow diagram, the different steps of a control method, a processing method and a method of obtaining according to the invention as they are implemented respectively.
  • FIG. 1 represents, in its environment, a control system 1 according to the invention, in a particular embodiment.
  • the service is a communication service.
  • the control system 1 is adapted to securely frame the automatic configuration of a terminal 2 of a user U, in accordance with the invention, and more particularly to control the obtaining of by this terminal 2 of a configuration file CFG2 allowing it to access a communication service S.
  • the service S is for example here a telephone service or voice over IP provided by a service provider 3.
  • a configuration file CFG2 making it possible to access such a communication service typically groups together the technical elements enabling the user U to take advantage of the communication service S via his terminal 2, such as in particular a login and a password. pass assigned to the user U to connect to the communication service S, user parameters (eg his address book, the telephone number assigned to him to communicate on the service S, SIP password (Session Initiation Protocol), etc.), as well as technical parameters intended to be implemented by the terminal 2 during a session of the communication service S (eg audio / video codecs, voice over IP parameters, etc.) . It can also contain software or firmwares useful for the benefit of the communication service S.
  • the terminal 2 applies the technical elements contained in the configuration file CFG2 during its sessions. use of the communication service S.
  • obtaining a configuration file is necessary when a user acquires a new terminal, but it may also be necessary during the lifetime of the terminal (for example after a complete reset of the terminal). this one).
  • control system 1 To frame the configuration of the terminal 2 to enable it to access the communication service S, the control system 1 is based, in the embodiment described here, on an architecture comprising various entities, namely:
  • a management server 4 of the communication service S in accordance with the invention, and associated with a database 5, comprising activation data of the service S such as, for example, the users of the service, their telephone numbers; and the terminals associated with them (identified for example via their MAC address), etc. ;
  • a reverse proxy server 7 (also commonly called “reverse proxy"), in accordance with the invention, placed in a flow cut between the terminal 2 and the management server 4 on the one hand, and between the terminal 2 and the server configuration 5 on the other hand.
  • a reverse proxy server is conventionally used in computer networks to secure access from outside and in particular from the public Internet network to one or more servers located in an "internal" network. Any message coming from outside and intended for a server of the internal network protected by the inverse proxy server transits through it, which then redirects to the server of the internal network concerned.
  • the inverse proxy server 7 protects access to the management server 4 and the configuration server 6. It intercepts all the requests sent by the terminal 2 to the management server 4 in particular, and redirects them to this one. In addition, in the embodiment described here, the inverse proxy server 7 also acts as an intermediary between the management server 4 and the configuration server 6 as further detailed.
  • the terminal 2, the management server 4 and the inverse proxy server 7 all have the hardware architecture of a computer 8 as shown schematically and generically in FIG.
  • the computer 8 comprises in particular a processor 9, a read-only memory 10, a random access memory 11, a non-volatile memory 12 and communication means 13 on one or more communication networks interconnecting the terminal 2, the management server 4 , the configuration server 6 and the inverse proxy server 7.
  • the terminal 2, the management server 4, the configuration server 6 and the inverse proxy server 7 communicate with each other by using the http protocol or the HTTPS protocol (between the terminal 2 and the inverse proxy server 7), so that the communication means 13 comprise an http and / or HTTPS protocol stack.
  • any other type of protocol making it possible to access a resource identified by an address can be used by the terminal 2, the server management 4, the configuration server 6 and the reverse proxy server 7, such as FTP (File Transfer Protocol).
  • FTP File Transfer Protocol
  • the ROM 10 of the computer 8 constitutes a recording medium or information according to the invention, readable by the processor 9 and on which is recorded a computer program according to the invention, referenced generically in Figure 2 by PROG.
  • This PROG computer program differs depending on the entity in the ROM from which it is stored.
  • the computer program is a PROG4 program comprising instructions for executing a control method according to the invention of obtaining by the terminal 2 configuration file CFG2 allowing it to access the communication service S.
  • This program PROG4 defines, through its instructions, functional modules of the management server 4 which s' press on and / or control the hardware elements 9-13 of the computer 8 described previously, and which include in particular here as illustrated in FIG.
  • An application module 4A with a default configuration DEF according to which the management server 4 rejects any request to obtain a configuration file by a received terminal until it is associated with a user in its database 5;
  • 4B-4D modules activated on receipt of a request for obtaining by a terminal (for example by the terminal 2) of a configuration file allowing access to the service S, this request called “first request of obtaining "comprising a first URL1 access address to the configuration file.
  • These modules are more particularly:
  • a first verification module 4B configured to check if the terminal at the origin of the first request is associated with a user in the database 5; and o a generation module 4C of a secure token (or token) for the terminal (referenced by TOK2 for the terminal 2); and
  • the generation module 4C and the transmission module 4D are activated if the first verification module 4B determines that the terminal is associated with a user in the database 5;
  • Modules 4E and 4F activated on receipt of a second request from the terminal for obtaining the configuration file comprising the second URL2. These modules 4E and 4F are more particularly:
  • a second verification module 4E configured to check whether the secure token included in the second address included in the second obtaining request is valid
  • a triggering module 4F configured to trigger a provision of the terminal of the configuration file, this 4F module being activated if the second verification module 4E determines that the token is valid.
  • the computer program is a program PROG2 comprising instructions for the execution of a method of obtaining according to the invention by the terminal 2 of the configuration file CFG2 allowing it to access to the communication service S.
  • This program PROG2 defines, by means of its instructions, functional modules of the terminal 2 which rely on and / or control the hardware elements 9-13 of the computer 8 described above, and which include in particular here as illustrated in FIG.
  • a first transmission module 2A configured to transmit at least a first request for obtaining a configuration file to access a communication service, said at least one first obtaining request comprising the first URL access address1 ;
  • a second transmission module 2B activated on reception in response to the first request for obtaining the second URL2 access address including the TOK secure token generated for the terminal by the management server 4, the second module of emission 2B being configured to issue a second request to obtain the configuration file including the second address URL2;
  • a reception module 2C adapted to receive the configuration file CFG2 from the configuration server 6.
  • the computer program is a program PROG7 comprising instructions for the execution of a processing method according to the invention requests to obtain the configuration file CFG2 transmitted by the terminal 2 to be able to access the communication service S.
  • This program PROG7 defines, by means of its instructions, functional modules of the inverse proxy server 7 which rely on and / or control the hardware elements 9-13 of the computer 8 described above, and which include in particular here as illustrated in FIG.
  • a first redirection module 7A configured to redirect to the management server 4 the obtaining requests (first obtaining requests in the sense of the invention) sent by the terminal 2 and comprising the first access address URL1;
  • a second redirection module 7B configured to redirect to the management server 4 the obtaining requests (second obtaining requests in the sense of the invention) sent by the terminal 2 and comprising the second URL2 access address.
  • the program PROG7 also defines by means of its instructions a third redirection module 7C configured to redirect a second obtaining request received from the terminal 2 to the configuration server 6 on receipt of the data. a message from the management server 4 triggering a provision of the terminal 2 of the configuration file CFG2.
  • FIG. 3 represents, in the form of a flow diagram, the main steps implemented, in accordance with the invention, by the terminal 2 and by the control system 1, to secure the automatic configuration of the terminal 2 in order to enable it to access to the communication service S offered by the service provider 3.
  • These steps include the steps of the control method implemented by the management server 4 of the communication service S, the steps of the processing method implemented by the inverse proxy server 7, and the steps of the obtaining method implemented by the terminal 2.
  • This first address URL1 is an access address to the configuration file CFG2 of the terminal 2 within the meaning of the invention. It is predefined generically as in the state of the art, that is to say from a "static" reachability address of the configuration server 6 and the MAC address of the terminal 2, noted here. @ MAC2.
  • the first access address URL1 thus makes it possible to access the configuration server 6 which hosts or generates the configuration files making it possible to access the service S, and to identify on this server the configuration file CFG2 which is adapted to the terminal 2 and its user U (typically which is adapted to the capabilities of the terminal 2, the options subscribed if necessary by the user U as part of the service S, etc.).
  • a first request REQ1 for obtaining the configuration file of the terminal 2 on the first predefined address URL1 with which it was configured at the factory is for example a HTTPS request sent on the URL address1 configured with the address of the configuration server 6 and the @ MAC2 address of the terminal 2.
  • the request REQ1 is intercepted by the inverse proxy server 7, which is configured to redirect, through its first redirection module 4A, the requests comprising the URL1 to the management server 4 (step E20).
  • the management server 4 is configured by default with a rule DEF according to which it rejects any request to obtain by a terminal of a received configuration file (a fortiori, a request for obtaining including the first address URL1 ) as long as this terminal is not associated with a user in its database 5. In other words, access to the configuration is closed to the terminals as they are not declared to the database 5.
  • This default configuration DEF is applied by the application module 4A of the management server 4.
  • the management server 4 Upon receipt of the request REQ1, the management server 4 thus verifies, through its first verification module 4B, whether the terminal 2 at the origin of the request REQ1 is identified in its database 5 and associated with a user (step E30). It uses for this purpose the address @ MAC2 of the terminal 2, present in a standard way in the request REQ1. As a variant, another identifier of the terminal 2 may be used as long as it corresponds to the identifiers used to inform the database 5 or is linked to such an identifier.
  • the management server 4 rejects the REQ1 request from Terminal 2, by example by sending a Forbidden http 403 response message (step E40). This message passes through the inverse proxy server 7 which relays it to the terminal 2 (step E50).
  • the rejection of the request REQ1 can be done via the sending to the terminal 2 of a predefined configuration file making it possible to display on the terminal 2 a message inviting it to configure its communication service S and to declare its terminal 2 to the service provider 3, via for example an administration portal provided for this purpose.
  • step E60 he provides during this declaration a user identifier and an identifier of his terminal 2 , here the MAC @ MAC2 address of the terminal 2.
  • a user identifier and an identifier of his terminal 2 here the MAC @ MAC2 address of the terminal 2.
  • Alternatively, another type of identifier can be envisaged since it allows to identify and recognize the terminal 2 from its requests.
  • This event triggers an update of the database 5 of the management server 4 (step E70); more precisely, following this declaration, the terminal 2 is associated, via its MAC @ MAC2 address, with the user U who has registered with the service provider 3 to benefit from the communication service S. This update triggers the regeneration of a SIP password for the terminal 2.
  • the user U is prompted to restart his terminal 2 to begin his configuration in order to access the communication service S.
  • the terminal 2 sends via its transmitting module 2A and its communication means 13, a new request for obtaining REQ1 'of its configuration file.
  • This request REQ1 ' is a first request within the meaning of the invention.
  • the request REQ1 ' is intercepted by the inverse proxy server 7 which, via its redirection module 7A, redirects it to the management server 4 (step E100).
  • the management server 4 On receiving the request REQ1 ', the management server 4 checks, through its first verification module 4B, if the terminal 2 at the origin of the request REQ1' is identified in its database 5 and associated to a user (step E110). It uses for this purpose the address @ MAC2 of the terminal 2, contained in the request REQ1 '.
  • the terminal 2 is registered in the database 5 in association with the user U.
  • the verification module 4B thus determines, during its interrogation of the base 5, the terminal 2 is associated with a user (U) in the database 5 and can be configured.
  • the management server 4 through its generation module 4C, then generates a TOK2 secure token for the terminal 2 (step E120).
  • a token is in the form of a character string having a predefined dimension. This dimension may vary typically between 50 and 300 characters depending on the implementations. However, these values are given for illustrative purposes only and are not limiting in themselves.
  • the generation module 4C uses, for example, the AES encryption algorithm, applied to a string of characters consisting of the MAC @ MAC2 address of the terminal 2 and a random event which may include a time stamp ( or "timestamp" in English) to ensure the uniqueness of the generated token and prevent its reuse.
  • the AES encryption algorithm applied to a string of characters consisting of the MAC @ MAC2 address of the terminal 2 and a random event which may include a time stamp ( or "timestamp" in English) to ensure the uniqueness of the generated token and prevent its reuse.
  • the secure token thus generated is advantageously random and unpredictable. It is dedicated to terminal 2 and only to this terminal. For example :
  • TOK2 'EkRooesmoe56razazeg87ARu ii prea pr'
  • the management server 4 stores it in its database 5, in association with the identifier @ MAC2 of the terminal 2. In the embodiment described here, it allocates the TOK2 token a limited, predefined validity period (for example 1h). ).
  • the token TOK2 can be stored in another storage space than the database 5 in association with the address @ MAC2 of the terminal 2, for example in the non-volatile memory 12 of the management server 4.
  • the management server 4 stores only the hazard that made it possible to generate the token TOK2 in association with the address @ MAC2, the token TOK2 being able to be easily regenerated from this randomness.
  • This URL2 address is here of the following form:
  • the second address URL2 is for example:
  • URL2 https: //configuration.serviceS.com/EkRooesmoe56razazeg87ARuiipreapr/@MAC2.cfg
  • the management server 4 via its 4D transmission module and its communication means 13, sends the second URL2 address thus generated to destination of the terminal 2, in a response message http 200 to its request REQ1 '(step E130).
  • the address URL2 is a second access address to the configuration file of the terminal 2 within the meaning of the invention.
  • TOK2 passes through the inverse proxy server 7, which relays it to the terminal 2 (step E140).
  • the reception of the second URL2 triggers the sending by the terminal 2 via its second transmission module 2B and its communication means 13, a new request to obtain REQ2 of its configuration file, this time including the URL2 and token TOK2 included in this address (step E150).
  • the REQ2 request is for example here a GET request on the URL2 address.
  • the REQ2 request is intercepted by the inverse proxy server 7, which upon detection of the URL2 addresses it via its second redirection module 7A to the management server 4 (step El 60).
  • the management server 4 On receipt of the REQ2 request, the management server 4, via its second verification module 4E, extracts the TOK2 token from the URL2 address. Then the verification module 4E interrogates the database 5 to check the validity of the TOK2 token, ie if it exists, is well associated with the terminal 2 (that is to say at its MAC @ MAC2 address present in the URL2), and is valid (step E170). It is assumed here that the tokens that are no longer valid are deleted from the database 5.
  • the management server 4 via its trigger module 4F, triggers the provision of the terminal 2 of its configuration file CFG2 to access the communication service S (step E180).
  • the management server 4 for example sends to the terminal 2 a Forbidden HTTP 403 message as described previously in step E40.
  • the provision of the terminal 2 of its configuration file results in the sending by the management server 4 via its trigger module 4F and its communication means 13, a message http 302 to the inverse proxy server 7.
  • This message requires the redirection of the REQ2 request sent by the terminal 2 to the configuration server 6 so that the terminal 2 can access its configuration file CFG2. It contains, in the "Location" field of its header, a URL6-CFG2 address comprising a static part corresponding to the reachability address denoted URL6 of the configuration server 6, and a dynamic part corresponding to the MAC @ MAC2 address of the terminal 2.
  • the provision of the terminal 2 of its configuration file results in the redirection by the management server 4, via its trigger module 4F and its communication means 13, from the REQ2 request to the server configuration 6 so that it makes available to the terminal 2 its CFG2 configuration file.
  • the management server 4 is configured to reject any new receive request received containing the TOK2 secure token allocated to the terminal 2. This step is however optional.
  • a parameter indicating whether the obtaining of a configuration file is authorized or not can be recorded in the database 5 in association with the identifier of the terminal 2 and that of the associated user U.
  • This parameter can be typically updated manually via a human-machine interface (HMI). If obtaining the configuration file is not allowed, everything happens as if the terminal was not associated with the user.
  • Reception by the inverse proxy server 7 of the message http 302 containing the URL6-CFG2 triggers the redirection by the third redirection module 7C of the inverse proxy server 7 of the obtaining request REQ2 of the terminal 2 to the configuration server 6 (step 190).
  • this redirection is carried out here by sending by the redirection module 7C, to the configuration server 6, the request REQ2 in which the URL2 has been replaced by the URL6-CFG2 (referenced by REQ2 '(URL6-CFG2) in Figure 3) to obtain the CFG2 configuration file.
  • the configuration server 6 Upon receipt of the obtaining request REQ2 ', the configuration server 6 dynamically generates, in a manner known per se, the configuration file CFG2 adapted to the terminal 2 and allowing it to access the communication service S (step E200). To generate such a file, the configuration server 6 has, for example templates ("templates”) or programs pre-generated and pre-registered for different types of terminals. It uses the model or the program corresponding to the terminal 2, as well as the parameters of the user U and the terminal 2.
  • templates templates
  • programs pre-generated and pre-registered for different types of terminals. It uses the model or the program corresponding to the terminal 2, as well as the parameters of the user U and the terminal 2.
  • such a configuration file 2 is generated in advance and hosted by the configuration server 6.
  • the configuration server 6 supplies the inverse proxy server 7, in response to the request REQ2, the configuration file CFG2 thus generated, for example in an http 200 OK message (step E210).
  • the inverse proxy server 7 transmits the configuration file CFG2 received from the configuration server 6 to the terminal 2 (step E220).
  • the terminal 2 Upon receipt of the configuration file CFG2 by its reception module 2C and via its communication means 13, the terminal 2 proceeds to its automatic configuration in a manner known per se (step E230). It is now configured to allow its user U to access the communication service S.
  • the service is a communication service.
  • the service is not a communication service.
  • the service is for example a service in the field of home automation.
  • the terminal is a connected object able to communicate with a management server.
  • the connected object is for example a room light or a sensor, for example a temperature sensor.
  • the connected object is for example initially configured with a first address allowing access to the management server.
  • a secure token is generated for this connected object and a second access address to a configuration file including the secure token is transmitted to the connected object.
  • the connected object can obtain a configuration file.
  • the configuration file contains user-specific settings.
  • the configuration file can have one or more parameters specifying the frequency of the data to be traced back to the server. This data is for example chosen according to the preferences of the user.
  • the configuration file contains parameters specifying the operating rules of the luminaire, for example operating hours chosen by the user.
  • the configuration file contains coordinates of a mobile phone of the user authorized to communicate with the connected object.

Landscapes

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

Abstract

Le procédé de contrôle est destiné à être mis en œuvre par un serveur de gestion d'un service et comprend : ¾ l'application (E30,E40) d'une configuration par défaut selon laquelle le serveur de gestion rejette toute requête d'obtention d'un fichier de configuration par un terminal tant que celui-ci n'est pas associé à un utilisateur dans une base de données du serveur; ¾ sur réception (E20,E100) d'une première requête d'obtention par un terminal d'un fichier de configuration comprenant une première adresse d'accès au fichier : la vérification (E30,E110) si le terminal est associé à un utilisateur dans la base de données; le cas échéant, la génération (E120) d'un jeton sécurisé pour le terminal et la transmission (E130) à destination du terminal d'une deuxième adresse d'accès au fichier incluant le jeton; ¾ sur réception (E160) d'une deuxième requête d'obtention (REQ2) par le terminal du fichier comprenant la deuxième adresse : la vérification (E170) si le jeton inclus dans la deuxième adresse est valide; et le cas échéant, le déclenchement (E180) d'une mise à disposition du terminal du fichier.

Description

Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration
Arrière-plan de l'invention
L'invention se rapporte au domaine général des télécommunications.
Elle concerne plus particulièrement l'obtention par un terminal d'un fichier de configuration lui permettant d'accéder à un service, par exemple un service de communication. Un tel fichier de configuration comprend typiquement les éléments techniques permettant à un utilisateur de profiter du service de communication via son terminal comme notamment un login et un mot de passe attribués à l'utilisateur pour se connecter au service de communication, des paramètres utilisateur (ex. carnet d'adresses, numéro de téléphone qui lui a été attribué, etc.), et des paramètres techniques destinés à être mis en œuvre par le terminal lors d'une session du service de communication (ex. codées audio/vidéo, paramètres de voix sur IP, etc.).
Aucune limitation n'est attachée à la nature du terminal ni à celle du service. Le terminal peut être fixe ou mobile, matériel ou logiciel ; il peut s'agir par exemple d'un téléphone intelligent (ou « smartphone »), d'un ordinateur, d'une tablette numérique, ou encore d'une application logicielle (ex. « softphone ») cherchant à accéder à un service de voix sur IP, à un service de vidéo, etc.
Dans l'état actuel de la technique, la configuration d'un terminal pour accéder à un service de communication offert par un réseau se fait via le téléchargement par le terminal d'un fichier de configuration hébergé sur un serveur de configuration distant (ex. serveur SFTP (SSH (Secure SHell) File Transfer Protocol) ou http (HyperText Transfert Protocol), en utilisant une adresse d'accès à ce fichier configurée en usine dans le terminal. Cette adresse comprend, de façon générique, l'adresse (ex. URL (Uniform Resource Locator)) du serveur distant, et le nom du fichier de configuration, celui-ci étant généré à partir d'un paramètre technique du terminal, typiquement son adresse MAC (Médium Access Control). Cette adresse est donc très facile à générer dès lors qu'on connaît l'adresse MAC du terminal.
Lorsque le téléchargement du fichier de configuration est mis en œuvre via un réseau d'accès sécurisé par nature (ex. réseau privé virtuel ou VPN (Virtual Private Network) ou réseau opérateur), les mesures de sécurité mises en œuvre par le réseau d'accès sont généralement suffisantes pour s'assurer que seul un terminal donné d'un utilisateur accède au fichier de configuration qui lui est destiné et à aucun autre.
Toutefois, il existe aujourd'hui de plus en plus d'offres sur le marché de services de communication qui ne sont pas adhérents à un tel réseau d'accès et qui s'appuient sur le réseau public Internet directement pour la configuration des terminaux.
Pour sécuriser ces offres, diverses techniques peuvent être envisagées.
Une première technique peut consister notamment à mettre en œuvre, préalablement à l'obtention du fichier de configuration par le terminal, une authentification mutuelle entre le terminal et le fournisseur du service de communication, via par exemple le protocole TLS (Transport Layer Security) classiquement utilisé pour sécuriser le transport d'information au sein de réseaux informatiques. A cet effet, un certificat TLS peut être fourni en usine au terminal. Malheureusement, ce certificat TLS peut être extrait aisément du terminal et donc compromis pour être utilisé par un dispositif tiers malveillant.
Une deuxième technique peut consister à imposer la saisie par l'utilisateur du terminal, par exemple au démarrage du terminal et préalablement à sa configuration, d'un identifiant et d'un mot de passe propres au service de communication et à l'utilisateur. Cette deuxième technique impose toutefois une contrainte d'usage à l'utilisateur qui peut s'avérer difficilement acceptable en pratique par celui-ci.
II existe donc un besoin d'une technique permettant de sécuriser l'accès par des terminaux à leurs fichiers de configuration notamment lorsque ceux-ci utilisent pour télécharger ces fichiers de configuration un réseau non sécurisé tel que le réseau public Internet.
Objet et résumé de l'invention
L'invention permet de répondre notamment à ce besoin en proposant un mécanisme de configuration automatique d'un terminal qui s'appuie avantageusement sur les procédures existantes et vient renforcer leur sécurité via la génération d'un jeton sécurisé spécifiquement pour le terminal, déclenchée dès lors que celui-ci est clairement associé à un utilisateur, ce jeton servant à la définition d'une adresse sécurisée à partir de laquelle le terminal peut accéder à son fichier de configuration.
Plus précisément, l'invention concerne selon un premier aspect, un procédé de contrôle de l'obtention par un terminal d'un fichier de configuration lui permettant d'accéder à un service, ce procédé étant destiné à être mis en œuvre par un serveur de gestion du service et comprenant :
— une étape d'application d'une configuration par défaut selon laquelle le serveur de gestion rejette toute requête d'obtention d'un fichier de configuration par un terminal tant que ce terminal n'est pas associé à un utilisateur dans une base de données du serveur de gestion ;
— sur réception d'une première requête d'obtention par un terminal d'un fichier de configuration comprenant une première adresse d'accès au fichier de configuration :
o une étape de vérification si le terminal est associé à un utilisateur dans la base de données ;
o si le terminal est associé à un utilisateur dans la base de données,
■ une étape de génération d'un jeton sécurisé pour le terminal ; et
■ une étape de transmission à destination du terminal d'une deuxième adresse d'accès au fichier de configuration incluant le jeton sécurisé ;
— sur réception d'une deuxième requête d'obtention par le terminal du fichier de configuration comprenant la deuxième adresse : o une étape de vérification si le jeton sécurisé inclus dans la deuxième adresse comprise dans la deuxième requête d'obtention est valide ; et
o si le jeton est valide, une étape de déclenchement d'une mise à disposition du terminal du fichier de configuration.
Dans un mode de réalisation particulier, le service est un service de communication.
Corrélativement, l'invention vise également un serveur de gestion d'un service, configuré pour contrôler l'obtention par un terminal d'un fichier de configuration lui permettant d'accéder au service, le serveur de gestion comprenant :
— un module d'application d'une configuration par défaut selon laquelle le serveur de gestion rejette toute requête d'obtention d'un fichier de configuration par un terminal tant que ce terminal n'est pas associé à un utilisateur dans une base de données du serveur de gestion ;
— des modules, activés sur réception d'une première requête d'obtention du fichier de configuration par un terminal comprenant une première adresse d'accès au fichier de configuration, et comprenant :
o un premier module de vérification, configuré pour vérifier si le terminal est associé à un utilisateur dans la base de données ;
o un module de génération d'un jeton sécurisé pour le terminal et un module de transmission à destination du terminal d'une deuxième adresse d'accès au fichier de configuration incluant le jeton sécurisé, le module de génération et le module de transmission étant activés si le premier module de vérification détermine que le terminal est associé à un utilisateur dans la base de données ;
— des modules, activés sur réception d'une deuxième requête d'obtention du fichier de configuration par le terminal comprenant la deuxième adresse, et comprenant :
o un deuxième module de vérification, configuré pour vérifier si le jeton sécurisé inclus dans la deuxième adresse comprise dans la deuxième requête d'obtention est valide ; et
o un module de déclenchement d'une mise à disposition du terminal du fichier de configuration activé si le deuxième module de vérification détermine que le jeton est valide.
Ainsi, conformément à l'invention, le terminal tente une première fois d'accéder à son fichier de configuration de manière classique, via l'envoi d'une requête sur l'adresse prédéfinie, « générique » (première adresse au sens de l'invention) avec laquelle il a été préalablement configuré. Cette première adresse prédéfinie est par exemple configurée avec l'adresse MAC (Médium Access Control) du terminal, comme dans l'état actuel de la technique.
Conformément à l'invention, cette première adresse prédéfinie est fermée par défaut : le serveur de gestion rejette toutes les requêtes d'accès à son fichier de configuration formulées par le terminal à cette adresse tant que celui-ci n'a pas été déclaré et associé à un utilisateur dans la base de données du serveur de gestion, autrement dit, tant que le serveur de gestion n'est pas en mesure de s'assurer de la légitimité du terminal qui lui adresse une requête pour obtenir un fichier de configuration. Dès que le serveur de gestion détecte que le terminal est attribué à un utilisateur identifié dans sa base de données, il lui alloue spécifiquement un jeton sécurisé à partir duquel il génère avantageusement une deuxième adresse, cette fois-ci spécifique et de ce fait sécurisée également, que le terminal peut alors utiliser pour accéder à son fichier de configuration.
Grâce à la présence du jeton dans la deuxième adresse, on s'assure que seul le terminal auquel le jeton a été alloué et communiqué peut accéder au fichier de configuration, et aucun autre. En l'absence de connaissance a priori de la deuxième adresse, il est impossible d'accéder au fichier de configuration d'un terminal. Or la deuxième adresse dépend du jeton sécurisé qui a été généré spécifiquement par le serveur de gestion pour le terminal : la façon même dont elle est générée, à partir d'un paramètre sécurisé maintenu secret à l'exception du terminal concerné et non d'un paramètre déterministe comme par exemple l'adresse MAC du terminal, suffit à sécuriser l'accès au fichier de configuration. L'invention est donc très simple à mettre en œuvre.
II convient de noter par ailleurs que le mécanisme de sécurisation proposé par l'invention vient en « surcouche » du mécanisme de configuration existant qui consiste pour le terminal à aller chercher son fichier de configuration à une adresse prédéfinie avec laquelle il a été préalablement configuré. L'invention ne requiert aucune configuration préalable supplémentaire des terminaux. La deuxième adresse est fournie à la volée au terminal dès lors qu'il a été contrôlé que celui-ci était bien le terminal concerné par le fichier de configuration requis. L'invention est donc compatible avec toute solution industrielle existante et ne nécessite pas d'évolution propriétaire des terminaux.
En outre, la mise en œuvre de l'invention est transparente pour les utilisateurs des terminaux.
Dans un mode particulier de réalisation, le jeton sécurisé est généré pour le terminal si le terminal est associé dans la base de données à un paramètre autorisant l'accès au fichier de configuration par le terminal.
L'obtention d'un fichier de configuration est en effet nécessaire lors de l'acquisition d'un nouveau terminal par un utilisateur, mais elle peut s'avérer également utile en cours de vie du terminal (par exemple après une réinitialisation complète). Un paramètre additionnel prévu dans la base de données et autorisant ou non l'accès au fichier de configuration par le terminal permet de gérer aisément une telle situation.
En outre, l'utilisation d'un tel paramètre dans la base de données permet de fermer facilement l'accès au fichier de configuration, par exemple après un premier accès à celui-ci par le terminal.
Comme mentionné précédemment, le jeton généré pour un terminal est sécurisé. A cet effet, dans un mode particulier de réalisation, le jeton peut être généré de façon imprédictible. Aucune limitation n'est attachée à la manière dont est généré le jeton de façon imprédictible. On peut utiliser typiquement un algorithme de chiffrement symétrique AES (Advanced Encryption Standard) qui, appliqué sur une chaîne contenant par exemple l'adresse MAC du terminal et une clé aléatoire, permet de générer un jeton aléatoire et imprédictible. L'imprédictibilité du jeton assure également celle de la deuxième adresse générée à partir du jeton et permettant au terminal d'accéder à son fichier de configuration.
Par ailleurs, le jeton sécurisé généré peut avantageusement être auto-suffisant (ou « self-contained » en anglais), dans le sens où il renferme diverses informations permettant de traiter la requête d'obtention du fichier de configuration, comme par exemple une référence temporelle, un identifiant utilisateur, etc.
En outre, pour renforcer la sécurité du mécanisme mis en œuvre par l'invention, le jeton sécurisé généré pour le terminal peut avoir une durée de validité prédéterminée.
Au-delà de cette durée de validité, il est révoqué par le serveur de gestion, de sorte que tout terminal utilisant la deuxième adresse pour obtenir le fichier de configuration y compris en présentant le jeton qui lui a été alloué voit sa requête rejetée à l'issue de la durée de validité.
Dans un autre mode de réalisation, le procédé comprend en outre suite à l'étape de déclenchement, une étape de rejet de toute nouvelle requête d'obtention du fichier de configuration reçue comprenant le jeton sécurisé.
Autrement dit, le serveur de gestion est configuré pour n'accepter qu'une seule requête d'accès au fichier de configuration. Toute requête ultérieure est rejetée. On accroît ainsi encore davantage la sécurité du mécanisme de configuration mis en œuvre.
En variante, pour fermer tout accès ultérieur au fichier de configuration, un paramètre refusant pour le terminal un accès au fichier de configuration peut être positionné dans la base de données.
En outre, ce mode de réalisation permet de se prémunir contre des attaques qui consisteraient à envoyer de façon répétée une même requête à la deuxième adresse.
Dans un mode particulier de réalisation, l'étape de déclenchement comprend une étape d'envoi d'un message à un serveur mandataire inverse placé entre le terminal et le serveur de gestion, ce message comprenant une adresse d'un serveur de configuration adapté à générer ou hébergeant le fichier de configuration, ce message étant apte à déclencher une redirection par le serveur mandataire inverse de la deuxième requête d'obtention vers le serveur de configuration pour mettre à disposition du terminal le fichier de configuration.
Le serveur mandataire inverse permet de protéger le serveur de gestion et le serveur de configuration, notamment lorsque le terminal utilise pour accéder à son fichier de configuration un réseau non sécurisé, tel que le réseau public Internet. Il est avantageusement en coupure de flux entre le terminal et les serveurs de gestion et de configuration, et intercepte à ce titre notamment toutes les requêtes émises par le terminal. Dans ce mode de réalisation, le serveur mandataire inverse gère en outre l'accès au fichier de configuration en interagissant, sur la requête du serveur de gestion, avec le serveur de configuration qui héberge le fichier de configuration du terminal. On évite ainsi un accès direct au serveur de gestion et au serveur de configuration par le terminal, et ce de façon totalement transparente pour le terminal.
On note que l'utilisation d'un tel serveur mandataire inverse permet également de mettre facilement en place des solutions d'équilibre de la charge pour la configuration automatique des terminaux : le serveur mandataire inverse, peut en fonction de l'indisponibilité de tel ou tel serveur de configuration, rediriger la requête du terminal vers un serveur de configuration plus disponible et moins chargé.
Dans un autre mode de réalisation, l'étape de déclenchement comprend la redirection de la deuxième requête d'obtention vers un serveur de configuration adapté à générer ou hébergeant le fichier de configuration pour mettre à disposition du terminal ledit fichier de configuration.
Autrement dit, dans ce mode de réalisation alternatif, la redirection de la requête vers le serveur de configuration est réalisée directement par le serveur de gestion du service, sans l'intervention du serveur mandataire inverse.
Le mécanisme de sécurisation proposé par l'invention s'appuie, comme il apparaît clairement au vu de ce qui précède, sur le serveur de gestion du service qui met en œuvre le procédé de contrôle selon l'invention, mais également sur le terminal et, dans certains modes de réalisation, sur un serveur mandataire inverse localisé entre le terminal et le serveur de gestion.
Selon un deuxième aspect, l'invention concerne également un procédé d'obtention par un terminal d'un fichier de configuration lui permettant d'accéder à un service, ce procédé comprenant :
— au moins une étape d'émission d'une première requête d'obtention du fichier de configuration comprenant une première adresse d'accès au fichier de configuration ;
— une étape d'émission d'une deuxième requête d'obtention du fichier de configuration, déclenchée suite à la réception en réponse à la première requête d'obtention d'une deuxième adresse d'accès au fichier de configuration incluant un jeton sécurisé généré pour le terminal par un serveur de gestion du service, ladite deuxième requête d'obtention comprenant ladite deuxième adresse ;
— une étape de réception du fichier de configuration en provenance d'un serveur de configuration apte à générer ou à héberger le fichier de configuration.
Corrélativement, l'invention vise aussi un terminal comprenant :
— un premier module d'émission configuré pour émettre au moins une première requête d'obtention d'un fichier de configuration pour accéder à un service, ladite au moins une première requête d'obtention comprenant une première adresse d'accès au fichier de configuration ;
— un deuxième module d'émission, activé sur réception en réponse à la première requête d'obtention d'une deuxième adresse d'accès au fichier de configuration incluant un jeton sécurisé généré pour le terminal par un serveur de gestion du service, et configuré pour émettre une deuxième requête d'obtention du fichier de configuration comprenant la deuxième adresse ; et
— un module de réception adapté à recevoir le fichier de configuration en provenance d'un serveur de configuration apte à générer ou à héberger le fichier de configuration.
Selon un troisième aspect, l'invention concerne un procédé de traitement de requêtes d'obtention par un terminal d'un fichier de configuration pour accéder à un service, ce procédé étant destiné à être mis en œuvre par un serveur mandataire inverse placé entre le terminal et un serveur de gestion du service, le procédé comprenant :
— au moins une première étape de redirection vers le serveur de gestion du service, d'une première requête d'obtention par le terminal du fichier de configuration, ladite première requête d'obtention comprenant une première adresse d'accès au fichier de configuration ; et
— une deuxième étape de redirection d'une deuxième requête d'obtention par le terminal du fichier de configuration, ladite deuxième requête d'obtention comprenant une deuxième adresse d'accès au fichier de configuration fournie par le serveur de gestion au terminal par l'intermédiaire du serveur mandataire inverse et incluant un jeton sécurisé généré par le serveur de gestion pour le terminal.
Corrélativement, l'invention propose également un serveur mandataire inverse placé entre un terminal et un serveur de gestion d'un service, ce serveur mandataire inverse comprenant :
— un premier module de redirection, configuré pour rediriger vers le serveur de gestion au moins une première requête d'obtention par un terminal d'un fichier de configuration destiné à permettre audit terminal d'accéder au service, ladite au moins une première requête d'obtention comprenant une première adresse d'accès au fichier de configuration ; et — un deuxième module de redirection, configuré pour rediriger vers le serveur de gestion une deuxième requête d'obtention par le terminal du fichier de configuration, ladite deuxième requête d'obtention comprenant une deuxième adresse d'accès au fichier de configuration fournie par le serveur de gestion au terminal par l'intermédiaire du serveur mandataire inverse et incluant un jeton sécurisé généré par le serveur de gestion pour le terminal.
Autrement dit, le serveur mandataire inverse selon l'invention est configuré pour gérer deux adresses distinctes d'accès au fichier de configuration du terminal, et rediriger les requêtes portant sur ces deux adresses vers le serveur de gestion du service.
Dans un mode particulier de réalisation, le procédé de traitement comprend une troisième étape de redirection de la deuxième requête d'obtention vers un serveur de configuration adapté à générer ou hébergeant le fichier de configuration, ladite troisième étape de redirection étant déclenchée suite à la réception d'un message du serveur de gestion déclenchant une mise à disposition du terminal du fichier de configuration et comprenant une adresse du serveur de configuration. Cette troisième étape de redirection est totalement transparente pour le terminal.
Corrélativement, dans ce mode de réalisation, le serveur comprend en outre un troisième module de redirection configuré pour rediriger la deuxième requête d'obtention vers un serveur de configuration adapté à générer ou hébergeant le fichier de configuration, ce troisième module de redirection étant activé sur réception d'un message du serveur de gestion déclenchant une mise à disposition du terminal du fichier de configuration et comprenant une adresse du serveur de configuration.
L'invention vise aussi un système de contrôle de l'obtention d'un fichier de configuration par un terminal pour accéder à un service, ledit système comprenant :
— un serveur de gestion du service conforme à l'invention ;
— un serveur mandataire inverse conforme à l'invention, placé entre le terminal et le serveur de gestion ; et
— un serveur de configuration apte à générer ou hébergeant le fichier de configuration, et configuré pour fournir le fichier de configuration au terminal sur réception d'un message du serveur de gestion ou du serveur mandataire inverse.
Le terminal, le serveur mandataire inverse, le procédé de traitement, le procédé d'obtention et le système selon l'invention présentent des avantages similaires à ceux décrits précédemment pour le procédé de contrôle et le serveur de gestion selon l'invention.
Dans un mode particulier de réalisation, les différentes étapes du procédé de contrôle, et/ou du procédé d'obtention et/ou du procédé de traitement sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un serveur de gestion ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de contrôle tel que décrit ci-dessus.
L'invention vise également un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un terminal ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé d'obtention tel que décrit ci-dessus.
L'invention concerne aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un serveur mandataire inverse ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de traitement tel que décrit ci-dessus.
Chacun des programmes précités peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus.
Le support d'informations ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de contrôle, le procédé de traitement, le procédé d'obtention, le serveur de gestion, le terminal, le serveur mandataire inverse et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
— la figure 1 représente, dans son environnement, un système de contrôle conforme à l'invention ;
— la figure 2 illustre schématiquement l'architecture matérielle des différents éléments du système de contrôle représenté à la figure 1 ; et
— la figure 3 représente, sous forme de diagramme de flux, les différentes étapes d'un procédé de contrôle, d'un procédé de traitement et d'un procédé d'obtention selon l'invention tels qu'ils sont mis en œuvre respectivement par le serveur de gestion et le serveur mandataire inverse du système de contrôle de la figure 1, et par le terminal cherchant à accéder à son fichier de configuration.
Description détaillée de l'invention La figure 1 représente, dans son environnement, un système de contrôle 1 conforme à l'invention, dans un mode particulier de réalisation.
Dans ce mode de réalisation, le service est un service de communication. Dans l'exemple envisagé à la figure 1, le système de contrôle 1 est adapté à encadrer de manière sécurisée la configuration automatique d'un terminal 2 d'un utilisateur U, conforme à l'invention, et plus particulièrement à contrôler l'obtention par ce terminal 2 d'un fichier de configuration CFG2 lui permettant d'accéder à un service de communication S. Le service S est par exemple ici un service de téléphonie ou de voix sur IP fourni par un fournisseur de services 3.
De façon connue, un fichier de configuration CFG2 permettant d'accéder à un tel service de communication regroupe typiquement les éléments techniques permettant à l'utilisateur U de profiter du service de communication S via son terminal 2, comme notamment un login et un mot de passe attribués à l'utilisateur U pour se connecter au service de communication S, des paramètres utilisateur (ex. son carnet d'adresses, le numéro de téléphone qui lui a été attribué pour communiquer sur le service S, mot de passe SIP (Session Initiation Protocol), etc.), ainsi que des paramètres techniques destinés à être mis en œuvre par le terminal 2 lors d'une session du service de communication S (ex. codées audio/vidéo, paramètres de voix sur IP, etc.). Il peut contenir également des logiciels ou firmwares utiles pour bénéficier du service de communication S. Une fois le fichier de configuration CFG2 obtenu par le terminal 2, le terminal 2 applique les éléments techniques contenus dans le fichier de configuration CFG2 lors de ses sessions d'utilisation du service de communication S.
On note que l'obtention d'un fichier de configuration est nécessaire lors de l'acquisition d'un nouveau terminal par un utilisateur, mais elle peut s'avérer nécessaire également en cours de vie du terminal (par exemple après une réinitialisation complète de celui-ci).
Aucune limitation n'est attachée à la nature du service S, ni à la nature du terminal 2. II peut s'agir d'un téléphone de type téléphone intelligent (ou « smartphone »), d'une application logicielle (ou « softphone »), d'un ordinateur sur lequel est installé une telle application logicielle, d'une tablette numérique, etc.
Pour encadrer la configuration du terminal 2 pour lui permettre d'accéder au service de communication S, le système de contrôle 1 s'appuie, dans le mode de réalisation décrit ici, sur une architecture comprenant diverses entités, à savoir :
— un serveur de gestion 4 du service de communication S, conforme à l'invention, et auquel est associée une base de données 5, comprenant des données d'activation du service S telles que par exemple les utilisateurs du service, leurs numéros de téléphone et les terminaux qui leur sont associés (identifiés par exemple via leur adresse MAC), etc. ;
— un serveur de configuration 6, apte à générer ou à héberger des fichiers de configuration permettant à des terminaux et à leurs utilisateurs d'accéder au service de communication S, dont en particulier le fichier de configuration CFG2 du terminal 2 ; et — un serveur mandataire inverse 7 (aussi couramment appelé « proxy inverse »), conforme à l'invention, placé en coupure de flux entre le terminal 2 et le serveur de gestion 4 d'une part, et entre le terminal 2 et le serveur de configuration 5 d'autre part. De façon connue, un serveur mandataire inverse est classiquement utilisé dans les réseaux informatiques pour sécuriser l'accès depuis l'extérieur et notamment depuis le réseau public Internet à un ou plusieurs serveurs localisés dans un réseau « interne ». Tout message venant de l'extérieur et destiné à un serveur du réseau interne protégé par le serveur mandataire inverse transite par celui-ci, qui le redirige ensuite vers le serveur du réseau interne concerné. De cette sorte on évite que les serveurs internes soient en accès direct depuis l'extérieur. Dans l'exemple envisagé à la figure 1, le serveur mandataire inverse 7 protège l'accès au serveur de gestion 4 et au serveur de configuration 6. Il intercepte toutes les requêtes émises par le terminal 2 à destination du serveur de gestion 4 notamment, et les redirige vers celui-ci. En outre, dans le mode de réalisation décrit ici, le serveur mandataire inverse 7 joue également le rôle d'intermédiaire entre le serveur de gestion 4 et le serveur de configuration 6 comme détaillé davantage ultérieurement.
Dans le mode de réalisation décrit ici, le terminal 2, le serveur de gestion 4 et le serveur mandataire inverse 7 ont tous les trois l'architecture matérielle d'un ordinateur 8 tel que représenté de façon schématique et générique à la figure 2.
L'ordinateur 8 comprend notamment un processeur 9, une mémoire morte 10, une mémoire vive 11, une mémoire non volatile 12 et des moyens de communication 13 sur un ou plusieurs réseaux de communication reliant entre eux le terminal 2, le serveur de gestion 4, le serveur de configuration 6 et le serveur mandataire inverse 7. En outre, dans le mode de réalisation décrit ici, le terminal 2, le serveur de gestion 4, le serveur de configuration 6 et le serveur mandataire inverse 7 communiquent entre eux en utilisant le protocole http ou le protocole HTTPS (entre le terminal 2 et le serveur mandataire inverse 7), de sorte que les moyens de communication 13 comprennent une pile du protocole http et/ou HTTPS.
En variante, tout autre type de protocole permettant d'accéder à une ressource identifiée par une adresse (telle une URL (Uniform Ressource Locator)) ou un chemin ou encore une route pointant sur cette ressource peut être utilisé par le terminal 2, le serveur de gestion 4, le serveur de configuration 6 et le serveur mandataire inverse 7, comme par exemple le protocole FTP (File Transfer Protocol).
La mémoire morte 10 de l'ordinateur 8 constitue un support d'enregistrement ou d'informations conforme à l'invention, lisible par le processeur 9 et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, référencé de façon générique sur la figure 2 par PROG. Ce programme d'ordinateur PROG diffère en fonction de l'entité dans la mémoire morte de laquelle il est stocké.
Ainsi, lorsque l'ordinateur 8 est le serveur de gestion 4, le programme d'ordinateur est un programme PROG4 comportant des instructions pour l'exécution d'un procédé de contrôle selon l'invention de l'obtention par le terminal 2 du fichier de configuration CFG2 lui permettant d'accéder au service de communication S. Ce programme PROG4 définit, par le biais de ses instructions, des modules fonctionnels du serveur de gestion 4 qui s'appuient sur et/ou commandent les éléments matériels 9-13 de l'ordinateur 8 décrits précédemment, et qui comprennent notamment ici comme illustré à la figure 1 :
— un module d'application 4A d'une configuration par défaut DEF selon laquelle le serveur de gestion 4 rejette toute requête d'obtention d'un fichier de configuration par un terminal reçue tant que celui-ci n'est pas associé à un utilisateur dans sa base de données 5 ;
— des modules 4B-4D, activés sur réception d'une requête d'obtention par un terminal (par exemple par le terminal 2) d'un fichier de configuration permettant d'accéder au service S, cette requête dite « première requête d'obtention » comprenant une première adresse d'accès URL1 au fichier de configuration. Ces modules sont plus particulièrement :
o un premier module de vérification 4B, configuré pour vérifier si le terminal à l'origine de la première requête est associé à un utilisateur dans la base de données 5 ; et o un module de génération 4C d'un jeton sécurisé (ou token) pour le terminal (référencé par TOK2 pour le terminal 2) ; et
o un module de transmission 4D à destination du terminal d'une deuxième adresse d'accès URL2 au fichier de configuration incluant le jeton sécurisé généré pour le terminal.
Le module de génération 4C et le module de transmission 4D sont activés si le premier module de vérification 4B détermine que le terminal est associé à un utilisateur dans la base de données 5 ;
— des modules 4E et 4F, activés sur réception d'une deuxième requête d'obtention du fichier de configuration par le terminal comprenant la deuxième adresse URL2. Ces modules 4E et 4F sont plus particulièrement :
o un deuxième module de vérification 4E, configuré pour vérifier si le jeton sécurisé inclus dans la deuxième adresse comprise dans la deuxième requête d'obtention est valide ; et
o un module de déclenchement 4F configuré pour déclencher une mise à disposition du terminal du fichier de configuration, ce module 4F étant activé si le deuxième module de vérification 4E détermine que le jeton est valide.
Les modules 4A-4F et leurs fonctions respectives sont décrits plus en détail ultérieurement en référence aux étapes du procédé de contrôle selon l'invention.
Lorsque l'ordinateur 8 est le terminal 2, le programme d'ordinateur est un programme PROG2 comportant des instructions pour l'exécution d'un procédé d'obtention selon l'invention par le terminal 2 du fichier de configuration CFG2 lui permettant d'accéder au service de communication S. Ce programme PROG2 définit, par le biais de ses instructions, des modules fonctionnels du terminal 2 qui s'appuient sur et/ou commandent les éléments matériels 9-13 de l'ordinateur 8 décrits précédemment, et qui comprennent notamment ici comme illustré à la figure 1 :
— un premier module d'émission 2A configuré pour émettre au moins une première requête d'obtention d'un fichier de configuration pour accéder à un service de communication, ladite au moins une première requête d'obtention comprenant la première adresse d'accès URL1 ;
— un deuxième module d'émission 2B, activé sur réception en réponse à la première requête d'obtention de la deuxième adresse d'accès URL2 incluant le jeton sécurisé TOK généré pour le terminal par le serveur de gestion 4, le deuxième module d'émission 2B étant configuré pour émettre une deuxième requête d'obtention du fichier de configuration comprenant la deuxième adresse URL2 ; et
— un module de réception 2C adapté à recevoir le fichier de configuration CFG2 en provenance du serveur de configuration 6.
Les modules 2A-2C et leurs fonctions respectives sont décrits plus en détail ultérieurement en référence aux étapes du procédé d'obtention selon l'invention.
Enfin, lorsque l'ordinateur 8 est le serveur mandataire inverse 7, le programme d'ordinateur est un programme PROG7 comportant des instructions pour l'exécution d'un procédé de traitement selon l'invention des requêtes d'obtention du fichier de configuration CFG2 émises par le terminal 2 pour pouvoir accéder au service de communication S. Ce programme PROG7 définit, par le biais de ses instructions, des modules fonctionnels du serveur mandataire inverse 7 qui s'appuient sur et/ou commandent les éléments matériels 9-13 de l'ordinateur 8 décrits précédemment, et qui comprennent notamment ici comme illustré à la figure 1 :
— un premier module de redirection 7A, configuré pour rediriger vers le serveur de gestion 4 les requêtes d'obtention (premières requêtes d'obtention au sens de l'invention) émises par le terminal 2 et comprenant la première adresse d'accès URL1 ; et
— un deuxième module de redirection 7B, configuré pour rediriger vers le serveur de gestion 4 les requêtes d'obtention (deuxièmes requêtes d'obtention au sens de l'invention) émises par le terminal 2 et comprenant la deuxième adresse d'accès URL2.
En outre, dans le mode de réalisation décrit ici, le programme PROG7 définit également par le biais de ses instructions un troisième module de redirection 7C configuré pour rediriger une deuxième requête d'obtention reçue du terminal 2 vers le serveur de configuration 6 sur réception d'un message du serveur de gestion 4 déclenchant une mise à disposition du terminal 2 du fichier de configuration CFG2.
Les modules 7A-7C et leurs fonctions respectives sont décrits plus en détail ultérieurement en référence aux étapes du procédé de traitement selon l'invention.
La figure 3 représente, sous forme de diagramme de flux, les principales étapes mises en œuvre, conformément à l'invention, par le terminal 2 et par le système de contrôle 1, pour sécuriser la configuration automatique du terminal 2 afin de lui permettre d'accéder au service de communication S offert par le fournisseur de services 3. Ces étapes regroupent les étapes du procédé de contrôle mis en œuvre par le serveur de gestion 4 du service de communication S, les étapes du procédé de traitement mises en œuvre par le serveur mandataire inverse 7, et les étapes du procédé d'obtention mises en œuvre par le terminal 2.
Dans le mode de réalisation décrit ici, on suppose que le terminal 2 est livré à son utilisateur U, configuré avec la première adresse URL1 (étape E00). Cette première adresse URL1 est une adresse d'accès au fichier de configuration CFG2 du terminal 2 au sens de l'invention. Elle est prédéfinie de manière générique comme dans l'état de la technique, c'est-à-dire à partir d'une adresse de joignabilité « statique » du serveur de configuration 6 et de l'adresse MAC du terminal 2, notée ici @MAC2. La première adresse d'accès URL1 permet ainsi d'accéder au serveur de configuration 6 qui héberge ou génère les fichiers de configuration permettant d'accéder au service S, et d'identifier sur ce serveur le fichier de configuration CFG2 qui est adapté au terminal 2 et à son utilisateur U (typiquement qui est adapté aux capacités du terminal 2, aux options souscrites le cas échéant par l'utilisateur U dans le cadre du service S, etc.).
Lorsque l'utilisateur U démarre son terminal 2, celui-ci est configuré pour émettre par l'intermédiaire de son premier module d'émission 2A et de ses moyens de communication 13, une première requête REQ1 d'obtention du fichier de configuration du terminal 2 sur la première adresse prédéfinie URL1 avec laquelle il a été configuré en usine (étape E10). Cette requête REQ1 est par exemple une requête HTTPS Get émise sur l'adresse URL1 configurée avec l'adresse du serveur de configuration 6 et l'adresse @MAC2 du terminal 2.
La requête REQ1 est interceptée par le serveur mandataire inverse 7, qui est configuré pour rediriger, par le biais de son premier module de redirection 4A, les requêtes comprenant l'adresse URL1 vers le serveur de gestion 4 (étape E20).
Comme mentionné précédemment, le serveur de gestion 4 est configuré par défaut avec une règle DEF selon laquelle il rejette toute requête d'obtention par un terminal d'un fichier de configuration reçue {a fortiori, une requête d'obtention comprenant la première adresse URL1) tant que ce terminal n'est pas associé à un utilisateur dans sa base de données 5. Autrement dit, l'accès à la configuration est fermé aux terminaux tant que ceux-ci ne sont pas déclarés auprès de la base de données 5. Cette configuration par défaut DEF est appliquée par le module d'application 4A du serveur de gestion 4.
Sur réception de la requête REQ1, le serveur de gestion 4 vérifie donc, par l'intermédiaire de son premier module de vérification 4B, si le terminal 2 à l'origine de la requête REQ1 est identifié dans sa base de données 5 et associé à un utilisateur (étape E30). Il utilise à cet effet ici l'adresse @MAC2 du terminal 2, présente de façon standard dans la requête REQ1. En variante, un autre identifiant du terminal 2 peut être utilisé dès lors qu'il correspond aux identifiants utilisés pour renseigner la base de données 5 ou est lié à un tel identifiant.
Dans l'exemple envisagé ici, on suppose que le premier module de vérification 4B du serveur de gestion 4 ne trouve pas l'adresse MAC @MAC2 du terminal 2 dans sa base de données 5. Conformément à la règle DEF, le serveur de gestion 4 rejette la requête REQ1 du terminal 2, par exemple en envoyant un message de réponse http 403 Forbidden (étape E40). Ce message transite par le serveur mandataire inverse 7 qui le relaie vers le terminal 2 (étape E50).
En variante, le rejet de la requête REQ1 peut se faire via l'envoi au terminal 2 d'un fichier de configuration prédéfini permettant d'afficher sur le terminal 2 un message l'invitant à configurer son service de communication S et à déclarer son terminal 2 auprès du fournisseur de service 3, via par exemple un portail d'administration prévu à cet effet.
On suppose maintenant que l'utilisateur U se connecte sur un tel portail d'administration du service de communication S pour déclarer son terminal 2 (étape E60) : il fournit lors de cette déclaration un identifiant d'utilisateur et un identifiant de son terminal 2, à savoir ici l'adresse MAC @MAC2 du terminal 2. En variante, un autre type d'identifiant peut être envisagé dès lors qu'il permet d'identifier et de reconnaître le terminal 2 à partir de ses requêtes.
Cet événement déclenche une mise à jour de la base de données 5 du serveur de gestion 4 (étape E70) ; plus précisément, suite à cette déclaration, le terminal 2 est associé, par l'intermédiaire de son adresse MAC @MAC2, à l'utilisateur U qui s'est enregistré auprès du fournisseur de service 3 pour bénéficier du service de communication S. Cette mise à jour déclenche par ailleurs la regénération d'un mot de passe SIP pour le terminal 2.
Dans l'exemple envisagé ici, suite à cette déclaration, l'utilisateur U est invité à redémarrer son terminal 2 pour commencer sa configuration en vue d'accéder au service de communication S.
Suite au redémarrage du terminal 2 (étape E80), le terminal 2 envoie par l'intermédiaire de son module d'émission 2A et de ses moyens de communication 13, une nouvelle requête d'obtention REQ1' de son fichier de configuration. Cette requête de configuration REQ1' comprend la première adresse URL1 avec laquelle le terminal 2 a été configuré en usine (étape E90). Cette requête REQ1' est une première requête au sens de l'invention.
La requête REQ1' est interceptée par le serveur mandataire inverse 7 qui, via son module de redirection 7A, la redirige vers le serveur de gestion 4 (étape E100).
Sur réception de la requête REQ1', le serveur de gestion 4 vérifie, par l'intermédiaire de son premier module de vérification 4B, si le terminal 2 à l'origine de la requête REQ1' est identifié dans sa base de données 5 et associé à un utilisateur (étape E110). Il utilise à cet effet ici l'adresse @MAC2 du terminal 2, contenue dans la requête REQ1'.
Suite à la déclaration faite par l'utilisateur U à l'étape E60, le terminal 2 est enregistré dans la base de données 5 en association avec l'utilisateur U. Le module de vérification 4B détermine donc, lors de son interrogation de la base de données 5, que le terminal 2 est associé à un utilisateur (U) dans la base de données 5 et peut donc être configuré.
Le serveur de gestion 4, par l'intermédiaire de son module de génération 4C, génère alors un jeton sécurisé TOK2 pour le terminal 2 (étape E120). Un tel jeton se présente sous la forme d'une chaîne de caractères ayant une dimension prédéfinie. Cette dimension peut varier typiquement entre 50 et 300 caractères selon les implémentations. Toutefois ces valeurs ne sont données qu'à titre illustratif et ne sont pas limitatives en soi.
Pour générer le jeton sécurisé TOK2, le module de génération 4C utilise par exemple l'algorithme de chiffrement AES, appliqué sur une chaîne de caractères formée de l'adresse MAC @MAC2 du terminal 2 et d'un aléa pouvant inclure notamment un horodatage (ou « timestamp » en anglais) pour assurer l'unicité du jeton généré et empêcher sa réutilisation.
Le jeton sécurisé ainsi généré est avantageusement aléatoire et imprédictible. Il est dédié au terminal 2 et uniquement à ce terminal. Par exemple :
TOK2 = 'EkRooesmoe56razazeg87ARu ii prea pr'
Le serveur de gestion 4 le stocke dans sa base de données 5, en association avec l'identifiant @MAC2 du terminal 2. Dans le mode de réalisation décrit ici, il alloue au jeton TOK2 une durée de validité limitée, prédéfinie (par exemple lh).
En variante, le jeton TOK2 peut être stocké dans un autre espace de stockage que la base de données 5 en association avec l'adresse @MAC2 du terminal 2, par exemple dans la mémoire non volatile 12 du serveur de gestion 4.
Dans une autre variante encore, le serveur de gestion 4 stocke uniquement l'aléa ayant permis la génération du jeton TOK2 en association avec l'adresse @MAC2, le jeton TOK2 pouvant être aisément regénéré à partir de cet aléa.
Puis le module de génération 4C du serveur de gestion 4 génère à partir du jeton TOK2 une deuxième adresse URL2 d'accès au fichier de configuration du terminal 2. Cette adresse URL2 est ici de la forme suivante :
[protocole]://[Domaine]/Ueton TOK2]/[@MAC2].cfg
A titre illustratif, la deuxième adresse URL2 est par exemple :
URL2=https://configuration.serviceS.com/EkRooesmoe56razazeg87ARuiipreapr/@MAC2.cfg Le serveur de gestion 4, par l'intermédiaire de son module de transmission 4D et de ses moyens de communication 13, envoie la deuxième adresse URL2 ainsi générée à destination du terminal 2, dans un message de réponse http 200 à sa requête REQ1' (étape E130). L'adresse URL2 est une deuxième adresse d'accès au fichier de configuration du terminal 2 au sens de l'invention.
Le message de réponse http 200 contenant la deuxième adresse URL2 incluant le jeton
TOK2 transite par le serveur mandataire inverse 7, qui le relaie vers le terminal 2 (étape E140).
La réception de la deuxième adresse URL2 déclenche l'envoi par le terminal 2 via son deuxième module d'émission 2B et ses moyens de communication 13, d'une nouvelle requête d'obtention REQ2 de son fichier de configuration comprenant cette fois-ci l'adresse URL2 et le jeton TOK2 inclus dans cette adresse (étape E150). La requête REQ2 est par exemple ici une requête GET sur l'adresse URL2. La requête REQ2 est interceptée par le serveur mandataire inverse 7, qui sur détection de l'adresse URL2 la redirige via son deuxième module de redirection 7A vers le serveur de gestion 4 (étape El 60).
Sur réception de la requête REQ2, le serveur de gestion 4, via son deuxième module de vérification 4E, extrait le jeton TOK2 de l'adresse URL2. Puis le module de vérification 4E interroge la base de données 5 pour vérifier la validité du jeton TOK2, i.e. si celui-ci existe, est bien associé au terminal 2 (c'est-à-dire à son adresse MAC @MAC2 présente dans l'adresse URL2), et est en cours de validité (étape E170). On suppose ici que les jetons qui ne sont plus valides, sont supprimés de la base de données 5.
Si le jeton TOK2 est valide et bien associé au terminal 2 (on suppose que c'est le cas ici), le serveur de gestion 4, via son module de déclenchement 4F, déclenche la mise à disposition du terminal 2 de son fichier de configuration CFG2 pour accéder au service de communication S (étape E180).
Sinon, la requête d'obtention REQ2 est rejetée : le serveur de gestion 4 envoie par exemple à destination du terminal 2 un message http 403 Forbidden comme décrit précédemment à l'étape E40.
Dans le mode de réalisation décrit ici, la mise à disposition du terminal 2 de son fichier de configuration se traduit par l'envoi par le serveur de gestion 4, via son module de déclenchement 4F et ses moyens de communication 13, d'un message http 302 au serveur mandataire inverse 7. Ce message requiert la redirection de la requête REQ2 émise par le terminal 2 vers le serveur de configuration 6 afin que le terminal 2 puisse accéder à son fichier de configuration CFG2. Il contient, dans le champ « Location » de son entête, une adresse URL6-CFG2 comprenant une partie statique correspondant à l'adresse de joignabilité notée URL6 du serveur de configuration 6, et une partie dynamique correspondant à l'adresse MAC @MAC2 du terminal 2.
Dans une variante de réalisation, la mise à disposition du terminal 2 de son fichier de configuration se traduit par la redirection par le serveur de gestion 4, via son module de déclenchement 4F et ses moyens de communication 13, de la requête REQ2 vers le serveur de configuration 6 pour que celui-ci mette à disposition du terminal 2 son fichier de configuration CFG2.
Dès lors, dans le mode de réalisation décrit ici, le serveur de gestion 4 est configuré pour rejeter toute nouvelle requête d'obtention reçue contenant le jeton sécurisé TOK2 alloué au terminal 2. Cette étape est toutefois optionnelle.
Dans une variante de réalisation, un paramètre indiquant si l'obtention d'un fichier de configuration est autorisée ou non peut être enregistré dans la base de données 5 en association avec l'identifiant du terminal 2 et celui de l'utilisateur U associé. Ce paramètre peut être typiquement mis à jour manuellement via une interface homme-machine (IHM). Si l'obtention du fichier de configuration n'est pas autorisée, tout se passe comme si le terminal n'était pas associé à l'utilisateur. La réception par le serveur mandataire inverse 7 du message http 302 contenant l'adresse URL6-CFG2 déclenche la redirection par le troisième module de redirection 7C du serveur mandataire inverse 7 de la requête d'obtention REQ2 du terminal 2 vers le serveur de configuration 6 (étape 190). Plus particulièrement, cette redirection s'effectue ici via l'envoi par le module de redirection 7C, au serveur de configuration 6, de la requête REQ2 dans laquelle l'adresse URL2 a été remplacée par l'adresse URL6-CFG2 (référencée par REQ2'(URL6-CFG2) sur la figure 3) pour obtenir le fichier de configuration CFG2.
Sur réception de la requête d'obtention REQ2', le serveur de configuration 6 génère dynamiquement, de façon connue en soi, le fichier de configuration CFG2 adapté au terminal 2 et lui permettant d'accéder au service de communication S (étape E200). Pour générer un tel fichier, le serveur de configuration 6 dispose par exemple de modèles (« templates ») ou de programmes pré-générés et pré-enregistrés pour différents types de terminaux. Il utilise le modèle ou le programme correspondant au terminal 2, ainsi que les paramètres de l'utilisateur U et du terminal 2.
En variante, un tel fichier de configuration 2 est généré à l'avance et hébergé par le serveur de configuration 6.
Le serveur de configuration 6 fournit au serveur mandataire inverse 7, en réponse à la requête REQ2, le fichier de configuration CFG2 ainsi généré, par exemple dans un message http 200 OK (étape E210).
Le serveur mandataire inverse 7 transmet le fichier de configuration CFG2 reçu du serveur de configuration 6 au terminal 2 (étape E220).
Sur réception du fichier de configuration CFG2 par son module de réception 2C et via ses moyens de communication 13, le terminal 2 procède à sa configuration automatique de façon connue en soi (étape E230). Il est maintenant configuré pour permettre à son utilisateur U d'accéder au service de communication S.
Dans le mode de réalisation décrit, le service est un service de communication.
A titre d'alternative, le service n'est pas un service de communication. Le service est par exemple un service dans le domaine de la domotique.
Par exemple, le terminal est un objet connecté apte à communiquer avec un serveur de gestion.
L'objet connecté est par exemple un luminaire d'ambiance ou un capteur, par exemple un capteur de température.
Aucune limite n'est apportée à la nature de l'objet connecté.
L'objet connecté est par exemple initialement configuré avec une première adresse permettant l'accès au serveur de gestion.
Si l'objet connecté est associé à un utilisateur dans une base de données accessible par le serveur de gestion, un jeton sécurisé est généré pour cet objet connecté et une deuxième adresse d'accès à un fichier de configuration incluant le jeton sécurisé est transmise à l'objet connecté.
Grâce à la deuxième adresse, l'objet connecté peut obtenir un fichier de configuration.
Le fichier de configuration contient par exemple des paramètres propres à l'utilisateur. A titre d'exemple, si l'objet connecté est un capteur, le fichier de configuration peut un ou plusieurs paramètres spécifiant la fréquence des données à remonter au serveur. Ces données sont par exemple choisies en fonction de préférences de l'utilisateur.
Egalement à titre d'exemple, si l'objet connecté est un luminaire d'ambiance, le fichier de configuration contient des paramètres spécifiant des règles de fonctionnement du luminaire, par exemple des horaires de fonctionnement choisis par l'utilisateur.
A titre d'alternative, le fichier de configuration contient des coordonnées d'un téléphone mobile de l'utilisateur autorisé à communiquer avec l'objet connecté.

Claims

REVENDICATIONS
1. Procédé de contrôle de l'obtention par un terminal (2) d'un fichier de configuration (CFG2) lui permettant d'accéder à un service (S), ce procédé étant destiné à être mis en œuvre par un serveur de gestion (4) du service et comprenant :
— une étape d'application (E30,E40) d'une configuration par défaut selon laquelle le serveur de gestion rejette toute requête d'obtention d'un fichier de configuration par un terminal tant que ce terminal n'est pas associé à un utilisateur dans une base de données du serveur de gestion ;
— sur réception (E20,E100) d'une première requête d'obtention (REQ1,REQ1') par un terminal d'un fichier de configuration comprenant une première adresse d'accès (URL1) au fichier de configuration :
o une étape de vérification (E30,E110) si le terminal est associé à un utilisateur dans la base de données ;
o si le terminal est associé à un utilisateur dans la base de données,
■ une étape de génération (E120) d'un jeton sécurisé (TOK2) pour le terminal ; et
■ une étape de transmission (E130) à destination du terminal d'une deuxième adresse d'accès (URL2) au fichier de configuration incluant le jeton sécurisé ; — sur réception (E160) d'une deuxième requête d'obtention (REQ2) par le terminal du fichier de configuration comprenant la deuxième adresse :
o une étape de vérification (E170) si le jeton sécurisé inclus dans la deuxième adresse comprise dans la deuxième requête d'obtention est valide ; et
o si le jeton est valide, une étape de déclenchement (E180) d'une mise à disposition du terminal du fichier de configuration.
2. Procédé de contrôle selon la revendication 1 dans lequel le service est un service de communication. 3. Procédé de contrôle selon la revendication 1 ou 2 dans lequel le jeton sécurisé
(TOK2) est généré pour le terminal si le terminal est associé dans la base de données à un paramètre autorisant l'accès au fichier de configuration par le terminal.
4. Procédé de contrôle selon l'une des revendications 1 à 3 dans lequel le jeton sécurisé généré pour le terminal a une durée de validité prédéterminée.
5. Procédé de contrôle selon l'une quelconque des revendications 1 à 4 comprenant en outre suite à l'étape de déclenchement, une étape de rejet de toute nouvelle requête d'obtention du fichier de configuration reçue comprenant le jeton sécurisé. 6. Procédé de contrôle selon l'une quelconque des revendications 1 à 5 dans lequel la première adresse d'accès (URL1) est configurée avec une adresse MAC (Médium Access Control) du terminal.
7. Procédé de contrôle selon l'une quelconque des revendications 1 à 6 dans lequel l'étape de déclenchement comprend une étape d'envoi (E180) d'un message à un serveur mandataire inverse placé entre le terminal et le serveur de gestion, ledit message comprenant une adresse (URL6-CFG2) d'un serveur de configuration (6) adapté à générer ou hébergeant le fichier de configuration, ce message étant apte à déclencher une redirection par le serveur mandataire inverse de la deuxième requête d'obtention vers le serveur de configuration pour mettre à disposition du terminal ledit fichier de configuration.
8. Procédé de contrôle selon l'une quelconque des revendications 1 à 7 dans lequel l'étape de déclenchement comprend la redirection de la deuxième requête d'obtention vers un serveur de configuration adapté à générer ou hébergeant le fichier de configuration pour mettre à disposition du terminal ledit fichier de configuration.
9. Procédé d'obtention par un terminal (2) d'un fichier de configuration lui permettant d'accéder à un service, ce procédé comprenant :
— au moins une étape d'émission (E10,E90) d'une première requête d'obtention (REQ1,REQ1') du fichier de configuration comprenant une première adresse d'accès au fichier de configuration ;
— une étape d'émission (E150) d'une deuxième requête d'obtention (REQ2) du fichier de configuration, déclenchée suite à la réception (E140) en réponse à la première requête d'obtention d'une deuxième adresse d'accès (URL2) au fichier de configuration incluant un jeton sécurisé généré pour le terminal par un serveur de gestion du service, ladite deuxième requête d'obtention comprenant ladite deuxième adresse ;
— une étape de réception (E220) du fichier de configuration en provenance d'un serveur de configuration (6) apte à générer ou à héberger le fichier de configuration.
10. Procédé de traitement de requêtes d'obtention (REQ1,REQ1',REQ2) par un terminal d'un fichier de configuration pour accéder à un service, ce procédé étant destiné à être mis en œuvre par un serveur mandataire inverse (7) placé entre le terminal (2) et un serveur de gestion (4) du service, le procédé comprenant : — au moins une première étape de redirection (E20,E100) vers le serveur de gestion du service, d'une première requête d'obtention (REQ1,REQ1') par le terminal du fichier de configuration, ladite première requête d'obtention comprenant une première adresse (URL1) d'accès au fichier de configuration ; et
— une deuxième étape de redirection (E160) d'une deuxième requête d'obtention (REQ2) par le terminal du fichier de configuration, ladite deuxième requête d'obtention comprenant une deuxième adresse (URL2) d'accès au fichier de configuration fournie par le serveur de gestion au terminal par l'intermédiaire du serveur mandataire inverse et incluant un jeton sécurisé généré par le serveur de gestion pour le terminal.
11. Procédé de traitement selon la revendication 10 comprenant en outre une troisième étape de redirection (E190) de la deuxième requête d'obtention vers un serveur de configuration adapté à générer ou hébergeant le fichier de configuration, ladite troisième étape de redirection étant déclenchée suite à la réception d'un message du serveur de gestion déclenchant une mise à disposition du terminal du fichier de configuration et comprenant une adresse du serveur de configuration.
12. Serveur de gestion (4) d'un service, configuré pour contrôler l'obtention par un terminal d'un fichier de configuration lui permettant d'accéder au service, le serveur de gestion comprenant :
— un module d'application (4A) d'une configuration par défaut selon laquelle le serveur de gestion rejette toute requête d'obtention d'un fichier de configuration par un terminal tant que ce terminal n'est pas associé à un utilisateur dans une base de données du serveur de gestion ;
— des modules, activés sur réception d'une première requête d'obtention du fichier de configuration par un terminal comprenant une première adresse d'accès au fichier de configuration, et comprenant :
o un premier module de vérification (4B), configuré pour vérifier si le terminal est associé à un utilisateur dans la base de données ;
o un module de génération (4C) d'un jeton sécurisé pour le terminal et un module de transmission (4D) à destination du terminal d'une deuxième adresse d'accès au fichier de configuration incluant le jeton sécurisé, le module de génération et le module de transmission étant activés si le premier module de vérification détermine que le terminal est associé à un utilisateur dans la base de données ;
— des modules, activés sur réception d'une deuxième requête d'obtention du fichier de configuration par le terminal comprenant la deuxième adresse, et comprenant : o un deuxième module de vérification (4E), configuré pour vérifier si le jeton sécurisé inclus dans la deuxième adresse comprise dans la deuxième requête d'obtention est valide ; et
o un module de déclenchement (4F) d'une mise à disposition du terminal du fichier de configuration activé si le deuxième module de vérification détermine que le jeton est valide.
13. Terminal (2) comprenant :
— un premier module d'émission (2A) configuré pour émettre au moins une première requête d'obtention d'un fichier de configuration pour accéder à un service, ladite au moins une première requête d'obtention comprenant une première adresse d'accès au fichier de configuration ;
— un deuxième module d'émission (2B), activé sur réception en réponse à la première requête d'obtention d'une deuxième adresse d'accès au fichier de configuration incluant un jeton sécurisé généré pour le terminal par un serveur de gestion du service, et configuré pour émettre une deuxième requête d'obtention du fichier de configuration comprenant la deuxième adresse ; et
— un module de réception (2C) adapté à recevoir le fichier de configuration en provenance d'un serveur de configuration apte à générer ou à héberger le fichier de configuration.
14. Serveur mandataire inverse (7) placé entre un terminal et un serveur de gestion d'un service, ce serveur mandataire inverse comprenant :
— un premier module de redirection (7A), configuré pour rediriger vers le serveur de gestion au moins une première requête d'obtention par un terminal d'un fichier de configuration destiné à permettre audit terminal d'accéder au service, ladite au moins une première requête d'obtention comprenant une première adresse d'accès au fichier de configuration ; et
— un deuxième module de redirection (7B), configuré pour rediriger vers le serveur de gestion une deuxième requête d'obtention par le terminal du fichier de configuration, ladite deuxième requête d'obtention comprenant une deuxième adresse d'accès au fichier de configuration fournie par le serveur de gestion au terminal par l'intermédiaire du serveur mandataire inverse et incluant un jeton sécurisé généré par le serveur de gestion pour le terminal.
15. Serveur mandataire selon la revendication 14 comprenant en outre un troisième module de redirection (7C) configuré pour rediriger la deuxième requête d'obtention vers un serveur de configuration adapté à générer ou hébergeant le fichier de configuration, ledit troisième module de redirection étant activé sur réception d'un message du serveur de gestion déclenchant une mise à disposition du terminal du fichier de configuration et comprenant une adresse du serveur de configuration.
16. Système de contrôle (1) de l'obtention d'un fichier de configuration par un terminal pour accéder à un service, ledit système comprenant :
— un serveur de gestion (4) du service conforme à la revendication 11 ;
— un serveur mandataire inverse (7) conforme à la revendication 13 ou à la revendication 14, placé entre le terminal et le serveur de gestion ; et
— un serveur de configuration (6) apte à générer ou hébergeant le fichier de configuration, et configuré pour fournir le fichier de configuration au terminal sur réception d'un message du serveur de gestion ou du serveur mandataire inverse.
EP18749431.5A 2017-06-20 2018-06-14 Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration Pending EP3643035A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1755628A FR3067538A1 (fr) 2017-06-20 2017-06-20 Procede de controle de l'obtention par un terminal d'un fichier de configuration
PCT/FR2018/051404 WO2018234662A1 (fr) 2017-06-20 2018-06-14 Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration

Publications (1)

Publication Number Publication Date
EP3643035A1 true EP3643035A1 (fr) 2020-04-29

Family

ID=59811531

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18749431.5A Pending EP3643035A1 (fr) 2017-06-20 2018-06-14 Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration

Country Status (3)

Country Link
EP (1) EP3643035A1 (fr)
FR (1) FR3067538A1 (fr)
WO (1) WO2018234662A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6318940B2 (ja) * 2013-07-30 2018-05-09 株式会社リコー サービス提供システム、データ提供方法及びプログラム
US9426156B2 (en) * 2013-11-19 2016-08-23 Care Innovations, Llc System and method for facilitating federated user provisioning through a cloud-based system
FR3015168A1 (fr) * 2013-12-12 2015-06-19 Orange Procede d'authentification par jeton

Also Published As

Publication number Publication date
WO2018234662A1 (fr) 2018-12-27
FR3067538A1 (fr) 2018-12-14

Similar Documents

Publication Publication Date Title
EP2819052B1 (fr) Procédé et serveur de traitement d'une requête d'accès d'un terminal à une ressource informatique
EP3008872B1 (fr) Procédé d'authentification d'un terminal par une passerelle d'un réseau interne protégé par une entité de sécurisation des accès
EP2692089B1 (fr) Mécanisme de redirection entrante sur un proxy inverse
EP3503508A1 (fr) Procédé de traitement de requêtes et serveur proxy
WO2013093314A1 (fr) Procede d'acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
WO2020016504A1 (fr) Dispositifs et procedes de gestion d'un attachement d'un dispositif de communication a un reseau d'un operateur
EP3643035A1 (fr) Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration
WO2019239029A1 (fr) Procédé de traitement de messages par un dispositif d'un réseau de voix sur ip
EP3149902B1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
WO2023083770A1 (fr) Procédé de recherche de données sensibles dans au moins un paquet de données, dispositif et système associés
WO2023083772A1 (fr) Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés
WO2023083769A1 (fr) Procédé de traitement d'au moins un paquet de données, dispositif et système associés.
WO2023083771A1 (fr) Procédés de contrôle, de vérification et de configuration, et entités configurées pour mettre en œuvre ces procédés
WO2024068722A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
EP4073999A1 (fr) Procede de traitement de requetes de resolution de nom de domaine
EP3820112A1 (fr) Procédé de configuration d accès à un service internet
EP4158872A1 (fr) Procede de delegation de la livraison de contenus a un serveur cache
EP4128717A1 (fr) Délégation d'une fonction de résolution d'identifiants de nommage
FR3076638A1 (fr) Procede de gestion d'un acces a une page web d'authentification
WO2017089710A1 (fr) Procédé de distribution de droits sur un service et plateforme de service
EP3360293A1 (fr) Moyens de gestion d'accès à des données

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200114

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210428

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE