FR3067538A1 - Procede de controle de l'obtention par un terminal d'un fichier de configuration - Google Patents

Abstract

Le procédé de contrôle est destiné à être mis en œuvre par un serveur de gestion d un service de communication 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

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 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 de communication. 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 (Medium 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.

Il 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 de communication, ce procédé étant destiné à être mis en œuvre par un serveur de gestion du service de communication 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.

Corrélativement, l'invention vise également un serveur de gestion d'un service de communication, configuré pour contrôler l'obtention par un terminal d'un fichier de configuration lui permettant d'accéder au service de communication, 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 (Medium 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.

Il 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 de communication, 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 de communication 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 de communication, 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 de communication, 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 de communication, 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 de communication, 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 de communication, 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 de communication, le procédé comprenant :

— au moins une première étape de redirection vers le serveur de gestion du service de communication, 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 de communication, 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 de communication, 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 terminai.

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 de communication.

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 de communication, ledit système comprenant :

— un serveur de gestion du service de communication 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é cidessus.

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 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. Il 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 UR.L1 (é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 régé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 El 10). 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='EkRooesmoe56razazeg87ARuiipreapr'

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]/[jeton 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 E160).

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.

Claims (15)

1. 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 de communication (S), ce procédé étant destiné à être mis en œuvre par un serveur de gestion (4) du service de communication 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. 2. Procédé de contrôle selon la revendication 1 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.
3. 3. Procédé de contrôle selon la revendication 1 ou 2 dans lequel le jeton sécurisé généré pour le terminal a une durée de validité prédéterminée.
4. 4. Procédé de contrôle selon l'une quelconque des revendications 1 à 3 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é.
5. 5. Procédé de contrôle selon l'une quelconque des revendications 1 à 4 dans lequel la première adresse d'accès (URL1) est configurée avec une adresse MAC (Medium Access Control) du terminal.
6. 6. Procédé de contrôle selon l'une quelconque des revendications 1 à 5 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.
7. 7. Procédé de contrôle selon l'une quelconque des revendications 1 à 5 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.
8. 8. Procédé d'obtention par un terminal (2) d'un fichier de configuration lui permettant d'accéder à un service de communication, 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 de communication, 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.
9. 9. 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 de communication, 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 de communication, le procédé comprenant :

   — au moins une première étape de redirection (E20,E100) vers le serveur de gestion du service de communication, 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.
10. 10. Procédé de traitement selon la revendication 9 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.
11. 11. Serveur de gestion (4) d'un service de communication, configuré pour contrôler l'obtention par un terminal d'un fichier de configuration lui permettant d'accéder au service de communication, 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.
12. 12. 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 de communication, 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 de communication, 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.
13. 13. Serveur mandataire inverse (7) placé entre un terminal et un serveur de gestion d'un service de communication, 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 de communication, 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.
14. 14. Serveur mandataire selon la revendication 13 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.
15. 15. Système de contrôle (1) de l'obtention d'un fichier de configuration par un terminal pour accéder à un service de communication, ledit système comprenant :

    — un serveur de gestion (4) du service de communication 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.