FR2898748A1

FR2898748A1 - Procede et dispositif de gestion des instances d'une application informatique

Info

Publication number: FR2898748A1
Application number: FR0650925A
Authority: FR
Inventors: Nicolas Bailleul; Rouzic Jean Pierre Le
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2006-03-17
Filing date: 2006-03-17
Publication date: 2007-09-21
Also published as: WO2007113409A1

Abstract

Ce dispositif gère les instances d'une application informatique (AP) accédant à des fournisseurs de services (S1, S2, S3) regroupés dans des groupes (G1, G2), ces groupes étant prédéfinis pour regrouper les fournisseurs de services qui requièrent l'exécution d'au moins une opération de l'application. Il utilise une même instance de l'application pour accéder aux fournisseurs (S1, S2) d'un même groupe (G1) de sorte que l'opération précitée n'est exécutée qu'une seule fois pour tous ces fournisseurs (S1, S2). Utilisation pour l'authentification d'un utilisateur auprès de fournisseurs (S1, S2) de services ayant établi une relation de confiance avec un même fournisseur d'identité (I1).

Description

Arrière-plan de l'invention La présente invention se rapporte au domaine

général des réseaux de télécommunication, et plus particulièrement à l'accès, via de tels réseaux, à des fournisseurs de service distants. Dans ce document, on entend par "fournisseur de service", toute entité pouvant être accédée par un terminal via un réseau de télécommunication, et susceptible de fournir, à ce terminal, un service quelconque. Les serveurs web constituent ainsi des fournisseurs de service au sens de l'invention. D'une façon générale, il est connu qu'un utilisateur accède, à partir d'une application informatique, à plusieurs fournisseurs de service, et ce dans une période de temps relativement courte. C'est notamment le cas lorsqu'un utilisateur accède avec un navigateur Internet à une pluralité de serveurs web. Dans ce contexte particulier, il est connu que les serveurs web sollicitent le navigateur précité pour obtenir des données d'authentification d'un utilisateur. Or, les navigateurs Internet ne répercutent pas systématique-ment cette demande à l'utilisateur, ses données d'authentification étant susceptibles d'être mémorisées dans une mémoire cache du navigateur de façon non contrôlée par l'utilisateur.

Il en résulte que la perception, par l'utilisateur, de la façon dont sont gérées ces données d'authentification ne correspond pas à l'usage qui en est réellement fait : l'utilisateur peut par exemple être sollicité pour saisir un mot de passe alors que le niveau de sécurité perçu pour accéder à ces fournisseurs de services est faible, et inversement ne pas être sollicité pour la saisi- de ce mot de passe alors qu'Il accède à un

b et et esuine de !'invention La présente invention vise à pallier cet inconvénient, et plus 35 généralement à permettre le contrôle, par un utilisateur, de l'exécution particulière d'une opération particulière susceptible d'être répétée par une application en réponse à des sollicitations de différents fournisseurs de services distants, Plus précisément, l'invention concerne un procédé de gestion des instances d'une application informatique permettant d'accéder, via un réseau de télécommunication, à une pluralité de fournisseurs de services susceptibles d'appartenir à des groupes de fournisseurs de services prédéterminés, les groupes étant prédéfinis pour regrouper les fournisseurs de services requérant l'exécution d'au moins une opération de ladite application. Ce procédé comporte : - une étape de réception, en provenance de l'application, d'une requête pour accéder à l'un des fournisseurs de services, dit fournisseur cible ; - une étape pour déterminer si une première instance active de l'application est utilisée pour accéder à un premier des fournisseurs appartenant au même groupe que le fournisseur cible ; - une étape pour, le cas échéant, utiliser la première instance active pour accéder au fournisseur cible, sans ré-exécuter l'opération; et - une étape pour, dans le cas contraire, créer une deuxième instance de l'application pour accéder au fournisseur cible, et exécuter l'opération dans la deuxième instance.

D'une façon générale, l'invention permet donc de définir des groupes de fournisseurs de services, l'accès aux fournisseurs de services d'un même groupe s'effectuant dans une même instance de l'application, et une opération commune aux fournisseurs du même groupe n'étant exécutée qu'une seule fois dans une instance particulière.

