FR3110262A1 - Procédé et système d’authentification d’un utilisateur auprès d’un serveur d’authentification - Google Patents
Procédé et système d’authentification d’un utilisateur auprès d’un serveur d’authentification Download PDFInfo
- Publication number
- FR3110262A1 FR3110262A1 FR2004981A FR2004981A FR3110262A1 FR 3110262 A1 FR3110262 A1 FR 3110262A1 FR 2004981 A FR2004981 A FR 2004981A FR 2004981 A FR2004981 A FR 2004981A FR 3110262 A1 FR3110262 A1 FR 3110262A1
- Authority
- FR
- France
- Prior art keywords
- user
- authentication server
- access token
- application
- authentication
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 33
- 230000004044 response Effects 0.000 claims abstract description 24
- 230000000750 progressive effect Effects 0.000 claims abstract description 22
- 238000004590 computer program Methods 0.000 claims description 9
- 238000009877 rendering Methods 0.000 claims description 5
- 238000010200 validation analysis Methods 0.000 claims description 5
- 230000005540 biological transmission Effects 0.000 claims description 4
- 238000004891 communication Methods 0.000 description 9
- 238000011161 development Methods 0.000 description 9
- 230000018109 developmental process Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000005055 memory storage Effects 0.000 description 2
- 239000013308 plastic optical fiber Substances 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 241001112258 Moca Species 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/42—User authentication using separate channels for security data
- G06F21/43—User authentication using separate channels for security data wireless channels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
- H04L63/0846—Network architectures or network communication protocols for network security for authentication of entities using passwords using time-dependent-passwords, e.g. periodically changing passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
Abstract
L’invention concerne un procédé d’authentification d’un utilisateur auprès d’un serveur d’authentification à travers une application web progressive encapsulée dans un composant système. Le procédé comporte comportant des étapes de :obtention (210) d’un identifiant et d’un mot de passe de l’utilisateur par une application du serveur d’authentification ;authentification (220) de l’utilisateur par l’application du serveur d’authentification à partir de l’identifiant et du mot de passe obtenus ;si l’authentification de l’utilisateur échoue, émission (230), par l’application du serveur d’authentification, d’une réponse informant l’utilisateur de l’échec de connexion, et si l’authentification de l’utilisateur réussie, émission d’un jeton d’accès par l’application du serveur d’authentification ;réception (240) du jeton d’accès par un composant intermédiaire jouant le rôle de pont entre l’application du serveur d’authentification et le composant système du dispositif client mobile ;si la réponse comporte un jeton d’accès, émission (250) du jeton d’accès au composant système. Figure pour l’abrégé : Figure 2
Description
L’invention concerne les procédés et dispositifs d’authentification d’un utilisateur auprès d’un serveur d’authentification à travers une application d’un dispositif mobile. En particulier, l’invention concerne l’authentification d’un utilisateur pour accéder à un service en ligne requérant une authentification préalable.
Arrière-plan technologique.
La technologie client-serveur, utilisée pour le World Wide Web, utilise un navigateur web d’un dispositif client pour envoyer des requêtes à un serveur. Le serveur répond à ces requêtes en envoyant des instructions au navigateur web qui les interprète pour afficher des pages web.
Une application web utilise cette technique pour mettre en œuvre son interface graphique. Celle-ci est composée de pages web créées de toutes pièces par le serveur lors de chaque requête. Chaque hyperlien contenu dans une page web provoque l'envoi d'une nouvelle requête, qui donnera en résultat une nouvelle page web. A la différence d'un site web statique où les pages web sont des fichiers préalablement enregistrés.
Une application web est donc une application manipulable directement en ligne grâce à un navigateur web et ne nécessite donc pas d’installation sur des dispositifs client, contrairement aux applications natives qui sont construites en utilisant un langage de programmation spécifique aux systèmes d’exploitation installés sur ces dispositifs client. L’usage du navigateur web comme partie client assure la portabilité d’une application web.
De la même manière que les sites web, une application web est généralement installée sur un serveur et se manipule en actionnant des composants d’interface graphiques (en anglais « widgets ») à l’aide d’un navigateur web, via un réseau informatique (Internet, intranet, réseau local,…). Par exemple, les messageries web, les systèmes de gestion de contenu, les wikis et les blogs sont des applications web. Les moteurs de recherche, les logiciels de commerce électronique, les jeux en ligne, les logiciels de forum, les agrégateurs peuvent être sous forme d’application web.
Une application hybride est une application utilisant un composant système, (communément appelé « webview » en anglais), qui se comporte comme un navigateur web intégré à un dispositif client mobile, c’est-à-dire qu’il permet le rendu et l’affichage de page web. Un tel composant système utilise des technologies web (HTML, CSS et Javascript) pour fonctionner sur différents systèmes d’exploitation (iOS, Android par exemple). Une telle application hybride utilise alors des fonctionnalités natives des dispositifs client mobiles et peut être distribuée sur des plateformes d’applications telles que l' »AppStore » ou le « Google Play ». A cet effet, le développement d’application hybride passe par l’utilisation d’un environnement de développement qui transfère les concepts de développement web dans le développement mobile. Bien que le langage de développement pour ces applications soit JavaScript, le résultat est une véritable application native. React Natif est un exemple d’environnement de développement mais uniquement pour les plateformes iOS et Android.
L’un des avantages de l’utilisation d’un environnement de développement tel que REACT native par rapport à l’option de développer une application native est que l'on gagne beaucoup de temps de développement et de mise à jour de ces applications hybrides. Il n'est pas nécessaire de développer deux applications différentes car, au lieu d’utiliser des codes différents, on peut utiliser un même code source pour des systèmes d’exploitation différents tels que iOS ou Android. D’où un gain de temps dans la conception, la maintenance corrective ou encore dans la mise en place des évolutions.
De multiples services en ligne (réseaux sociaux, commerce, etc.) sont mis en œuvre sous forme d’applications hybrides pour faciliter leur déploiement et leur maintenance.
Toutefois, utiliser des applications hybrides pour implémenter ce type de service peut poser un problème lorsque ces services requièrent une authentification d’un utilisateur auprès d’un serveur d’authentification. En effet, dans un service d’authentification, il est classique qu’un utilisateur utilise un dispositif client mobile pour émettre une requête d’authentification à destination d’un serveur d’authentification. Le serveur d’authentification réceptionne cette requête et authentifie l’utilisateur en déterminant si cet utilisateur a accès ou pas au service en ligne. Si l’authentification réussie alors le serveur d’authentification émet sa réponse au dispositif client mobile. Cette réponse contient, entre autres, un jeton, communément appelé jeton d’accès de type JWT (en anglais « JSON Web Token ») pouvant inclure diverses informations de l’utilisateur telles que son identifiant, son nom, son prénom, etc.
Certains fabricants de dispositifs client mobiles n’autorisent pas la réception de tel jeton d’accès par une application hybride pour des raisons de sécurité informatique et de protection de données privées.
Il se pose donc le problème d’utiliser une application hybride pour développer un service en ligne qui requiert une authentification des utilisateurs auprès d’un serveur d’authentification.
Un objet de l’invention est de déployer un service d’authentification entre un serveur d’authentification et un dispositif client mobile.
Un autre objet de l’invention est de déployer un service en ligne qui requiert une authentification préalable d’un utilisateur.
Selon un premier aspect, l’invention concerne un procédé d’authentification d’un utilisateur auprès d’un serveur d’authentification à travers une application web progressive encapsulée dans un composant système permettant le rendu et l’affichage de pages web sur un dispositif client mobile, comportant une étape d’obtention d’un identifiant et d’un mot de passe de l’utilisateur par une application du serveur d’authentification ; une étape d’authentification de l’utilisateur par l’application du serveur d’authentification à partir de l’identifiant et du mot de passe obtenus ; si l’authentification de l’utilisateur échoue, une étape d’émission, par l’application du serveur d’authentification, d’une réponse informant l’utilisateur de l’échec de connexion, et si l’authentification de l’utilisateur réussie, une étape d’émission d’un jeton d’accès par l’application du serveur d’authentification; une étape de réception du jeton d’accès par un composant intermédiaire jouant le rôle de pont entre l’application du serveur d’authentification et le composant système du dispositif client mobile; si la réponse comporte un jeton d’accès, une étape d’émission du jeton d’accès au composant système qui stocke alors ce jeton d’accès.
Le procédé d’authentification utilise un composant intermédiaire qui joue le rôle de pont entre l’application du serveur d’authentification et le composant système du dispositif client mobile. Ainsi, le jeton d’accès n’est pas reçu directement par l’application web progressive mais par ce composant intermédiaire qui le transmet ensuite au composant interne qui encapsule cette application web progressive, évitant ainsi le problème de sécurité informatique et de protection de données privées évoqués ci-dessus.
Selon un exemple de réalisation, le jeton d’accès inclue une date limite d’expiration.
Selon un exemple de réalisation, l’application web progressive émet périodiquement une requête de rafraîchissement du jeton d’accès et l’application du serveur d’authentification répond une réponse comportant un autre jeton d’accès valide.
Selon un exemple de réalisation, la période d’émission de la requête de rafraîchissement dépend de la durée de validé de ce jeton d’accès.
Selon un exemple de réalisation, l’identifiant et le mot de passe sont obtenus à partir de saisies faites par l’utilisateur à partir d’un composant d’interface graphique.
Selon un exemple de réalisation, l’identifiant et le mot de passe sont obtenus par l’application du serveur d’authentification à partir d’un serveur d’authentification d’un réseau social.
Selon un deuxième aspect, l’invention concerne un dispositif client mobile comprenant des moyens pour la mise en œuvre partielle des étapes du procédé selon le premier aspect de l’invention.
Selon un troisième aspect, l’invention concerne un système d’authentification d’un utilisateur auprès d’un serveur d’authentification à partir d’un dispositif client mobile selon le second aspect de l’invention.
Selon un cinquième aspect, l’invention concerne un produit programme d’ordinateur comportant des instructions adaptées pour l’exécution des étapes des procédés selon le premier aspect lorsque le programme d’ordinateur est exécuté par au moins un processeur.
Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
Selon un sixième aspect, l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect de l’invention.
D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur.
D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des figures
D’autres caractéristiques et avantages de l’invention ressortiront de la description des modes de réalisation non limitatifs de l’invention ci-après, en référence aux figures 1 à 8 annexées, sur lesquelles :
Des procédés et dispositifs vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 8.
Le système 100 comporte un serveur d’authentification 110 connecté à au moins l’un des deux dispositifs client mobile 120 (130). Sur l’exemple de la figure 1, le serveur 100 est connecté au dispositif client mobile 300 sur lequel est installé le système d’exploitation Androïd et au dispositif client mobile 400 sur lequel est installé le système d’opération iOS.
Le serveur d’authentification 110 comporte une API 111 qui communique avec une base de données 112. Une API (en anglais « Application Programming Interface ») est une partie d’un programme qui est exposée au monde extérieur pour manipuler celui-ci. Une API permet d’entrer des données et de les récupérer à la sortie d’un traitement mis en œuvre par ce programme. Initialement, une API regroupe un ensemble de fonctions ou méthodes, leurs signatures et ordre d’usage pour obtenir un résultat. La mise en place d’une API permet d’opérer une séparation des responsabilités entre le serveur d’authentification 110 et les dispositifs client mobiles 120 et 130. Cette séparation permet donc une portabilité et une évolutivité grandement améliorées.
L’API 111 suit une architecture REST (en anglais Representational State Transfer (REST). Une architecture REST est une solution permettant à un dispositif client mobile d’accéder à un service en ligne. Elle utilise le protocole de transfert hypertexte HTTP (en anglais HyperText Transfert Protocol) et se doit d’être sans état. Ainsi, chaque requête doit contenir l’ensemble des informations nécessaires à son traitement. Cela signifie que l’on dispose d’un identifiant uniforme de ressource, en bref URI (de l’anglais « Uniform Ressource Identifier »), pour chaque ressource que l’on souhaite manipuler. Différentes fonctions du protocole HTTP (POST, GET, PUT, …) sont alors associées aux actions que l’on souhaite effectuer grâce à l’API. Ainsi, les actions ne font pas partie de l'URI, elles sont directement effectuées selon la méthode HTTP utilisée. Pour chaque réponse renvoyée par l’API, un code doit être envoyé, ce code correspond à l’état de la requête et dépend de la réussite ou non de celle-ci. L’utilisation d’une API suivant une architecture REST permet donc au serveur 110 de traiter indifféremment les requêtes de plusieurs dispositifs client mobiles 120 (130) via de multiples instances de serveurs.
Le dispositif client mobile 120 (130) implémente un composant système 121 (131) de type navigateur intégré (en anglais « webview ») tel que défini précédemment dans la partie introductive. Par ailleurs, le composant système 121 est associé à une mémoire locale 123 et le composant système 131 est associé à une mémoire locale 133. Ainsi, le composant système 121 (131) peut mémoriser des données dans la mémoire locale 123 (133) au même titre qu’un navigateur web peut mémoriser des données dans une mémoire locale.
Les composants systèmes 121 et 131 dépendent du système d’exploitation installé. Ainsi, le dispositif client mobile 120 implémente un composant système 121 spécifique pour le système d’exploitation Androïd tandis que le dispositif client mobile 130 implémente un composant système 131 spécifique pour le système d’exploitation iOS.
Les dispositifs client mobiles 121 et 131 implémentent aussi une application web progressive, en anglais « progressive web application » (PWA). Une application web progressive est une application web qui consiste en des pages ou des sites web qui peuvent apparaître à l’utilisateur de la même manière qu’une application natives. Ce type d'applications tente de combiner des fonctionnalités offertes par la plupart des navigateurs modernes avec les avantages de l'expérience offerte par les appareils mobiles. L’un des avantages des applications web progressive est de conjuguer rapidité, fluidité et légèreté tout en permettant de limiter considérablement les coûts de développement : plus besoin de faire des développements spécifiques pour les applications en fonction du système d’exploitation installé sur un dispositif client mobile.
Le service d’authentification, qui va être décrit en détails par la suite, est mis partiellement en œuvre par une application web progressive 140 encapsulée dans les composants système 121 et 131. Pour ce faire, une première instance de l’application web progressive 140 est encapsulée dans le composant système 121 du dispositif client mobile 120 et une seconde instance (clone de la première instance) de l’application web progressive 140 est encapsulée dans le composant système 131 du dispositif client mobile 130. Le service d’authentification est aussi mis partiellement en œuvre par l’API 111 et par un composant intermédiaire 122, respectivement 132, qui se présente sous la forme d’un ensemble d’instructions d’un programme. Ce composant intermédiaire 122 (132) joue le rôle de pont (en anglais « bridge ») entre l’API 111 et le composant système 121 (131).
Selon un mode de réalisation, le composant intermédiaire se présente sous la forme d’un code Javascript issue de la librairie REACT (aussi appelé React.js ou ReactJS). La librairie REACT a pour principal objectif de faciliter la création d’application web monopage, via la création de composants dépendant d'un état et générant une page (ou portion) HTML à chaque changement d'état. C’est une librairie qui ne gère que l'interface d’une application. REACT native est une autre librairie basée sur la librairie REACT qui permet de créer des applications mobiles avec des fonctionnalités natives d’un appareil implémentant une système d’exploitation Android ou iOS. Les principes de fonctionnement de REACT native sont pratiquement similaires à ceux de REACT, à la différence près que REACT native ne manipule pas le modèle d’objets document (en anglais « Document Object Model ») d’une page (ou portion de code HTML). REACT native s’exécute en arrière-plan et interprète le code javascript directement sur l’appareil cible exécutant le programme généré.
Dans une étape 210, un identifiant et un mot de passe d’un utilisateur sont obtenus par l’API 111.
Selon un mode de réalisation de l’étape 210, l’utilisateur saisit un identifiant et un mot de passe à partir d’un composant d’interface graphique. Ce composant peut être un formulaire apparaissant sur l’écran d’un dispositif client mobile 120 (130) utilisé par cet utilisateur. Les interactions avec ce formulaire sont alors assurées par l’application web progressive 140 et le rendu de ce formulaire est assuré par le composant système 121 si le dispositif client mobile est un dispositif Androïd, soit par le composant système 131 si le dispositif client mobile est un dispositif iOS. L’application web progressive 140 génère alors et émet une requête d’authentification comportant l’identifiant et le mot de passe saisis.
Selon une variante, la méthode HTTP POST est utilisée pour cette requête.
Selon un autre mode de réalisation de l’étape 210, l’API 111 reçoit des informations de connexion, tel qu’une adresse email et un mot de passe, de l’utilisateur à un réseau social. Ces informations de connexion sont récupérées, par exemple via une connexion courante de l’utilisateur à un réseau social. L’API 11 envoie alors une requête au serveur d’authentification de ce réseau social pour lui demander des informations relatives à l’utilisateur. Le serveur du réseau social répond un jeton comportant des informations de l’utilisateur. Enfin l’API 111 extrait un identifiant et un mot de passe à partir de ce jeton reçu.
Dans une étape 220, l’API 111 authentifie l’utilisateur à partir de l’identifiant et le mot de passe extraits obtenus.
Selon un exemple, l’authentification commence par tester si l’identifiant obtenu correspond à un identifiant préalablement enregistré dans la base de données 112. Cet identifiant correspond à un compte particulier ou un compte commerçant. Une empreinte numérique servant à identifier le mot de passe est obtenu par exemple par une fonction de hachage ‘en anglais « hash function ») et cette empreinte numérique est comparée avec les empruntes numériques préalablement stockées dans la base de données 112.
Dans une étape 230, si l’un de ces deux tests échoue, l’API 111 renvoie une réponse informant l’utilisateur de l’échec de connexion. Si les deux tests sont concluants, un jeton d’accès, par exemple un jeton JWT (en anglais « JSON Web Token »), incluant la date limite d’expiration de ce dernier est créé. Ce jeton d’accès peut également contenir diverses informations de l’utilisateur tel que son identifiant, son nom, son prénom ,…).
Dans une étape 240, le composant intermédiaire 122 (132) reçoit la réponse émise par l’API 111.
Dans une étape 250, si la réponse comporte un jeton d’accès alors le jeton d’accès est transmis au composant système 121 (131) qui le stocke dans la mémoire locale associé 123 (133). Si la réponse ne comporte pas de jeton d’accès alors l’authentification a échouée et le composant intermédiaire 140 en informe le composant système 121 (131) qui réagit en conséquence. Par exemple, une fenêtre apparaît sur l’écran du dispositif client mobile 120 (130) indiquant à l’utilisateur que l’authentification à partir de l’identifiant et le mot de passe saisis a échoué.
Dans une étape 260 (optionnelle), l’application web progressive 140 génère et émet périodiquement une requête de rafraîchissement du jeton d’accès. La période dépendant de la durée de validé de ce jeton d’accès. L’API 111 répond une réponse comportant un autre jeton d’accès valide.
Selon une variante, la période d’émission de la requête de rafraîchissement dépend de la durée de validé de ce jeton d’accès. Ainsi, dès que la data limite de validé du jeton approche, l’application web progressive 140 génère et émet une requête de rafraîchissement du jeton d’accès.
Des exemples d’un tel dispositif comprennent, sans y être limités, différents appareils électroniques tels qu’un téléphone intelligent (de l’anglais « smartphone »), une tablette, une montre connectée ou tout autre dispositif mobile. Les éléments du dispositif 300, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif 300 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels. Le dispositif 300 comprend un (ou plusieurs) processeur(s) 301 configurés pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif 300. Le processeur 301 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif 300 comprend en outre au moins une mémoire 302, par une mémoire volatile at/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. Ce dispositif de stockage peut être adapté pour mémoriser un coût énergétique associé à un tronçon de route.
Le code informatique comprenant les instructions à charger et exécuter par le processeur est par exemple stocké sur la mémoire ou le dispositif de stockage mémoire 302.
Selon un mode de réalisation particulier et non limitatif, le dispositif 300 comprend un bloc 303 d’éléments d’interface pour communiquer avec des dispositifs externes. Les éléments d’interface du bloc 303 comprennent une ou plusieurs des interfaces suivantes :
- interface radiofréquence RF, par exemple de type Bluetooth® ou Wi-Fi® ;
- interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ;
- interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français) ;
Selon un autre mode de réalisation particulier, le dispositif 300 comprend une interface de communication 304 qui permet d’établir une communication avec d’autres dispositifs tel que l’API 111. L’interface de communication 304 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via un canal de communication 305. L’interface de communication 304 comprend par exemple un modem et/ou une carte réseau et le canal de communication peut par exemple être mis en œuvre dans un medium filaire et/ou sans fil.
Des données sont par exemples échangées avec l’API 111 en utilisant un réseau Wi-Fi® tel que selon IEEE 802.11 via un point d’accès. La communication entre un dispositif 300 et un point d’accès peut alors s’établir selon un protocole de communication sans fil tel que Wifi® (selon IEEE 802.11), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou Bluetooth (selon IEEE 802.15.1), dans la bande de fréquence à 2,4 GHz. Un point d’accès sans fil peut également communiquer avec un autre point d’accès par une liaison filaire (ou « backbone » en anglais), par exemple du type MoCA (de l’anglais « Multimedia over Coax Alliance » ou en français « Alliance multimédia sur coax »), Ethernet, PLC (de l’anglais « Powerline Communication » ou en français CPL « Courants Porteurs en Ligne »), POF (de l’anglais « Plastic Optical Fiber » ou en français « Fibre optique plastique) ou encore ITU G.hn (correspondant au standard pour les technologies de réseaux domestiques de prochaine génération de ITU, de l’anglais « International Telecommunication Union » ou en français « Union internationale des télécommunications »).
Des données peuvent aussi être échangées avec l’API 111 en utilisant un réseau cellulaire tel qu’un réseau 4G (ou LTE Advanced selon 3GPP release 10 – version 10) ou 5G.
Selon un mode de réalisation particulier supplémentaire, le dispositif 300 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes, tels qu’un écran d’affichage 306, un ou des haut-parleurs 307 et/ou d’autres périphériques 308 (système de projection, système de navigation, système d’aide à la conduite) via respectivement des interfaces de sortie 309, 310 et 311. Selon une variante, l’un ou l’autre des dispositifs externes est intégré au dispositif 300. L’écran d’affichage 306 correspond par exemple à un écran, tactile ou non.
Le dispositif client mobile 300 est adapté pour mettre en œuvre le procédé de la figure 2 ou le procédé de la figure 4.
Le procédé de la figure 2 fait partie d’un service en ligne qui n’est donné ici qu’à titre illustratif et qui ne limite en rien l’utilisation du procédé d’authentification de la figure 2 dans tout type de service en ligne requérant au préalable une authentification d’un utilisateur.
Le service en ligne permet de mettre en relation des commerces, des produits vendus dans ces commerces, et des utilisateurs. En bref, le service en ligne consiste à déterminer une zone géographique dans laquelle se trouve un utilisateur et à lui proposer un ensemble de commerces localisés dans cette zone géographique et/ou un ensemble de produits vendus par ces commerces.
Ce service en ligne est mis en œuvre par un serveur de ressources, un serveur d’authentification 110 et un dispositif client mobile 120 ou 130 de la figure 1. Selon notre exemple de mise en œuvre, le serveur de ressources et le serveur d’authentification sont confondus et utilise tous les deux l’API 111 pour communiquer avec l’application web progressive 140 du dispositif client mobile 120 (130) et la base de données 112. D’autres mises en œuvre sont possibles.
Ce service en ligne se compose d’une interface client, pour que des utilisateurs puissent accéder au service en ligne, et d’une interface commerce, pour que des responsables de commerces puissent gérer la liste de leurs clients (utilisateurs enregistrés), gérer les produits qu’ils vendent et dont ils font la publicité ou faire la promotion de leurs produits via le service en ligne.
L’authentification d’un utilisateur ou d’un responsable d’un commerce se fait par un composant d’interface graphique tel qu’un formulaire. Typiquement, un identifiant (adresse email ou pseudo) et un mot de passe sont demandés. Un responsable d’un commerce peut souscrire au service en ligne pour lui permettre d’accéder à l’interface commerce. Un utilisateur peut également souscrire au service en ligne et ainsi devenir un client. La souscription passe par l’affichage d’une page web comportant un composant d’interface graphique, typiquement un formulaire, que le client ou le responsable du commerce remplisse.
L’interface client est une succession de pages web affichées sur l’écran du dispositif client mobile 120 (130). Ces pages web présentent des composants d’interface graphique tels que des icônes, des formulaires ou tout autre moyen classiquement utilisé pour afficher des données ou permettre à un client d’interagir avec le service en ligne.
Selon une étape 510, une page d’accueil est affichée sur l’écran d’affiche du dispositif client mobile (figure 5). Cette page d’accueil comporte un composant d’interface graphique 511 invitant un client à saisir un nom de ville, par exemple Lille. Une zone géographique recouvrant cette ville est alors déduite de ce nom de ville saisi.
Selon une variante de cette étape 510, la position géographique du client peut être obtenue à partir d’un récepteur satellitaire de type GPS (en anglais « Global Positioning System ») embarqué dans son dispositif client mobile et une zone géographique est déterminée autour de cette position géographique.
Dans une étape 520, le client click sur le composant d’interface graphique 511. Une page web de la figure 6 est affichée invitant le client à saisir un nom de ville via un composant d’interface graphique 611. Le client saisi alors un nom de ville.
Dans une étape 530, l’application web progressive 140 émet une requête à destination de l’API 111 pour lui demander une liste L de commerces et/ou de produits vendus dans des commerces localisés dans la zone géographique déterminée. L’API 111 communique avec la base de données 112 pour constituer cette liste L. L’API 111 forme alors une réponse qui comporte la liste L si au moins un commerce ou un produit vendu dans un commerce est enregistré dans la base de données 112. Dans le cas contraire, l’API 111 retourne une réponse sans liste. L’API 111 émet alors la réponse.
Dans une étape 540, l’application web progressive 140 reçoit cette réponse et examine si la réponse contient une liste L.
Si ce n’est pas le cas, dans une étape 550, la page d’accueil de la figure 5 s’affiche.
Si la réponse contient une liste L, dans une étape 560, la liste L s’affiche dans une page web (voire plusieurs successives si la liste comporte un nombre important d’éléments et/ou selon la configuration de la page web). Selon un exemple, une liste de composants d’interface graphique, tels que des icônes et/ou des photos représentant chacun un élément de la liste L est affiché. Selon un exemple non limitatif, illustré par la figure 7, la page web affichée se compose de 10 icônes représentant chacun soit un commerce soit un produit. L’un de ces icônes représente un lien vers une page web de souscription. Ceci n’est qu’un exemple d’affichage de la liste L.
Selon une variante, la page web peut aussi comporter un composant d’interface graphique 711 (figure 7) qui permet le filtrage des éléments de la liste L selon des critères tels qu’un secteur d'activité, un type de produit ou de commerce. Un client peut alors choisir l’un de ces critères pour filtrer la liste L par interaction avec ce composant d’interface graphique. Une nouvelle page web est alors affichée dont le contenu dépend des critère de filtrage choisis. La figure 8 donne un exemple de page Web résultante de l’application d’un filtre sur la liste L selon un critère de secteur d’activités.
Selon une variante, la page web comporte également un composant d’interface graphique 712 (figure 7) qui permette la recherche d’un commerce ou d’un produit de la liste L. Un client peut alors saisir un nom de commerce ou de produit via ce composant d’interface. Une nouvelle page web est alors affichée dont le contenu dépend du commerce ou produit saisi.
L’interface commerce est une succession de pages web affichées sur l’écran du dispositif client mobile 120 (130). Ces pages web présentent des composants d’interface graphique tels que des icônes, des formulaires ou tout autre moyen classiquement utilisé pour afficher des données ou permettre à un responsable de commerce d’interagir avec les informations qu’il a enregistrées ou qu’il souhaite enregistrer via le service en ligne. Des responsables de commerce peuvent ainsi gérer la liste de clients, envoyer des offres promotionnelles sur certains produits, ajouter de nouveaux produits, en retirer.
Bien entendu, l’invention ne se limite pas aux modes de réalisation décrits ci-avant mais s’étend à la mise en œuvre de tout service en ligne requérant une authentification d’un utilisateur pour accéder au service en ligne.
Claims (10)
- Procédé d’authentification d’un utilisateur auprès d’un serveur d’authentification à travers une application web progressive encapsulée dans un composant système permettant le rendu et l’affichage de pages web sur un dispositif client mobile, comportant des étapes de :
obtention (210) d’un identifiant et d’un mot de passe de l’utilisateur par une application du serveur d’authentification ;
authentification (220) de l’utilisateur par l’application du serveur d’authentification à partir de l’identifiant et du mot de passe obtenus ;
si l’authentification de l’utilisateur échoue, émission (230), par l’application du serveur d’authentification, d’une réponse informant l’utilisateur de l’échec de connexion, et si l’authentification de l’utilisateur réussie, émission d’un jeton d’accès par l’application du serveur d’authentification ;
réception (240) du jeton d’accès par un composant intermédiaire jouant le rôle de pont entre l’application du serveur d’authentification et le composant système du dispositif client mobile ;
si la réponse comporte un jeton d’accès, émission du jeton d’accès au composant système qui stocke alors ce jeton d’accès. - Procédé selon la revendication 1, pour lequel le jeton d’accès inclue une date limite d’expiration.
- Procédé selon la revendication 2, pour lequel l’application web progressive émet (260) périodiquement une requête de rafraîchissement du jeton d’accès et l’application du serveur d’authentification répond une réponse comportant un autre jeton d’accès valide.
- Procédé selon la revendication 3, pour lequel une période d’émission de la requête de rafraîchissement dépend de la durée de validé de ce jeton d’accès.
- Procédé selon l’une des revendications 1 à 4, pour lequel l’identifiant et le mot de passe sont obtenus à partir de saisies faites par l’utilisateur à partir d’un composant d’interface graphique.
- Procédé selon l’une des revendications 1 à 4, pour lequel l’identifiant et le mot de passe sont obtenus par l’application du serveur d’authentification à partir d’un serveur d’authentification d’un réseau social.
- Dispositif client mobile comportant :
un écran ;
un composant système permettant le rendu et l’affichage de pages web sur l’écran ;
un composant intermédiaire, jouant le rôle de pont entre une application d’un serveur d’authentification et un composant système du dispositif client mobile, ledit composant intermédiaire pouvant recevoir un jeton d’accès et l’émettre au composant système. - Système d’authentification d’un utilisateur auprès d’un serveur d’authentification à travers une application web progressive encapsulée dans un composant système d’un dispositif client mobile, le système comportant une application du serveur d’authentification pour :
obtenir un identifiant et un mot de passe de l’utilisateur ;
authentifier l’utilisateur à partir de l’identifiant et du mot de passe obtenus ;
si l’authentification de l’utilisateur échoue, émettre une réponse informant l’utilisateur de l’échec de connexion, et si l’authentification de l’utilisateur réussie, émettre un jeton d’accès ;
un composant intermédiaire, jouant le rôle de pont entre l’application du serveur d’authentification et le composant système du dispositif client mobile, pour :
recevoir un jeton d’accès ;
si la réponse comporte un jeton d’accès, émettre le jeton d’accès au composant système. - Produit programme d’ordinateur comportant des instructions adaptées pour l’exécution des étapes du procédé selon l’une des revendications 1 à 6, lorsque le programme d’ordinateur est exécuté par au moins un processeur.
- Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon l’une des revendications 1 à 6.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2004981A FR3110262B1 (fr) | 2020-05-18 | 2020-05-18 | Procédé et système d’authentification d’un utilisateur auprès d’un serveur d’authentification |
| PCT/FR2021/050847 WO2021234255A1 (fr) | 2020-05-18 | 2021-05-17 | Procede et systeme d'authentification d'un utilisateur aupres d'un serveur d'authentification |
| EP21732460.7A EP4154137A1 (fr) | 2020-05-18 | 2021-05-17 | Procede et systeme d'authentification d'un utilisateur aupres d'un serveur d'authentification |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2004981A FR3110262B1 (fr) | 2020-05-18 | 2020-05-18 | Procédé et système d’authentification d’un utilisateur auprès d’un serveur d’authentification |
| FR2004981 | 2020-05-18 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3110262A1 true FR3110262A1 (fr) | 2021-11-19 |
| FR3110262B1 FR3110262B1 (fr) | 2023-06-23 |
Family
ID=72356095
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2004981A Active FR3110262B1 (fr) | 2020-05-18 | 2020-05-18 | Procédé et système d’authentification d’un utilisateur auprès d’un serveur d’authentification |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP4154137A1 (fr) |
| FR (1) | FR3110262B1 (fr) |
| WO (1) | WO2021234255A1 (fr) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140026193A1 (en) * | 2012-07-20 | 2014-01-23 | Paul Saxman | Systems and Methods of Using a Temporary Private Key Between Two Devices |
| US20160366151A1 (en) * | 2015-06-11 | 2016-12-15 | Canon Kabushiki Kaisha | Authentication server system, method, and storage medium |
| US9716724B1 (en) * | 2014-02-24 | 2017-07-25 | Skyhigh Networks, Inc. | Cloud data loss prevention system |
| US20190007409A1 (en) * | 2017-06-30 | 2019-01-03 | Open Text Corporation | Hybrid authentication systems and methods |
-
2020
- 2020-05-18 FR FR2004981A patent/FR3110262B1/fr active Active
-
2021
- 2021-05-17 WO PCT/FR2021/050847 patent/WO2021234255A1/fr unknown
- 2021-05-17 EP EP21732460.7A patent/EP4154137A1/fr not_active Withdrawn
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140026193A1 (en) * | 2012-07-20 | 2014-01-23 | Paul Saxman | Systems and Methods of Using a Temporary Private Key Between Two Devices |
| US9716724B1 (en) * | 2014-02-24 | 2017-07-25 | Skyhigh Networks, Inc. | Cloud data loss prevention system |
| US20160366151A1 (en) * | 2015-06-11 | 2016-12-15 | Canon Kabushiki Kaisha | Authentication server system, method, and storage medium |
| US20190007409A1 (en) * | 2017-06-30 | 2019-01-03 | Open Text Corporation | Hybrid authentication systems and methods |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021234255A1 (fr) | 2021-11-25 |
| EP4154137A1 (fr) | 2023-03-29 |
| FR3110262B1 (fr) | 2023-06-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2017339379B2 (en) | Predictive analysis of computing patterns for preloaded data to reduce processing downtime | |
| EP2795878B1 (fr) | Procédé de partage d'un contenu multimédia entre utilisateurs | |
| EP1909462B1 (fr) | Procédé de mise à disposition cloisonnée d'un service électronique | |
| US11044222B2 (en) | Automated connection of electronic messaging and social networking services method and apparatus | |
| FR2908212A1 (fr) | Applications pour le profilage d'utilisateurs de services de telecommunications | |
| WO2010006914A1 (fr) | Procédé d'authentification d'un utilisateur d'un service sur terminal mobile | |
| WO2014029944A1 (fr) | Accès a distance a des contenus a partir d'un client léger | |
| EP2979430B1 (fr) | Technique de coopération entre une pluralité d'entités clientes | |
| FR3110262A1 (fr) | Procédé et système d’authentification d’un utilisateur auprès d’un serveur d’authentification | |
| WO2017207894A1 (fr) | Procédé pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné | |
| WO2020193773A1 (fr) | Procede de negociation de contrat entre deux parties dans un reseau de telecommunications et dispositifs mettant en oeuvre ce procede | |
| EP3021273A1 (fr) | Procédé de sécurisation d'une transaction entre un terminal mobile et un serveur d'un fournisseur de service par l'intermédiaire d'une plateforme | |
| FR3020164A1 (fr) | Module d'emulation d'au moins une carte de paiement, procede, dispositif de paiement, produit programme d'ordinateur et medium de stockage correspondants | |
| EP1894407B1 (fr) | Procede et dispositif de securite pour la gestion d'acces a des contenus multimedias | |
| EP4078922B1 (fr) | Procédé d'obtention d'une commande relative à un profil d'accès réseau d'un module de sécurité de type euicc | |
| EP3520008A1 (fr) | Contrôle de délégation de droits | |
| FR3065606A1 (fr) | Procedes pour le partage de donnees de localisation entre un dispositif source et un dispositif destinataire, serveur, dispositifs source et destinataire et programme d'ordinateur correspondants. | |
| EP4320534A1 (fr) | Méthode de contrôle d'accès à un bien ou service distribué par un réseau de communication de données | |
| WO2007113409A1 (fr) | Procede et dispositif de gestion des instances d'une application informatique | |
| EP4294067A1 (fr) | Gestion de l authentification d'un terminal pour accéder à un service d'un fournisseur de service | |
| FR2936331A1 (fr) | Portail informatique avec modification automatique d'affichage | |
| FR2941835A1 (fr) | Procede et dispositif de veille sur un reseau d'information | |
| FR3042362A1 (fr) | Moyens de gestion d'acces a des donnees | |
| FR3038199A1 (fr) | Procede et dispositif de mise a jour des capacites d'un objet connecte a un reseau de communications | |
| FR2860365A1 (fr) | Procede et systeme de mise a disposition d'informations de taxation d'un service payant delivre par un fournisseur de services. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20211119 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |