Brevet FR3093835A1 — publié le 20200918

Description Titre de l'invention : Réseau informatique pour un accès sécurisé à des applications en ligne [0001] La présente invention concerne un procédé et un réseau informatique pour fournir un accès sécurisé à des applications pour un ou plusieurs utilisateurs. L'invention est particulièrement bien adaptée aux systèmes de réservation informatiques en ligne (CRS), à savoir pour gérer la réservation des vols. [0002] Un tel système est un réseau informatique comprend généralement un ou plusieurs serveurs d'applications hébergeant une pluralité d'applications, appelées les applications CRS. Par exemple, ces applications sont utilisées pour fournir des services en ligne pour une variété de tâches, telles que la réservation de billets d'avion ou de chambres d'hôtel, la recherche d'offres de voyage et des tarifs correspondants. [0003] 11 est possible d'accéder aux applications CRS de n'importe où dans le monde, à tout moment et par tout dispositif (par ex., ordinateur de bureau, ordinateur portable, téléphone mobile, tablette). Par conséquent, il existe un besoin de fournir un accès sécurisé à ses applications CRS et donc d'assurer la sécurité des données qui sont distribuées via les applications CRS. [0004] À la réception d'une demande émise par un utilisateur pour accéder à une ap- plication, le serveur d'applications hébergeant l'application peut autoriser l'accès à l'application. Pour protéger l'accès et empêcher l'usage abusif du CRS, des composants de sécurité sont fournis dans le CRS. Par exemple, un serveur dc sécurité d'ouverture de session (LSS) peut être fourni pour autoriser ou refuser l'accès à un utilisateur demandant l'accès à une application, sur la base des données contenues dans un fichier de contrôle d'accès générique central (GAC) et dans la demande d'accès dc l'utilisateur. [0005] Plus spécifiquement, chaque application dans le CRS demandant un contrôle d'accès est fournie avec un composant d'identification. Même si tous ces composants d'identification sont finalement connectés à un LSS centralisé, chaque application va mettre en oeuvre son propre composant d'identification connecté au LSS. [0006] Par conséquent, l'utilisateur de chaque application est confronté à une interface uti- lisateur différente pour l'identification. De plus, la connexion entre les composants d'identification et le LSS n'est pas toujours garantie, en raison des incompatibilités résultant des différences dans la structure du message authentification, ou des différences dans les versions entre les composants d'identification, etc. [0007] De plus, une fois que l'utilisateur est identifié, il/elle devrait être capable (ou non) d'accéder au service par les applications exécutées sur les serveurs d'applications dis- 2 trihuées dans l'extrémité arrière ouverte (OBE) du réseau informatique CRS. L'accès ou le refus d'accès au service se hase sur les droits d'accès de l'utilisateur respectifs qui sont stockés dans le GAC. [0008] Le GAC est un module qui héberge une hase de données ou un fichier central isé(c) qui contient les informations du compte de tous les utilisateurs enregistrés, incluant leurs droits d'accès respectifs pour chaque application hébergée par les serveurs distribués. La hase de données GAC peut comprendre plusieurs noeuds pour assurer la stabilité si l'un des noeuds échoue, un autre ne peut être sollicité pour traiter la demande de l'utilisateur. [0009] Le module GAC peut être mis en oeuvre dans SQLite. Le fichier ou la hase de données GAC est stocké(c) dans une mémoire cache sur chaque OBE et dans laquelle l'OBE doit dupliquer le fichier à des intervalles fixes à partir d'un stockage central dans le LSS. [0010] En raison du nombre toujours croissant d'utilisateurs des services CRS, la taille du fichier SQLite GAC augmente rapidement. Par exemple, le fichier GAC peut tripler en trois ans. La taille d'un GAC est à présent typiquement de l'ordre de 6 GB (Giga Bytes). Par conséquent, en raison du grand nombre d'applications CRS différentes contenues dans l'architecture CRS, il est devenu de plus en plus difficile de récupérer, dupliquer ou stocker chaque fichier GAC. [0011] Dans les architectures CRS existantes, le module GAC distribue fréquemment les données utilisateur à toutes les applications sur un grand nombre de serveurs distribués (typiquement 2 000 à 3 000) pour appliquer les changements du compte utilisateur, en particulier concernant ses droits d'accès. Avec une architecture CRS typique comprenant jusqu'à 3 000 serveurs, environ 6 GB de données doivent être distribués sur le réseau chaque heure. [0012] Par conséquent, Il est impératif de réduire cette quantité d'informations pour réduire le trafic global du réseau et optimiser l'usage de ressources du réseau telles que la bande passante, le traitement de l'utilisation et de l'énergie. Ce besoin est devenu d'autant plus important que le nombre d'applications et d'utilisateurs ne cessent d'augmenter dans le monde à un rythme rapide. [0013] Le cadre de sécurité actuel mis en oeuvre dans les réseaux informatiques CRS existants, configurés pour identifier les utilisateurs de services en ligne et pour autoriser ou refuser l'accès à ces services souffre des inconvénients et des déficiences susmentionnés. La présente invention a été conçue pour résoudre une ou plusieurs des préoccupations précédentes. [0014] Selon un premier aspect, un réseau informatique adapté est fourni pour fournir un accès sécurisé aux applications pour un utilisateur, ledit réseau informatique comprenant : 3 au moins un serveur d'applications hébergeant une pluralité d'applications, ledit au moins un serveur d'applications étant adapté pour recevoir une demande d'accès émise par l'utilisateur et pour autoriser l'accès à au moins une de la pluralité d'applications ; un serveur de sécurité d'ouverture de session (LSS) configuré pour décider de l'accès à l'utilisateur sur la hase des données contenues dans un fichier de contrôle d'accès générique central et dans la demande d'accès ; dans lequel le réseau informatique comprend par ailleurs un composant d'identification utilisateur centralisé adapté à l'interface avec ledit au moins un serveur d'applications et le serveur de sécurité d'ouverture de session, ledit au moins un serveur d'applications étant configuré pour transmettre la demande d'accès au composant d'identification d'utilisateur centralisé, ladite demande d'accès comprenant une liste d'au moins une application demandée ; et dans lequel le composant d'identification d'utilisateur centralisé est configuré pour : recevoir la demande d'accès transmise ; afficher un panneau de session d'ouverture central à l'utilisateur, ledit panneau de session d'ouverture central étant adapté à la au moins une application demandée ; la réception des données d'identification de l'utilisateur provenant du panneau de session d'ouverture central ; la transmission desdites données d'identification de la liste d'au moins une application demandée au serveur de sécurité d'ouverture de session ; la récupération dans le serveur de sécurité d'ouverture de session d'une commande d'autorisation ou de refus d'accès pour chacune de la au moins une application demandée ; l'envoi de ladite commande d'autorisation ou de refus d'accès au au moins un serveur d'applications. [0015] Le panneau de session d'ouverture central est une interface d'authentification unique qui peut être avantageusement partagée parmi toutes les applications pour fournir les identifiants de l'utilisateur (login, mot de passe) au serveur de sécurité d'ouverture de session pour l'authentification centralisée. [0016] Le composant d'identification d'utilisateur centralisé et le panneau de session d'ouverture central constitue un point d'entrée unique qui empêche toutes les applications de mettre en oeuvre leur propre panneau de session d'ouverture, simplifiant ainsi l'architecture globale du système tout en fournissant un cadre de sécurité unifié. Cette caractéristique permet d'empêcher la prolifération de modules d'identification propriétaires qui sont difficiles à contrôler et à mettre à jour. [0017] Par ailleurs, les informations non transactionnelles qui sont dans la mémoire cache locale peuvent être avantageusement affichées à l'utilisateur, en réduisant ainsi la quantité de données qui sont transmises via le système informatique pour autoriser ou refuser l'accès à une application en ligne. Le fait que seules les données transactionnelles telles que les identifiants de l'utilisateur soient transmises via le réseau contribue à réduire le temps de réponse pour effectuer l'authentification de l'utilisateur. [0018] Selon une caractéristique, le panneau de session d'ouverture central est associé à une mémoire cache adaptée au stockage des données non transactionnelles associées à ladite au moins une application demandée, au moins une partie desdites données non transactionnelles statiques étant affichées à l'utilisateur par le panneau de session d'ouverture central, lors de l'affichage du panneau d'ouverture de session. [0019] Selon une autre caractéristique, les données non transactionnelles statiques sont dis- tribuées à la mémoire cache au moyen d'une architecture de réseau de distribution de contenu. [0020] Cette architecture est particulièrement efficace pour fournir des données non transac- tionnelles statiques à grande échelle avec un temps de réponse court. [0021] Selon une autre caractéristique, les données non transactionnelles sont sélectionnées par le composant d'identification d'utilisateur centralisé sur la hase d'un emplacement actuel de l'utilisateur et la dite au moins une application demandée. [0022] Selon une autre caractéristique, le panneau de session d'ouverture central est hébergé dans un serveur situé à proximité de l'utilisateur, de sorte que le serveur est situé dans le même pays que l'emplacement de l'utilisateur. Cette caractéristique permet un court temps de réponse. [0023] Selon une autre caractéristique, le composant d'identification d'utilisateur centralisé est hébergé par l'un des serveurs du réseau informatique, en particulier le serveur de sécurité d'ouverture de session. [0024] Selon un autre aspect, le réseau informatique comprend par ailleurs : un composant qui réduit la taille du fichier de contrôle d'accès générique configuré pour : récupérer les données contenues dans le fichier de contrôle d'accès générique, lesdites données incluant les droits d'accès aux dites applications pour une pluralité d'utilisateurs ; éliminer les données redondantes et/ou obsolètes provenant du fichier de contrôle d'accès générique central, de sorte à former un fichier de contrôle d'accès générique purgé une mémoire cache associée au au moins un serveur d'applications pour stocker au moins une partie des données contenues dans le fichier de contrôle d'accès générique purgé. [0025] Par conséquent, la quantité de données qui est transmise via le réseau informatique à savoir au serveur d'applications divers peut être fortement réduite, ce qui permet des exigences de bande passante plus faibles et des temps de réponse plus courts. [0026] Selon une autre caractéristique, le composant réduisant la taille du fichier de contrôle d'accès générique est par ailleurs configure pour diviser le fichier de contrôle d'accès générique central purgé en des fichiers spécifiques à l'application, de sorte à former un fichier de contrôle d'accès générique spécifique à l'application purgé avant de stocker ledit fichier dans ladite mémoire cache. [0027] Selon une autre caractéristique, le composant réduisant la taille du fichier de contrôle d'accès générique est adapté pour accéder au fichier de contrôle d'accès générique sur demande. [0028] Selon une autre caractéristique, le composant réduisant la taille du fichier de contrôle d'accès générique est adapté pour intercepter et analyser les commandes de refus ou d'autorisation d'accès qui sont transmises à partir du composant d'identification d'utilisateur centralisé audit au moins un serveur d'applications et mettre à jour le fichier de contrôle d'accès générique sur la base de l'analyse. [0029] Selon une autre caractéristique, le fichier de contrôle d'accès générique ou le fichier de contrôle d'accès générique réduit ou de taille purgée est un fichier ou une base de données conforme à SQL, en particulier conforme à SQLite. [0030] Selon une autre caractéristique, le composant d'identification d'utilisateur centralisé est mis en oeuvre avec un cadre HTML (HypertextMarkup Language) (Langage de balisage hypertexte)/JQuery léger, en utilisant la technologie de partage des ressources d'origine croisée comme langage de communication. [0031] Dans un autre aspect, un procédé d'identification d'utilisateur centralisé dans un réseau comprend, au niveau d'un composant d'identification d'utilisateur centralisé du réseau : la réception d'une demande d'accès provenant d'au moins un serveur d'applications, la demande d'accès comprenant une liste d'au moins une application demandée ; l'affichage d'un panneau de session d'ouverture central à l'utilisateur, ledit panneau d'ouverture de session central étant adapté conformément à la au moins une application demandée ; la réception des données d'identification de l'utilisateur provenant du panneau de session d'ouverture central ; la transmission desdites données d'identification et la liste d'au moins une application demandée à un serveur de sécurité d'ouverture de session du réseau ; la récupération à partir du serveur de sécurité d'ouverture de session d'une commande de refus ou d'autorisation d'accès pour chacune de la au moins une application demandée ; l'envoi de ladite commande de refus ou d'autorisation d'accès à au moins un serveur d'applications du réseau pour autoriser l'accès à la au moins une application demandée. [0032] Selon d'autres aspects, le procédé comprend des étapes du procédé correspondant à l'une quelconque des fonctions du réseau informatique exposées ci-dessus. [0033] Dans un autre aspect, un produit de programme informatique comprenant des ins- 6 tructions de code de programme stockées sur un support lisible par ordinateur pour exécuter les étapes du procédé selon les procédés exposés ci-dessus, lorsque ledit programme est exécuté sur un ordinateur. [0034] Dans un autre aspect supplémentaire, un système informatique agissant comme un composant d'identification d'utilisateur centralisé d'un réseau est adapté à l'interface avec au moins un serveur d'application et le serveur de sécurité de session d'ouverture du réseau, et ledit composant d'identification d'utilisateur centralisé est configuré pour : recevoir une demande d'accès provenant du au moins un serveur d'applications, la demande d'accès comprenant une liste d'au moins une application demandée ; afficher un panneau de session d'ouverture central à l'utilisateur, ledit panneau d'ouverture de session central étant adapté conformément à la au moins une application demandée ; recevoir des données d'identification de l'utilisateur provenant du panneau de session d'ouverture central ; transmettre lesdites données d'identification et la liste d'au moins une application demandée au serveur de sécurité d'ouverture de session ; récupérer dans le serveur de sécurité d'ouverture de session une commande de refus ou d'autorisation d'accès pour chacune de la au moins une application demandée ; et envoyer ladite commande de refus ou d'autorisation d'accès à au moins un serveur d'applications du réseau pour autoriser l'accès à la au moins une application de mandée. [0035] De plus, dans certains modes de réalisation, le système informatique est par ailleurs configuré pour exécuter l'une quelconque des fonctionnalités définies ci-dessus. [0036] Les présents mécanismes seront à présent décrits conformément à un mode de réa- lisation particulier, au moyen d'un exemple uniquement et en référence aux dessins suivants dans lesquels : [0037] [fig.1] illustre une architecture de réseau informatique conformément à la présente invention. [0038] [fig.2] est un schéma fonctionnel d'un dispositif informatique 100 pour la mise en oeuvre de l'architecture informatique de l'invention. [0039] [fig.3] un organigramme visualisant des activités du procédé selon les modes de réa- lisation enseignés dans les présentes. [0040] Le réseau informatique 1 comme décrit à la Figure 1 est un système de réservation informatique qui peut être mis en oeuvre pour fournir un accès sécurisé à des applications en ligne pour un utilisateur U. Le présent mode de réalisation est décrit dans le contexte de la réservation de voyages. [0041] Le réseau informatique ou CRS 1 comprend un serveur d'applications 10 hébergeant une pluralité d'applications 10.1....,10.n. Par souci de simplicité, seulement un serveur d'applications est considéré dans le présent mode de réalisation la description s'applique également lorsqu'une pluralité de serveurs sont distribués sur Internet pour 7 fournir une pluralité de services en ligne aux utilisateurs. [0042] Chaque élément constitutif du réseau informatique 1 est adapté pour communiquer au moyen de moyens classiques, à savoir via Internet. [0043] Pour accéder à un service en ligne fourni par une ou plusieurs applications sur le serveur d'applications 10, l'utilisateur U envoie 51 au moyen d'un terminal 2 une demande d'accès R1 au serveur d'applications 10. Le terminal 2 peut être un ordinateur personnel tel qu'un ordinateur portable ou un ordinateur de bureau ou un téléphone mobile ou une tablette. La demande d'accès est envoyée via des moyens de communication classiques (par ex., via la 4G, le Wi-Fi, Ethernet, etc). La demande d'accès R1 est générée par un client du serveur d'applications installé sur le terminal de l'utilisateur 2. La demande d'accès R1 comprend une liste d'au moins une application demandée sur ce serveur d'applications 10. Dans d'autres modes de réalisation, plusieurs applications peuvent être demandées sur des serveurs d'applications distincts (non représentés). [0044] À réception de la demande d'accès R1, le serveur d'applications 10 transmet ou transmet 52 la demande d'accès R1 à un composant d'identification d'utilisateur centralisé 40 (abrégé CUIC). Le CUIC 40 est adapté à l'interface avec le serveur d'applications 10 et un serveur de sécurité de session d'ouverture 20 (abrégé LSS). [0045] Le LSS 20 est configuré pour décider de l'accès de l'utilisateur U sur la hase des données contenues dans un fichier de contrôle d'accès générique central 32 et dans la demande d'accès RI. [0046] Un module de contrôle d'accès générique (abrégé GAC) 30 est fourni pour stocker au moins les droits d'accès des utilisateurs enregistrés pour chaque application. Par définition, un utilisateur enregistré est un utilisateur pour lequel un compte a été créé dans le réseau informatique. Dans le présent mode de réalisation, les données des comptes utilisateurs incluant les droits d'accès de l'utilisateur concernant toutes les applications sont stockées sous la forme d'un seul fichier 32 dans une mémoire du module GAC 30. Par exemple, ce fichier est conforme à SQL (Structured Query Language) (Langage d'interrogation structuré) et plus particulièrement à SQLite est particulièrement bien adapté pour interroger et conserver la base de données. Dans d'autres modes de réalisation, ces informations peuvent être stockées dans une base de données, par exemple une base de données relationnelle. Cette base de données peut être conforme à SQL et plus particulièrement à SQLite. [0047] Plus spécifiquement, le CUIC 40 est configuré pour : recevoir S2 la demande d'accès transmise R1 ; afficher S3 un panneau de session d'ouverture central 42 à l'utilisateur, ledit panneau de session d'ouverture étant adapté conformément à la au moins une application demandée ; 8 recevoir S4 les données d'identification de l'utilisateur provenant du panneau de session d'ouverture central 42 ; transmettre S5 lesdites données d'identification et la liste d'au moins une application demandée au serveur de sécurité de session d'ouverture 20 ; récupérer S8 à partir du serveur de sécurité de session d'ouverture 20 une commande de refus ou d'autorisation d'accès pour chacune de la au moins une application demandée ; envoyer S9 ladite commande de refus ou d'autorisation d'accès au serveur d'applications 10. [0048] Dans le présent mode de réalisation, le CUIC 40 est mis en oeuvre avec un cadre HTML/JQuery léger utilisant la technologie partage des ressources d'origine croisée comme un langage de communication. Cette technologie est particulièrement avantageuse étant donné qu'elle soutient tout type de demandes HTML avec un niveau élevé de sécurité. [0049] Le CUIC 40 est de préférence hébergé dans le LSS 20, de sorte à améliorer la latence de l'identification de l'utilisateur. Dans d'autres modes de réalisation, le CUIC 40 peut être hébergé par l'un quelconque des serveurs du réseau informatique 1, où qu'il soit considéré comme plus approprié. [0050] Le panneau de session d'ouverture central 42 (abrégé CLP) est une interface qui est commune à toutes les applications. Il est affiché directement sur le terminal de l'utilisateur 2 à réception de la demande d'accès par le CUIC 40. Le CLP 42 constitue un point d'entrée unique au moyen desquels tout utilisateur demandant l'accès à une application peut soumettre de manière centrale ses identifiants (c.-à-d. le login et le mot de passe enregistré) ou les données d'identification avant d'être dirigé vers l'application demandée La mise en oeuvre du CLP 42 empêche la mise en oeuvre d'un panneau de session d'ouverture séparé dans chaque application individuellement. Cette caractéristique est particulièrement utile, dans la mesure où chaque interface utilisateur pour l'authentification a normalement ses propres exigences de sécurité, telles que le cryptage du mot de passe. [0051] Le CLP 42 peut être hébergé dans un serveur 43 situé à proximité de l'utilisateur. La proximité de ce serveur d'hébergement 43 et de l'utilisateur est avantageuse pour afficher plus rapidement le CLP 42 sur le terminal utilisateur 2. [0052] Par conséquent, la mise en oeuvre du CUIC 40 ainsi que du CLP 42 conformément à la présente invention simplifie sensiblement la mise en oeuvre de l'authentification dans le réseau informatique 1. C'est particulièrement avantageux lors de l'ajout de nouvelles applications hébergées sur des serveurs d'applications distribués supplémentaires ou lors de la mise à niveau des contraintes ou des paramètres de sécurité pour toutes les applications en une seule fois. La mise en oeuvre du CUIC 40 et du 9 CLP 42 pour plus d'une application fournie avantageusement une expérience utilisateur d'identification unifiée sur l'un quelconque des services en ligne CRS avec un point d'entrée unique, permettant ainsi aux administrateurs système de se concentrer sur un composant unique et contribue à améliorer la sécurité du réseau informatique CRS. [0053] Le CPL 42 peut être associé à une mémoire cache locale 44 adaptée pour stocker les données non transactionnelles statiques associées aux applications demandées. Au moins une partie desdites données non transactionnelles statiques peut être affichée à l'utilisateur par le CLP 42 lors de l'affichage du CLP. Par définition, les données non transactionnelles désignent tous les types d'informations non sensibles (par ex., le texte, l'image, la vidéo, le son) excluant les données personnelles fournies par l'utilisateur pour effectuer une transaction (par ex., les détails de carte de crédit transmis pour réserver un vol). Par exemple, les données non transactionnelles peuvent inclure des informations générales qui sont spécifiques à l'application demandée, telles que le logo de la compagnie aérienne auprès de laquelle l'utilisateur a l'intention de réserver un vol. Ainsi, les données non transactionnelles peuvent être avantageusement utilisées pour personnaliser le CPL 42 conformément à la demande d'accès de l'utilisateur R1 reçue par le CUIC 40. Fournir les données non transactionnelles dans la mémoire cache locale 44 particulièrement avantageux pour réduire le temps de chargement des informations à afficher à l'utilisateur sur le CLP 42, particulièrement lorsque ces informations comprennent des images et des vidéos haute résolution. [0054] Les données non transactionnelles statiques peuvent être distribuées à la mémoire cache 44 au moyen d'une architecture de réseau de distribution de contenu. Cette architecture est particulièrement bien adaptée pour fournir efficacement des données non transactionnelles statiques à grande échelle avec des temps de réponse courts. [0055] Les données non transactionnelles peuvent être sélectionnées par le CUIC 40 sur la base de l'emplacement actuel de l'utilisateur et de l'application demandée. Dans ce cas, l'emplacement de l'utilisateur peut être inclus dans la demande d'accès RI par le client utilisateur installé sur le terminal de l'utilisateur 2. Par défaut, l'emplacement de l'utilisateur peut être obtenu à partir de l'adresse IP du terminal de l'utilisateur 2 utilisé pour envoyer l'accès RI par le terminal. [0056] Le CUIC 40 peut être hébergé par l'un des serveurs du réseau informatique 1, en par- ticulier le LSS 20. De préférence, le CLP 42 est hébergé dans un serveur situé à proximité de l'utilisateur. [0057] L'authentification peut être réalisée en utilisant une norme de sécurité telle que Open ID Connect. Cette nonne de sécurité à l'avantage d'être largement utilisée. [0058] Une fois que l'utilisateur U a soumis ses identifiants (fonction S4) via le CPL 42 affiché sur l'écran de son terminal 2, ceux-ci sont reçus par le CUIC 40. [0059] À partir de la demande d'accès de l'utilisateur R1 reçue du serveur d'applications 10 et des identifiants de l'utilisateur reçus du CLP 42 centralisé, le CUIC 40 génère une deuxième demande R2 qui inclut les identifiants de l'utilisateur et la liste des applications demandées au LSS 20 (fonction S5). [0060] À la réception de la deuxième demande R2, le LSS 20 consulte le fichier GAC 32 conservé par le module GAC 30 (fonction S6) et récupère dans celui-ci les droits d'accès de l'utilisateur associé aux applications demandées dans la (fonction S7). Sur la hase des droits d'accès récupérés, le LSS 20 détermine si l'accès devrait être autorisé ou refusé à l'application demandée pour l'utilisateur identifié. [0061] En réponse à la deuxième demande R2, le LSS 20 fournit une commande de refus ou d'autorisation pour chacune des applications pour lesquelles l'accès est requis par l'utilisateur U conformément à la première demande Rl. Cette commande de refus ou d'autorisation est récupérée par le CUIC 40 dans LSS 20 (fonction S8). [0062] Ensuite, la commande de refus ou d'autorisation est envoyée par le CUIC 40 au serveur d'applications 10 hébergeant les applications demandées (fonction S9). À la réception de cette commande, le serveur d'applications 10 autorise ou refuse l'accès à chacune des applications demandées à l'utilisateur (fonction S10). [0063] Selon un autre aspect, le réseau informatique CRS 1 peut par ailleurs comprendre un composant réduisant la taille du fichier de contrôle d'accès générique 50 configure pour : - récupérer les données contenues dans le fichier de contrôle d'accès générique 32, lesdites données incluant les droits d'accès aux dites applications pour une pluralité d'utilisateurs ; - éliminer les données redondantes et/ou obsolètes du fichier de contrôle d'accès générique central 32, de sorte à former un fichier de contrôle d'accès générique purgé 32'. [0064] Le composant réduisant la taille du fichier de contrôle d'accès générique ou le réducteur de taille du fichier GAC 50 (abrégé GACSR) réduit avantageusement la taille du fichier de contrôle d'accès générique en supprimant dans celui-ci toute donnée redondante et/ou obsolète. [0065] Selon la structure des données utilisée pour stocker les informations, le fichier GAC 32 (telles que les données d'identification de l'utilisateur et les droits d'accès correspondants pour les différentes applications), certaines redondances peuvent être supprimées, dans la mesure où les mêmes droits d'accès de l'utilisateur peuvent être répétés dans de multiples champs du fichier ou de la base de données GAC. Le fichier GAC 32 purgé à partir des données redondantes et/ou obsolètes peut être stocké comme un fichier GAC 32' dans une mémoire du module GAC 30. [0066] Selon le présent mode de réalisation, le serveur d'applications 10 comprend par 11 ailleurs une mémoire cache 11 adaptée pour stocker un ou plusieurs fichiers GAC de taille réduite 32.1 obtenu(s) à partir du fichier GAC 32. Ces fichiers GAC de taille réduite 32.1 peuvent être entièrement ou partiellement dupliqués à partir du fichier GAC 32' purgé. Ces fichiers sont transférés à la mémoire cache 11 du serveur d'applications 10 par des moyens de communication du réseau classiques. [0067] Par exemple, les inventeurs ont montré que l'élimination de redondance mise en oeuvre par le GACSR 50 dans un réseau informatique CRS comprenant environ 3 000 serveurs d'applications permet de réduire de manière drastique la quantité de données GAC transférées aux serveurs d'applications à 2 GB par heure, par rapport à 6 GB par heure sans aucune élimination de redondance. [0068] Pour réduire encore la taille des fichiers GAC de taille réduite dans la mémoire cache 11 du serveur d'applications 10, le GACSR 50 est par ailleurs configuré pour diviser le fichier de contrôle d'accès générique central purgé 32' en des fichiers spécifiques à l'application, de sorte à former un fichier de contrôle d'accès générique spécifique à l'application purgé 32" avant de stocker ledit fichier dans ladite mémoire cache 11. [0069] La mise en oeuvre du GACSR 50 réduit de manière drastique la taille du fichier SQLite GAC à dupliquer provenant d'une version maîtresse obtenue à partir du fichier GAC 32 (par ex. fichier GAC spécifique à l'application et purgé) et envoyé à la mémoire cache 11 du serveur d'applications 10. [0070] En envoyant uniquement les données spécifiques à l'application pertinentes aux serveurs d'applications respectifs, une mise à jour effectué de manière centrale sur la version originale ou la version maîtresse du fichier GAC peut être appliquée localement aux serveurs d'applications beaucoup plus rapidement que si l'intégralité du contenu du GAC original avait dû être envoyé à tous les serveurs d'applications, quelles que soient les applications hébergées par ces serveurs. [0071] La mise en oeuvre du GACSR 50 permet de réduire efficacement le trafic général du réseau et d'optimiser l'utilisation des ressources du réseau tel que la bande passante, le traitement et l'énergie. Par conséquent, les performances du réseau informatique CRS 1 sont améliorées de manière drastique. En particulier, les utilisateurs peuvent avoir accès aux applications demandées avec des latences inférieures et des transferts de données plus rapides aux serveurs d'applications pour faciliter la propagation des mises à jour sur les serveurs d'applications. La division du fichier GAC en des fichiers plus petits contenant les données mises à jour appartenant au même serveur d'applications permet d'envoyer des mises à jour dédiées à chaque serveur d'applications séparément. Cette division évite avantageusement d'avoir un point de défaillance unique en cas de corruption du fichier. [0072] Le GACSR 50 est adapté pour accéder au fichier GAC 32 sur demande. Cette 12 demande peut être émise automatiquement, par exemple périodiquement à des in- tervalles de temps prédéterminés pour conserver le fichier à jour sur une hase temporelle pertinente. [0073] Alternativement, le GACSR 50 est adapté pour intercepter et analyser les commandes de refus ou d'autorisation d'accès C qui sont transmises à partir du CUIC 40 au serveur d'applications 10 et mettre à jour le fichier de contrôle d'accès générique sur la hase de l'analyse. Dans ce cas, le GACSR 50 s'interface non seulement avec le module GAC 30 qui héberge le fichier GAC 32 ou différentes versions celui-ci (par ex., le fichier GAC purgé 32') mais également avec le LSS 20. [0074] De préférence, le GACSR 50 s'interface avec le LSS 20 qui héberge le module GAC 30 au moyen d'une interface unique pour minimiser le nombre d'interfaces que les administrateurs du système doivent gérer. [0075] La Figure 2 est un schéma fonctionnel d'un dispositif informatique 100 pour mettre en oeuvre un ou plusieurs modes de réalisation, en particulier des serveurs tels que le serveur de sécurité de session d'ouverture 20, le serveur d'applications 10. [0076] Le dispositif informatique 100 peut être un dispositif tel qu'un poste de travail. Le dispositif informatique 100 comprends un bus de communication connecté à : - une unité de traitement central 101, tel qu'un microprocesseur, appelé CPU ; - une mémoire à accès aléatoire 102, appelée RAM, pour le stockage du code exécutable pour mettre en oeuvre l'un quelconque des modules ou composants logiciels conformément à l'invention ainsi que les registres adaptés aux variables et paramètres d'enregistrement nécessaires pour mettre en oeuvre ces modules ou composants, la capacité de mémoire de ceux-ci peut être étendue par une RAM en option connectée à un port d'expansion par exemple ; - une mémoire morte 103, appelée ROM, pour le stockage des programmes informatiques pour mettre en oeuvre des modes de réalisation de l'invention, en particulier le GACSR 50, le GAC 30, le CUIC 40, le CLP 42 ; - une interface réseau 104 est typiquement connectée à un réseau de communication via lequel les données numériques devant être traitées sont transmises ou reçues. L'interface réseau 104 peut être une interface réseau unique, ou composée d'un ensemble d'interfaces réseau différentes (par exemple des interfaces câblées ou sans fil, ou différents types d'interfaces câblées ou sans fil). Les paquets de données sont écrits sur l'interface réseau pour transmission ou sont lus dans l'interface réseau pour réception sous le contrôle de l'application logicielle s'exécutant dans la CPU 101 ; - une interface utilisateur 105 peut être utilisée pour recevoir les entrées provenant d'un utilisateur ou pour afficher les informations à un utilisateur ; - un disque dur 106 appelé HD peut être fourni comme dispositif de stockage de masse ; 13 - un module PO 107 peut être utilisé pour recevoir/envoyer des données provenant de/à des dispositifs externes tels qu'une source ou un affichage vidéo. [0077] La Figure 3 permet de visualiser un algorithme de procédé selon certains modes de réalisation. Dans Sl, le terminal utilisateur 2 transmet et le serveur d'applications 10 reçoit la demande d'accès Rl. Dans S2, le serveur d'applications 10 transmet ou transmet S2 la demande d'accès R1 au CUIC 40. Dans S3, le CUIC 40 affiche le panneau sur le terminal utilisateur et invite l'utilisateur à saisir ses identifiants (par ex. l'ID utilisateur ou l'ID pour l'application demandée). Dans S4, le terminal utilisateur soumet l'ID de l'application ou de l'utilisateur au CUIC 40. Dans S5, le CUIC 40 transmet l'ID de l'application ou de l'utilisateur au LSS 20. Dans 56, le LSS 20 envoie l'ID de l'application ou de l'utilisateur au GAC 30. Dans S7, le GAC renvoie les droits d'accès pour l'utilisateur ou l'application au LSS 20. Dans S8, le LSS 20 envoie le refus ou l'autorisation d'accès au CUIC 40. Dans 59, le CUIC 40 envoie le refus ou l'autorisation d'accès au serveur d'applications 10. Dans S10, le serveur d'applications 10 envoie le refus ou l'autorisation d'accès au terminal de l'utilisateur 2. [0078] Le code exécutable peut être stocké soit dans une mémoire morte 103 sur le disque dur 106 soit sur un support numérique amovible, tel que par exemple un disque. Selon une variante, le code exécutable des programmes peut être reçu au moyen d'un réseau de communication, via l'interface réseau 104, afin d'être stocké dans l'un des supports de stockage du dispositif de communication 100, tel que le disque dur 106, avant d'être exécuté. [0079] L'unité de traitement centrale 101 est adaptée pour contrôler et diriger l'exécution des instructions ou des parties du code logiciel du programme ou des programmes selon des modes de réalisation de l'invention, dont les instructions sont stockées dans l'un des supports de stockage susmentionnés. Après mise sous tension, la CPU 101 est capable d'exécuter les instructions provenant d'une mémoire RAM principale 102 liée à une application logicielle après que ces instructions ont été chargées à partir de la ROM de programme 103 ou du disque dur (HD) 106, par exemple. Une telle application logicielle, lorsqu'elle est exécutée par la CPU 101, amène les fonctions SI-S10 décrites en référence à la Figure 1 et la Figure 3, respectivement, à être exécutées. [0080] Toute fonction de l'algorithme eprésenté à la Figure 3 peut être mis en oeuvre dans un logiciel par l'exécution d'un ensemble d'instructions ou un programme par une machine informatique programmable, telle qu'un PC (« Personal Computer ») (« Ordinateur personnel »), un DSP (« Digital Signal Processor ») (« Processeur de signal numérique) ou un microcontrôleur ; ou autrement mis en oeuvre dans le matériel par une machine ou un composant dédié, tel qu'un FPGA (« Field-Programmable Gate Array ») (« Réseau prédiffusé programmable par l'utilisateur ») ou un ASIC 14 (« Application-Spécifie Tntegrated Circuit ») (« Circuit Intégré spécifique à une application »). [0081] Bien que les présents mécanismes qui ont été décrits ci-dessus en référence à un mode de réalisation spécifique, ils ne sont pas limités à cc mode de réalisation spécifique, et les modifications apparaîtront à l'homme de métier qui se situe dans la portée. [0082] Le mot « comprenant» n'exclut pas d'autres éléments ou fonctions. [Revendication I] [Revendication 2]