Dans une première application, cette opération peut par exemple être une opération de calcul fortement coûteuse pour les ressources du terminal mettant en oeuvre ce procédé de gestion, de sorte que cette opération n'est exécutée qu'une seule fois, et son résultat gardé en mémoire pour être fourni, le cas échéant, à d'autres fournisseurs de services requérant la même opération mi =un 1(ii)[ [ ["lindi.Mii- SerVICeS reqUerant api moins une donnée sensible commune_ Dans ce mode, le procédé de gestion selon l'invention comporte ri - une étape d'obtention et de mémorisation de la donnée sensible en réponse à une requête d'un premier fournisseur de service accédé par une instance de l'application ; et - une étape d'envoi de la donnée sensible, en réponse à toute requête 5 d'un fournisseur de service accédé par cette instance. Ce mode de réalisation trouve une application particulièrement avantageuse lorsque l'obtention de la donnée sensible nécessite une étape de sollicitation de l'utilisateur. En effet, dans ce mode de réalisation de l'invention, l'utilisateur 10 sera systématiquement sollicité pour l'obtention des données sensibles dès qu'il souhaitera accéder à un fournisseur de service appartenant à un groupe pour lequel il n'existe pas d'instance active appartenant à un fournisseur de ce groupe. En revanche, il ne sera jamais sollicité pour une nouvelle 15 obtention de ces données sensibles au profit d'un autre fournisseur de service de ce groupe, tant que l'instance précitée restera active. L'invention peut être mise en oeuvre dans un environnement d'exécution multi-fenêtres. Dans ce mode de réalisation, l'instance active s'exécutera dans une fenêtre unique. 20 Cette réalisation permet avantageusement de clarifier encore la perception, par l'utilisateur, de la gestion de ces données sensibles, puisque la sollicitation pour obtenir de telles données est associée à l'ouverture d'une nouvelle fenêtre pour exécuter l'application. Dans un mode préféré de réalisation, un groupe au sens de 25 l'invention regroupe des fournisseurs de services ayant établi une relation de confiance avec un même fournisseur d'identité. L'invention permet ainsi de compléter avantageusement les fonctionnalités de protocole à authentification unique de type SSO (pour "Single Sign On" en anglais), qui permettent à un utilisateur de 30 -'luthentifrer -.iprès d'un f 3seur et d'accéder des sséurs vw Les systèmes de type SS ermetteiY a^nsi de l9arta Jne session d'authentification entre plusieurs fournisseurs de service web qui 35 ont établi une relation de confiance avec un fournisseur d'identité. On dira que ces fournisseurs de services appartiennent au même "cercle de confiance". Cependant, cette session d'authentification est établie entre l'utilisateur et le fournisseur d'identité par le biais d'un navigateur web.

Lorsque l'authentification de l'utilisateur est réalisée sur la base de données calculées par un objet tiers, par exemple une carte à puce, il ne peut pas y avoir de corrélation entre les déblocages de ces données par le navigateur, par exemple consécutivement à la saisie d'un code personnel, et leur mise à disposition ultérieure à destination du fournisseur d'identité, puisque le cache du navigateur ne peut les mémoriser. Ainsi, le code identificateur n'est demandé qu'une seule fois lors de la connexion. Et si l'on navigue d'un premier site à un deuxième site qui n'a pas de relation de confiance avec le premier, le code utilisateur ne sera pas redemandé.

L'utilisateur peut alors se demander pourquoi il est sollicité certaines fois et pas d'autres. Il se peut en particulier qu'il soit sollicité pour avoir accès à des informations non confidentielles alors qu'il ne l'est pas pour accéder à des informations confidentielles. Grâce à la présente invention, la sécurité perçue par l'utilisateur dans l'utilisation d'un service de type SSO est fortement améliorée, puisque l'utilisateur saisit une et une seule fois son code utilisateur pour débloquer l'accès à ces données d'authentification. Le cache de l'instance du navigateur et le système de type SSO garantissent une navigation sécurisée pour accéder à tous les sites d'un même groupe ou cercle de confiance. Bien entendu, si l'utilisateur souhaite naviguer dans un autre cercle de confiance, il est dirigé vers une instance de navigation dédiée qui sollicite alors la saisie de son code utilisateur, matérialisant ainsi la sécurisation des services d'un cercle de confiance à un autre. Selon une implémentation préférée, les différentes étapes du 30 procédé de gestion sont déterminées par des instructions de programmes rr urrilnateui si_ un suppor d irf-ornietions, ce piogrdmme étant susceptible d'être mis en oeuvre dans un ordinateur, ce programme 35 comportant des instructions adaptées à la mise en oeuvre du procédé de gestion tel que mentionné ci-dessus.

Ce programme 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 lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations 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 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 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. L'invention vise aussi un dispositif de gestion des instances d'une application informatique permettant d'accéder, via un réseau de télécommunication, à une pluralité de fournisseurs de services susceptibles d'appartenir à des groupes de fournisseurs de services, ces groupes étant prédéfinis pour regrouper les fournisseurs de services requérant l'exécution d'au moins une opération de ladite application.

C dispositif comporte -des moyens cour déterminer si une première Instance active l'application est utilisée pour accéder à un premier ces fournisseurs 35 appartenant au même groupe que le fournisseur cible ; des moyens pour, le cas échéant, utiliser la première instance active pour accéder au fournisseur cible avec l'application, sans ré exécuter l'opération ; et - des moyens pour, dans le cas contraire, créer une deuxième instance de l'application pour accéder au fournisseur cible, et exécuter l'opération dans la deuxième instance. L'invention vise également un ordinateur comportant un dispositif de gestion tel que mentionné ci-dessus, et des moyens de mémorisation d'un fichier comportant au moins une adresse d'un fournisseur de service sélectionné par un utilisateur de cet ordinateur, ce fichier comportant, le cas échéant, au moins un identifiant du groupe du fournisseur de service. Ce fichier peut par exemple être un carnet d'adresses Web également connu sous le nom de "Fichier de Favoris" dans lequel un navigateur ou tout autre logiciel informatique enregistre les adresses des sites préférés d'un utilisateur.

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, de façon schématique, un ordinateur conforme à l'invention dans un mode préféré de réalisation ; et - la figure 2 représente, sous forme d'organigramme, les principales étapes d'un procédé de gestion conforme à l'invention. relié, par des moyens de communication et i2i Nous supposerons dans cet exemple que les fournisseurs de 35 service Si et S2 sont régis par le fournisseur d'identité Il (ils appartiennent au même cercle de confiance), que le fournisseur de service Description détaillée d'un mode de réalisation La figure 1 représente un ordinateur 1 conforme à l'invention. Cet ordinateur 1 S3 est régi par le fournisseur d'identité 12 et que le fournisseur de service S4 n'est régi par aucun fournisseur d'identité. L'ordinateur 1 selon l'invention comporte un processeur 10, une mémoire morte 12, une mémoire vive 14 et une mémoire volatile réinscriptible de type flash 18. Dans le mode préféré de réalisation décrit ici, l'ordinateur 1 selon l'invention comporte des moyens 16 de lecture d'une carte à puce, cette carte à puce contenant des données secrètes utilisées pour authentifier un utilisateur de l'ordinateur 1.

Dans le mode préféré de réalisation décrit ici, la mémoire non volatile réinscriptible 18 contient un fichier informatique FAV dans lequel les adresses de chacun des fournisseurs de services S1, S2, S3, S4 ont été enregistrées. Ce fichier FAV comporte également, le cas échéant, un identifiant de chaque groupe auquel appartiennent ces fournisseurs de services. De façon avantageuse, on a défini trois groupes G1, G2, G3 qui reflètent les cercles de confiance précités. Plus précisément, le groupe G1 regroupe les fournisseurs de services S1 et S2 régis par le même fournisseur d'identité Il, le groupe G2 contient un seul élément, à savoir le fournisseur de service S3 régi par le fournisseur d'identité 12 et le groupe G3 un seul élément, à savoir le fournisseur de service S4 qui n'est régi par aucun fournisseur d'identité. La mémoire morte 12 comporte deux programmes informatiques, à savoir un programme informatique AP qui, lorsqu'il est exécuté par le processeur 10, exécute les instructions d'une application informatique adaptée à accéder, via le réseau 2, aux différents fournisseurs de service S1, S2, S3 et S4. Dans le mode de réalisation préféré décrit ici, l'ordinateur 1 selon l'invention comporte une mémoire cache 19 utilisée par l'application AP pour mémoriser tes données d'authentification de rutilisateLit de 1 I()i --= 1

mémoire morte 12 comporte o ..n deuxième programme informatique Cl adapté, lorsqu'il est mis en oeuvre, à exécuter les principales étapes du procédé de gestion selon l'invention, dont l'organigramme va maintenant être décrit en référence à la figure 2.

On supposera tout d'abord qu'un utilisateur de ce procédé lance l'application AP pour accéder au site web SI, Le lancement de cette exécution génère l'envoi d'une requête reçue, par le procédé de gestion selon l'invention, au cours d'une étape E10. Cette étape de réception El() est suivie par une étape E20 au cours de laquelle le procédé de gestion selon l'invention détermine le groupe (en l'occurrence Gl) auquel appartient le fournisseur de service Si. Dans l'exemple décrit ici, cette obtention se fait par lecture du fichier 10 FAV dans la mémoire non volatile 18. Cette étape E20 d'obtention du groupe est suivie par un test E30 au cours duquel le procédé de gestion selon l'invention détermine si une instance de l'application AP est active pour accéder à un fournisseur de service du groupe G1. 15 Comme ce n'est pas le cas, le résultat du test E30 est négatif. Ce test est alors suivi par une étape E40 au cours de laquelle le procédé de gestion selon l'invention crée une instance API de l'application AP. L'utilisateur peut ainsi accéder au site Si au cours d'une étape 20 E42. On supposera que le fournisseur de service SI sollicite le fournisseur d'identité Il pour authentifier l'utilisateur. Ainsi le programme de gestion selon l'invention reçoit, en provenance du fournisseur d'identité Il, une requête d'authentification au cours d'une étape E44. Dans le mode de réalisation décrit ici, l'authentification requiert 25 une étape de calcul de données d'authentification à partir de données secrètes mémorisées dans la carte à puce et d'un code utilisateur devant être explicitement fourni par l'utilisateur. Aussi, au cours d'une étape E46, le procédé de gestion selon l'invention sollicite l'utilisateur pour !a fourniture de ce code. 30 Au cours de cette même étape, (e procédé de gest'~.;r selon Hl' (- l'PC ei,E 1

Cette memonsetioi, es par une étape au _ee e laquelle le procédé de gestion selon l'invention transmet ces données 35 d'authentification au fournisseur d'identité De façon transparente pour l'utilisateur, le fournisseur d'identité I1 transmet au fournisseur de service S1 une information selon laquelle l'utilisateur a été dûment authentifié, et l'utilisateur peut accéder, au cours d'une étape E50, à un service personnalisé du fournisseur S1.

On va maintenant supposer que l'utilisateur sollicite une nouvelle fois l'application AP pour accéder au fournisseur de service S2. Comme décrit précédemment, le procédé de gestion selon l'invention reçoit une requête correspondante au cours d'une étape E10, et obtient, au cours de l'étape E20, le groupe G1 auquel appartient le 10 fournisseur de service S2. Au cours du test E30 précédemment décrit, le procédé de gestion selon l'invention détermine cette fois qu'une instance API est active pour accéder au fournisseur de service S1 du même groupe G1. Le résultat de ce test est donc positif.

15 En conséquence, le procédé de gestion selon l'invention réutilise, au cours d'une étape E60, l'instance API pour accéder au fournisseur de service S2. L'utilisateur peut ainsi accéder au fournisseur de service S2 au cours d'une étape E62 et reçoit, de la même façon que précédemment 20 décrit, une requête d'authentification en provenance du fournisseur d'identité Il au cours d'une étape E64. Mais, dans ce cas, le procédé de gestion selon l'invention ne resollicite pas l'utilisateur pour fournir son code utilisateur, mais obtient directement les données d'authentification, au cours d'une étape E66, à 25 partir de la mémoire cache 19. Ces données d'authentification sont envoyées au fournisseur d'identité Il au cours d'une étape E68 qui transmet, comme précédemment décrit, une information au fournisseur de service S2, représentative du fait que l'utilisateur a été dûment authentifié.

30 L'utilisateur peut ainsi accéder, de façon personnalisée, au .,--=,eui untt. -tliht 1, 01- au,' fournisseurs Sel et S/t a partir (te a 'cerne fenetre de ordinateur 1.

35 Lorsqu'il ferme explicitement cette fenêtre, l'instance API est détruite, de sorte que s'il souhaite accéder une nouvelle fois à un fournisseur de service du fournisseur géré par le fournisseur d'identité le procédé de gestion selon l'invention lui redemandera de fournir son code utilisateur. Si l'utilisateur sollicite l'application AP pour accéder au fournisseur de service S3, S4 respectivement, une nouvelle instance AP2 sera créée à l'étape E40 précédemment décrite, du fait qu'aucune instance de navigateur n'a été lancée pour un fournisseur de service du groupe G2, respectivement G3. Dans ce cas, et comme précédemment décrit, l'utilisateur sera sollicité au cours de l'étape E46 pour fournir son code utilisateur de façon à débloquer ses données d'authentification.

Claims

REVENDICATIONS

1. Procédé de gestion des instances d'une application informatique (AP) permettant d'accéder, via un réseau de télécommunication (2), à une pluralité de fournisseurs de services (Si, S2, S3, S4) susceptibles d'appartenir à des groupes (Gl, G2) de fournisseurs de services, lesdits groupes étant prédéfinis pour regrouper lesdits fournisseurs de services requérant l'exécution d'au moins une opération de ladite application (AP), ledit procédé comportant : - une étape (EIO) de réception, en provenance de ladite application (AP), d'une requête pour accéder à l'un (S2) desdits fournisseurs de services (Si, S2, S3, S4), dit fournisseur cible ; -une étape (E30) pour déterminer si une première instance active de ladite application (AP) est utilisée pour accéder à un premier (Si) desdits fournisseurs (Si, S2, S3) appartenant au même groupe (Gl) que ledit fournisseur cible (S2) ; - une étape (E60) pour, le cas échéant, utiliser ladite première instance active pour accéder audit fournisseur cible (S2), sans ré-exécuter ladite opération; et - une étape (E40) pour, dans le cas contraire, créer une deuxième instance de ladite application (AP) pour accéder audit fournisseur cible (S2), et exécuter ladite opération dans ladite deuxième instance.

2. Procédé de gestion selon la revendication 1, dans lequel on définit un groupe (Gl) de fournisseurs de services (Si, S2) requérant au moins une donnée sensible commune, caractérisé en ce qu'il comporte : - une étape (E46) d'obtention et de mémorisation de ladite donnée sensible en réponse à une requête d'un premier fournisseur de service (Si) accédé par une dite instance de l'application ; et - une étape (E48, E68) d'envoi de ladite '9dr e nsible réponse à ui ( il i,ii( 1 i ocede (le gestlon ,elo[ !a e, endicabo[i 2, edideierisé en ce qu'il comporte une étape (E46) de sollicitation d'un utilisateur pour obtenir ladite donnée sensible.4. Procédé selon la revendication 2 ou 3, caractérisé en ce que ladite donnée sensible est une donnée d'authentification et en ce que ledit groupe (Gi) regroupe des fournisseurs de services (Si, S2) ayant établi une relation de confiance avec un même fournisseur d'identité (Il). 5. Procédé de gestion selon l'une quelconque des revendications 2 à 4, ce procédé étant mis en œuvre dans un environnement d'exécution multi fenêtres caractérisé en ce qu'une instance active s'exécute dans une fenêtre unique. 10 6. Dispositif de gestion des instances d'une application informatique (AP) permettant d'accéder, via un réseau de télécommunication (2), à une pluralité de fournisseurs de services (Si, S2, S3, S4) susceptibles d'appartenir à des groupes (Gl, G2) de fournisseurs 15 de services, lesdits groupes étant prédéfinis pour regrouper lesdits fournisseurs de services requérant l'exécution d'au moins une opération de ladite application (AP), ledit dispositif comportant : - des moyens de réception, en provenance de ladite application (AP), d'une requête pour accéder à l'un (S2) desdits fournisseurs de services 20 (Sl, S2, S3, S4), dit fournisseur cible ; - des moyens pour déterminer si une première instance active de ladite application est utilisée pour accéder à un premier (Si) desdits fournisseurs (SI, S2, S3, S4) appartenant au même groupe (G1) que ledit fournisseur cible (S2) ; 25 - des moyens pour, le cas échéant, utiliser ladite première instance active pour accéder audit fournisseur cible (S2), sans ré-exécuter ladite opération; et - des moyens pour, dans le cas contraire, créer une deuxième instance de ladite application (AP) pour accéder audit fournisseur cible (S2), et 30 exécuter ladite opération dans ladite deu ème instance. 11 0,7,;j")()yï-Ir ,ewendicatlori es moyens ( de 111ernOtlSatlON Fichier F-Av) comportant au moins une adresse d'un fournisseur de service (Si, S2, S3, 35 S4) sélectionné par un utilisateur dudit ordinateur (1), caractérisé en ce aque ledit fichier (FAV) comporte, le cas échéant, au moins un identifiant du groupe (Gl, G2) dudit fournisseur de service (Si). 8. Programme d'ordinateur (CI) comportant des instructions pour l'exécution des étapes du procédé de gestion selon l'une quelconque des revendications 1 à 5 lorsque ledit programme est exécuté par un ordinateur (1). 9. Support d'enregistrement (12) lisible par un ordinateur (1) 0 sur lequel est enregistré un programme d'ordinateur (CI) comprenant des instructions pour l'exécution des étapes du procédé de gestion selon l'une quelconque des revendications 1 à 5.