L'invention concerne un procédé d'attribution de données d'authentifications temporaires pour l'accès à des services IMS. Elle s'applique notamment au domaine des réseaux de télécommunication IMS.

L'IMS, acronyme venant de l'expression anglo-saxonne « IP Multimedia Subsystem » est une architecture de réseau normalisée permettant aux opérateurs de fournir des services multimédia sur réseaux fixes et mobiles. L'IMS et normalisée au sein du trois GPP, acronyme venant de l'expression anglo-saxonne «3rd Génération Partnership Project ».

La création d'un compte IMS est effectuée habituellement selon deux alternatives. Une première alternative est de créer le compte IMS de manière statique lorsque l'abonné auprès d'un opérateur de télécommunication souscrit à un service. Une seconde alternative est de créer le compte IMS de manière dynamique, c'est-à-dire au moment où l'abonné cherche à utiliser pour la première fois un service. Le compte IMS est alors mis en œuvre à l'aide de plateformes appartenant au réseau IMS.

Une des actions effectuées par le réseau IMS au moment de la création du compte est de générer des données d'identification, désignées habituellement par le mot anglais « credentials ». Ces données d'authentification permettent à un utilisateur d'utiliser son compte IMS ainsi que les services auxquels il a souscrit.

Des exemples de services pouvant être utilisés dans le cadre de l'IMS sont la voix sur IP, désignée habituellement par l'acronyme VoIP, l'accès à des chaînes de télévision numérique, des moyens d'échanges de données pour jeux vidéo en ligne.

Les données d'authentification sont particulièrement importantes car elles permettent d'utiliser le compte IMS et les services IMS souscrits par un abonné. Ainsi, si un utilisateur est abonné auprès d'un opérateur de télécommunication lui fournissant un équipement de type boîtier modem pour accéder à Internet, celui-ci pourra se voir attribuer un compte IMS « post- paid », c'est-à-dire un compte pour lequel l'utilisateur sera facturé sur la base de son utilisation des services auxquels il a souscrit. Cet utilisateur aura alors besoin des données d'authentification qui lui ont été allouées et qui sont associées à son compte IMS et/ou à ses services afin de pouvoir y accéder.

L'abonné pourra par exemple accéder à des chaînes de télévision payantes en utilisant son boîtier modem comme point d'accès ou encore à un service de téléphonie en voix sur I P. Les données d'authentification sont habituellement mémorisées et cryptées dans le boîtier modem.

De plus en plus d'utilisateurs souhaitent utiliser les services IMS auxquels ils ont souscrit quelque soit leur position géographique et quelque soit le terminal qu'ils utilisent.

En outre, un utilisateur ayant souscrit à un service IMS peut vouloir partager ses droits d'accès à ce service avec d'autres personnes, par exemple des membres de sa famille.

Les utilisateurs peuvent vouloir aussi utiliser les services IMS souscrit par l'intermédiaire d'une application tierce qui utiliserait les données d'authentification attribuées à l'abonné, par exemple pour que l'utilisateur soit facturé pour son utilisation du service via l'application tierce sur la même facture que ses services IMS.

Par application tierce, on entendra ici une application qui se différencie de l'application initiale permettant à l'abonné d'accéder au service IMS parce qu'elle est mise en œuvre par un fournisseur de service tiers différent de l'opérateur de télécommunications auprès duquel l'abonné a souscrit à un service IMS, ou parce que l'utilisateur utilise un terminal distant du point d'accès attribué par l'opérateur de télécommunications, ou parce que l'utilisateur n'est pas l'abonné qui a initialement souscrit au service IMS.

Pour avoir le droit d'accéder à distance du point d'accès attribué à l'abonné-souscripteur, un utilisateur qui n'est pas forcément l'abonné devra s'identifier et s'authentifier. Cela est en général effectué de manière classique. L'utilisateur distant doit disposer des données d'authentification IMS requises pour l'accès à ces services. Dans cette description, le terme « distant » signifie éloigné du ou des points d'accès attribués à un abonné. Ce point d'accès peut être un boîtier modem comme mentionné précédemment, mais peut être également d'un autre type, par exemple une cellule radio-mobile auprès de laquelle l'abonné est attaché.

Du fait qu'un utilisateur distant utilise les données d'authentification IMS de n'importe où et avec potentiellement n'importe quel terminal, le problème de la sécurité et de la préservation des données d'authentification se pose. En effet, plus l'accès à un service sécurisé est ouvert, plus la sécurité des données personnelles de l'abonné-souscripteur est menacée. Un but de l'invention est notamment de pallier les inconvénients précités.

A cet effet l'invention a pour objet un procédé d'attribution de données temporaires d'authentifications par une entité d'un réseau IMS pour permettre un accès par une application tierce à un service IMS souscrit par un abonné, ledit procédé comprenant les étapes suivantes :

- la réception d'une requête d'accès en provenance de l'application tierce ;

- la vérification que l'application tierce est autorisée par l'abonné à accéder au service IMS ;

- la génération de données temporaires d'authentification différentes des données d'authentification attribuées initialement à l'abonné ;

- la transmission des données temporaires d'authentification à l'application tierce et à une base de données du réseau IMS. Ce procédé présente l'avantage déterminant de permettre un accès distant sécurisé aux services IMS souscrits par un abonné sans qu'il soit nécessaire de modifier l'architecture du réseau IMS pour le mettre en œuvre et sans surcoût. Cette délégation de l'authentification peut être mise en œuvre sur n'importe quel type de terminal, pour n'importe quel utilisateur préalablement autorisé par l'abonné ou pour n'importe quelle application tierce, et pour tous types de services IMS fournis par un opérateur de télécommunications.

Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux caractéristiques du procédé défini ci-dessus. Dans un mode de réalisation préféré, l'application tierce est embarquée dans un terminal distant.

Dans un autre mode de réalisation préféré, l'application tierce est utilisée par un utilisateur différent de l'abonné. Selon un autre aspect de l'invention, les données temporaires d'authentification attribuées à un utilisateur sont effacées de la base de données lorsque l'abonné résilie l'autorisation d'accès au service IMS pour l'application tierce. Avantageusement, ce mécanisme permet de bloquer de manière simplifiée l'accès à des services IMS auquel un utilisateur donné ou une application tierce pouvait accéder de par les autorisations qui lui avaient été accordées.

Selon un autre aspect de l'invention, les données temporaires d'authentification correspondent à au moins un élément appartenant au groupe comprenant : une identité IMPI, une identité IMPU, un mot de passe temporaire, une adresse de joignabilité du registraire. Avantageusement, du fait que les identités IMPI et IMPU sont des données normalisées dans le cadre de l'IMS, leur gestion peut être mise en œuvre simplement en utilisant des mécanismes normalisés existants.

Dans un mode de réalisation, les autorisations d'accès aux services IMS souscrits par l'abonné-souscripteur sont mémorisées par un serveur du réseau d'un opérateur de télécommunication mettant en œuvre un espace client, dans la base de données HSS ou dans la plateforme hébergeant le service IMS concerné. Ce mode de réalisation permet à l'utilisateur de gérer simplement et de manière conviviale les droits d'accès aux services IMS auxquels il a souscrit.

Les données temporaires d'authentification peuvent être générées par la plateforme hébergeant le service IMS.

Dans un mode de réalisation, la plateforme hébergeant le service

IMS envoie un message à l'application tierce de manière à lui transmettre les données temporaires d'authentification, ce message contenant également une adresse de redirection URI vers laquelle l'application tierce devra adresser ses requêtes d'accès au service IMS ultérieurement. Avantageusement, l'application tierce est apte à s'authentifier directement auprès de la bonne entité du réseau IMS afin d'accéder au service IMS demandé.

Selon un aspect de l'invention, l'adresse de redirection est l'adresse d'un registraire du réseau IMS.

Dans un mode de réalisation, une confirmation est demandée à l'abonné avant de générer des données temporaires d'authentification pour un utilisateur autorisé. Avantageusement, l'abonné ayant souscrit aux services IMS peut ainsi valider la demande d'accès. Ce mécanisme améliore ainsi la sécurité des accès aux services IMS.

L'invention a aussi pour objet un procédé d'authentification d'un utilisateur voulant accéder à un service IMS d'un réseau IMS souscrit par un abonné, par l'intermédiaire d'une application tierce. Ce procédé d'authentification comporte les étapes d'envoi par l'application tierce à une entité du réseau IMS d'une requête d'accès au service IMS, et de réception par l'application tierce de données temporaires d'authentification différentes des données d'authentification attribuées initialement à l'abonné.

Selon un mode particulier de réalisation de l'invention, le procédé d'authentification comporte également les étapes suivantes :

- l'envoi d'une requête d'authentification vers une adresse de redirection fournie lors de l'attribution des données temporaires d'authentification, cette requête contenant lesdites données temporaires d'authentification ;

- l'accès au service IMS par l'utilisateur, suite à l'authentification de l'utilisateur par comparaison des données temporaires d'authentification transmises dans la requête avec les données temporaires d'authentification mémorisées dans une base de données.

Les données temporaires d'authentification peuvent par exemple avoir été attribuées à l'application tierce par le procédé d'attribution de données temporaires décrit précédemment.

L'invention a aussi pour objet un dispositif comprenant des moyens adaptés pour mettre en œuvre le procédé d'attribution de données d'authentifications temporaires décrit précédemment.

L'invention a aussi pour objet un serveur comprenant ledit dispositif.

L'invention a aussi pour objet un programme d'ordinateur comportant des instructions pour l'exécution du procédé d'attribution de données temporaires d'authentification tel que décrit précédemment, lorsque le programme est exécuté par un processeur.

L'invention a aussi pour objet un support d'enregistrement lisible par un processeur sur lequel est enregistré un programme comportant des instructions pour l'exécution du procédé d'attribution de données temporaires d'authentification décrit précédemment, lorsque le programme est exécuté par un processeur.

L'invention a aussi pour objet un terminal de télécommunication comportant des moyens pour envoyer une requête d'accès à un service IMS et des moyens pour recevoir des données temporaires d'authentification dans le cadre du procédé d'authentification décrit précédemment.

Selon un mode particulier de réalisation de l'invention, le terminal comporte également des moyens pour mémoriser des données temporaires d'authentification et des moyens pour les utiliser dans le cadre du procédé d'authentification décrit précédemment.

L'invention a aussi pour objet un programme d'ordinateur comportant des instructions pour l'exécution du procédé d'authentification d'un utilisateur tel que décrit précédemment selon l'un quelconque des modes de réalisation décrits, lorsque le programme est exécuté par un processeur.

L'invention a aussi pour objet un support d'enregistrement lisible par un processeur sur lequel est enregistré un programme comportant des instructions pour l'exécution du procédé d'authentification d'un utilisateur tel que décrit précédemment selon l'un quelconque des modes de réalisation décrits, lorsque le programme est exécuté par un processeur.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit donnée à titre illustratif et non limitatif, faite en regard des dessins annexés parmi lesquels : la figure 1 illustre le mécanisme oAuth et donne un exemple de messages échangés entre un navigateur internet, une application d'intermédiation et un service tiers ; la figure 2 présente un diagramme simplifié de la procédure d'allocation de données temporaires d'authentification selon l'invention ;

la figure 3 présente un diagramme simplifié de la procédure d'authentification lorsqu'une application tierce utilise des données temporaires d'authentifications ;

la figure 4 présente un mode de réalisation préféré du procédé selon l'invention à l'aide d'un schéma d'échange de messages entre plusieurs entités d'une architecture IMS ; la figure 5 présente un dispositif informatique pouvant mettre en œuvre le procédé d'attribution de données temporaires d'authentification. La figure 1 illustre de manière simplifiée un échange de message typique du mécanisme oAuth.

Dans le monde de l'Internet, il existe un mécanisme normalisé appelé oAuth permettant de déléguer à une application dite d'intermédiation des droits d'accès aux services fournis par une application tierce.

La figure 1 illustre le mécanisme oAuth et donne un exemple de messages échangés entre un navigateur internet 100, une application d'intermédiation 101 et un service tiers 102. L'application d'intermédiation 101 est par exemple un blog hébergé sur un serveur et mettant en œuvre des interactions avec le service tiers 102. Le service tiers 102 correspond par exemple à un service proposé par un réseau social à ses souscripteurs. Le blog joue le rôle d'application d'intermédiation et peut diffuser par exemple des informations concernant les abonnés au réseau social si ces derniers le souhaitent et l'ont autorisé.

Pour cela, il est nécessaire que l'application d'intermédiation 101 soit autorisée à avoir accès au service tiers 102.

Afin d'éviter que les informations d'authentification associées aux comptes des souscripteurs au service tiers 102 ne soient directement transmises à l'application d'intermédiation 101 , le mécanisme oAuth génère un mot de passe temporaire spécifique à l'application 101 , à l'utilisateur 100 et au type d'accès demandé. C'est ce mot de passe temporaire qui sera utilisé par l'application d'intermédiation 101 pour accéder au service tiers 102.

Sur la figure 1 apparaissent l'utilisateur 100, l'application d'intermédiation 101 et le service tiers 102, ces trois entités s'échangeant des messages dans le cadre du mécanisme oAuth. Dans un premier temps, l'utilisateur 100 accède au portail Internet de l'application d'intermédiation 101 à l'aide de son terminal et lui envoie un message 103 lui indiquant qu'il souhaite lui donner accès à des données fournies par le service tiers 102, un préalable étant que l'utilisateur soit bien authentifié auprès de la plateforme hébergeant le service tiers 102.

Si l'application d'intermédiation ne possède pas à ce stade de données lui autorisant l'accès au service tiers 102, elle redirige l'utilisateur vers le site d'authentification oAuth du service tiers permettant la génération de données temporaires d'authentification. Pour cela, un message de redirection 104 est envoyé par l'application intermédiaire 101 vers l'utilisateur 100. Ce message de redirection comprend notamment l'adresse du site d'authentification oAuth hébergé sur un des serveurs mettant en œuvre le service tiers 102. L'utilisateur 100 envoie alors une requête 105 vers le site d'authentification oAuth du service tiers 102. Ce message comprend une adresse de redirection vers l'application 101 qui sera utilisée pour les requêtes ultérieures d'accès au service tiers. Ce message 105 comprend également un identifiant du service auquel l'application d'intermédiation souhaite accéder ainsi qu'un identifiant de l'utilisateur et un ensemble de données permettant de définir le type d'accès voulu au service tiers 102.

Le site oAuth du service tiers 102 répond alors en envoyant un message 106 demandant à l'utilisateur 100 de s'identifier grâce à ses données d'authentification. Pour cela l'utilisateur 100 transmet un message 107 au site oAuth du service tiers 102 dans lequel sont contenues lesdites données d'authentifications. En réponse à ce message 107, le site oAuth du service tiers 102 répond par un message 108 à destination de l'utilisateur 100 après que celui-ci ait accepté tout ou partie des type d'accès définis dans le message 105. Ce message 108 contient notamment un mot de passe temporaire, appelé également jeton, ainsi qu'une adresse de redirection vers l'application 101 . Suite à la réception de ce mot de passe temporaire, l'utilisateur 100 envoie un message 109 vers l'application d'intermédiation 101 afin de le lui transmettre.

L'application d'intermédiation 101 peut donc s'identifier et s'authentifier auprès du service tiers 102. Pour cela, elle envoie un message 1 10 comprenant ce mot de passe temporaire au service tiers 102. L'application d'intermédiation est alors authentifiée et autorisée à accéder au service tiers. Un message de confirmation 1 1 1 est alors transmis à l'application d'intermédiation 101 puis un autre message de confirmation 1 12 est transmis à l'utilisateur 100.

L'application d'intermédiation peut alors accéder au service tiers souscrit par l'utilisateur sans que les données d'authentification au service tiers de l'utilisateur ne lui aient été transmises. Pour ce qui est des mécanismes d'authentification IMS existants, le compte des services IMS est habituellement associé à un unique ensemble de données d'authentification, par exemple un identifiant utilisateur associé à un mot de passe.

Ainsi, si un utilisateur est abonné auprès d'un opérateur de télécommunication fournissant un accès à Internet via un boîtier modem connecté à son réseau, il pourra utiliser ses identifiants et mots de passe IMS pour accéder aux services auxquels il a souscrit.

Dans de nombreux cas de figure, lorsque que l'abonné souhaite accéder à un nouveau service IMS auquel il n'a pas encore souscrit, il ne possède pas d'identifiant et de mot de passe IMS pour cela. Afin d'obtenir un identifiant et un mot de passe, l'utilisateur devra s'identifier auprès de son opérateur. Pour cela, une interface utilisateur mise en œuvre par l'opérateur peut être utilisée. Une fois le nouveau service souscrit, son identifiant et son mot de passe IMS pourront lui être transmis en utilisant par exemple un lien crypté pour plus de sécurité. A l'aide de ces données d'authentification IMS, l'utilisateur abonné peut ensuite accéder aux services IMS auxquels il a souscrit.

Cependant, si l'abonné-souscripteur souhaite accéder à ces services à distance de son point d'accès depuis un terminal nomade par exemple, il doit en général utiliser un mot de passe et un identifiant IMS. Si l'abonné-souscripteur veut permettre à l'un de ses proches d'accéder à ce même service, il devra communiquer son mot de passe et son identifiant IMS. De plus, si après avoir utilisé un terminal nomade qui n'est pas le sien, l'identifiant et le mot de passe IMS y sont mémorisés, n'importe quel utilisateur de ce terminal pourra accéder à son service IMS. Comme mentionné précédemment, il apparaît clairement que ce type de mécanisme manque de sécurité.

Le procédé selon l'invention permet notamment à un utilisateur autorisé par celui qui a souscrit aux services IMS d'y accéder à distance sans que les données d'authentification ne lui soient communiquées. Cet utilisateur est de préférence également abonné auprès du même opérateur de télécommunication.

La figure 2 présente un diagramme simplifié de la procédure d'allocation de données temporaires d'authentification temporaire selon l'invention.

Dans la suite de la description, l'expression « abonné- souscripteur » désigne un abonné qui a souscrit à un service IMS auprès de son opérateur de télécommunication.

Dans un premier temps, un utilisateur, qui peut être l'abonné- souscripteur ou un utilisateur différent de l'abonné-souscripteur, envoie une requête d'accès aux services IMS à l'aide d'une application tierce 200. Si cette requête correspond à une première demande d'accès audit service IMS, des données temporaires d'authentification vont être générées.

Avant cette génération, une étape de vérification 201 a pour objectif de consulter une base de données de l'opérateur de télécommunications afin de s'assurer que l'application tierce est autorisée à accéder audit service. Si c'est le cas, des données temporaires d'authentification sont générées 202.

Selon le mode particulier de réalisation de l'invention, l'étape 201 vérifie que l'application tierce est autorisée à accéder audit service en fonction de données de l'utilisateur utilisant l'application tierce et/ou en fonction de données du terminal utilisé par l'utilisateur pour accéder au service.

Une étape de transmission 203 des données temporaires d'authentification générées vers une a base de données de l'opérateur de télécommunications, par exemple une base de données HSS est ensuite appliquée. HSS est un acronyme venant de l'expression anglo-saxonne « Home Subscriber Server ». Une base de données HSS mémorise notamment les informations relatives aux comptes IMS des utilisateurs du réseau, comme par exemple des données d'authentification.

Lors de l'étape 203, les données temporaires d'authentification sont également transmises à l'application tierce.

Les données temporaires d'authentification sont ensuite mémorisées 204 à la fois par la base de donnéese HSS.

Selon un mode particulier de réalisation de l'invention, les données temporaires d'authentification sont transmises à la plate-forme hébergeant le service IMS et mémorisées par la plate-forme.

Selon un autre mode particulier de réalisation de l'invention, la plate-forme hébergeant le service IMS met en œuvre l'étape 202 de génération des données temporaires d'authentification.

L'application tierce peut alors accéder aux services souscrits par l'abonné et pour lesquels des droits d'accès leur ont été accordés.

La figure 3 présente un diagramme simplifié de la procédure d'authentification lorsqu'une application tierce utilise des données temporaires d'authentification. Par exemple ces données d'authentification peuvent avoir été attribuées selon le procédé d'authentification décrit en relation avec la figure 2 ou un autre procédé. Par exemple, suite à l'envoi par l'application tierce à une entité d'un réseau IMS d'une requête d'accès, l'application tierce a reçu des données temporaires d'authentification.

Pour cela l'application tierce 300 envoie une requête d'authentification à destination du registraire du réseau IMS. Un registraire, désigné habituellement par le mot anglais « registrar », est une entité du réseau IMS ayant notamment pour fonction de gérer l'authentification dans le monde IMS et les requêtes des utilisateurs visant à signaler leur position courante.

La requête d'authentification contient également l'adresse du registraire ainsi que les données temporaires d'authentification.

Une étape d'authentification 301 est ensuite mise en œuvre. Cette étape correspond à un échange de données entre le registraire et le HSS du réseau IMS dans le but de comparer les données temporaires d'authentification contenues dans la requête à l'étape 300 ainsi que les données temporaires d'authentification mémorisée dans le HSS. Lorsque ces données temporaires d'authentification sont identiques, une étape d'échange de données numériques 302 permet d'accéder aux services IMS.

Le procédé d'authentification décrit en référence à la figure 3 peut par exemple être mis en œuvre par un terminal de communication comportant des moyens de communication tels que par exemple une interface réseau pour envoyer à une entité du réseau IMS une requête d'accès au service IMS, et recevoir des données temporaires d'authentification différentes des données d'authentification attribuées initialement à l'abonné. Le terminal comporte également des moyens pour mémoriser les données temporaires d'authentification tels que par exemple une mémoire RAM ou ROM et une unité de traitement tel que par exemple un processeur permettant de mettre en œuvre les étapes du procédé d'authentification. Selon un mode particulier de réalisation de l'invention, les moyens de communication permettent également d'envoyer la requête d'authentification à destination du registraire du réseau IMS.

La figure 4 présente un mode de réalisation particulier du procédé selon l'invention à l'aide d'un schéma d'échange de messages entre plusieurs entités d'une architecture IMS.

Cette figure présente quatre entités communiquant les unes avec les autres.

Une première entité 400 correspond à un terminal distant utilisé par un utilisateur voulant accéder à un service IMS.

Dans ce mode de réalisation, l'application tierce est embarquée dans le terminal distant. Ce terminal distant peut être un téléphone mobile intelligent désigné habituellement par l'expression anglaise « smart phone », une tablette tactile, un boîtier modem ou tout autre type de terminal connecté adapté pour utiliser le service IMS. Ce terminal distant 400 joue donc le rôle de client IMS.

Une deuxième entité 401 correspond à la base de données HSS de l'architecture IMS.

Ces données d'authentification sont habituellement associées à un compte IMS et correspondent notamment :

- à l'IMPU acronyme venant de l'expression anglo-saxonne « IP Multimedia Public Identity » ;

- à ΓΙΜΡΙ, acronyme venant de l'expression anglo-saxonne « IP Multimedia Private Identity » ;

- à un mot de passe IMS.

Une troisième entité 402 correspond au registraire de l'architecture IMS. Une base de données permet de stocker des informations comme des adresses IP associées à des identifiants uniformes de ressources URI, acronyme venant de l'expression anglo-saxonne « Uniform Resource Identifier ». Une quatrième entité 403 correspond à la plateforme hébergeant le service IMS que cherche à utiliser l'application tierce 400 embarquée dans le terminal distant. Cette plateforme est par exemple composée d'une pluralité de serveurs appartenant à l'opérateur de télécommunication de l'abonné-souscripteur.

Dans un premier temps, le terminal distant 400 envoie un message 404 au serveur 403. Le message 404 comprend aussi un identifiant du service IMS et un identifiant de l'utilisateur distant. Au préalable, l'utilisateur distant devra être authentifié auprès du serveur 403. Le message 404 comprend en outre une information concernant le type d'accès requis aux services IMS de l'opérateur. L'information concernant le type d'accès correspond par exemple à une information du type : appel national, appel international, appels fixes, appels mobiles, numéro surtaxé, localisation géographique, appel VoIP, services de télévision.

L'abonné-souscripteur doit avoir autorisé au préalable la délégation de ses droits IMS à l'utilisateur du terminal distant 400. Les opérateurs de télécommunication mettent habituellement à disposition de leurs abonnés un espace client mis en œuvre par au moins un serveur dans leur réseau. Selon un aspect de l'invention, l'abonné-souscripteur peut décider de partager son accès aux services souscrits avec d'autres utilisateurs et informer le réseau en utilisant cet espace client.

La liste des utilisateurs autorisés à accéder à un service souscrit par un abonné-souscripteur peut être mémorisée dans l'un des serveurs de l'espace client, dans l'un des serveurs de la plateforme dudit service ou dans la base de données HSS.

Lorsqu'un utilisateur distant qui n'a pas souscrit à un service IMS souhaite accéder à un service pour la première fois, le procédé selon l'invention va vérifier qu'il est un utilisateur autorisé, c'est-à-dire un utilisateur avec lequel l'abonné-souscripteur souhaite partager l'accès à un service IMS. Dans un mode de réalisation de l'invention, la vérification de l'autorisation d'accès au service est effectuée au sein de l'équipement mémorisant la liste des utilisateurs autorisés.

Si l'utilisateur abonné a effectivement autorisé la délégation de tout ou partie des droits IMS nécessaires à la réalisation des types d'accès décrit par la requête 404, des données temporaires d'authentification vont être générées correspondant à la délégation totale ou partielle des usages autorisés. Dans un mode de réalisation préféré, la plate-forme 403 mettant en œuvre le service IMS est responsable de la génération de ces données temporaires d'authentification. Une fois générées, un message 405 contenant ces données est envoyé au HSS 401 .

La plate-forme 403 mettant en œuvre le service IMS envoie également un message 407 contenant les données temporaires d'authentification au terminal de l'utilisateur distant 400.

Ce message comprend une adresse de redirection vers le serveur auprès duquel le terminal devra s'authentifier pour accéder au service IMS, par exemple le registraire 402. Cette adresse de redirection est par exemple un URI.

Dans un mode de réalisation préféré, les données temporaires d'authentification sont des données normalisées IMS. Avantageusement, le procédé selon l'invention pourra utiliser l'ensemble du protocole IMS pour l'authentification et l'utilisation du service IMS 403 à distance. Ainsi, la mise en œuvre du mécanisme proposé est très simple.

Les données temporaires d'authentification ainsi générées et transmises correspondent par exemple à au moins un identifiant associé à un mot de passe temporaire.

L'identifiant correspond par exemple à une nouvelle identité IMPI ou bien à une nouvelle identité IMPU. Une combinaison de deux nouvelles identités IMPI et IMPU peut également être utilisée comme identifiant.

Des jeux de données temporaires d'authentification peuvent ainsi être alloués à des utilisateurs autorisés. A titre d'exemple, un abonné-souscripteur peut vouloir autoriser les autres membres de sa famille à utiliser un service donné auquel il a souscrit. Pour cela, une interface utilisateur peut être mise en œuvre de manière à lui permettre de gérer les autorisations à ce service par utilisateur mais aussi par terminaux grâce à l'allocation d'IMPI temporaires. Cette flotte de terminaux correspond par exemple au téléphone mobile de son fils, à la tablette numérique de sa fille et à l'ordinateur portable de sa femme.

Avantageusement, ce mécanisme permet également de bloquer de manière simplifiée l'accès à des services IMS auquel un utilisateur donné pouvait accéder de par les autorisations qui lui avaient été accordées. Le blocage se fait par exemple en interdisant l'utilisation de tel ou tel jeu de données temporaires précédemment alloué. Cela a comme avantage d'éviter à l'abonné-souscripteur de modifier les données d'authentification associées à son compte et à ses services IMS et de les transmettre aux utilisateurs pour lesquelles il souhaite maintenir l'accès à son ou ses services.

Lorsque l'utilisateur et/ou son terminal distant 400 est en possession des données temporaires d'authentification nécessaires à l'accès au service IMS 403, il peut y accéder. Pour cela, il envoie un message 408 au registraire 402 dont il détient l'adresse URI. Ce message 408 contient également les données temporaires d'authentification qui lui ont été allouées, par exemple un identifiant IMPU associé à un mot de passe temporaire.

Une fois que le registraire 402 a reçu le message 408, celui-ci va vérifier que les données temporaires d'authentification sont correctes pour accéder aux services demandés. Pour cela un message 409 est envoyé au HSS 401 . Ce message 409 est une requête contenant les données temporaires d'authentification pour que celles-ci soit comparées aux données temporaires d'authentification mémorisées pour les mêmes services par le HSS 401 . Le HSS 401 envoie ensuite en réponse un message 410 de manière à indiquer au registraire 402 le résultat de cette comparaison. Si les données temporaires d'authentification transmises par le message 408 sont identiques à celles mémorisées dans le HSS 401 , le message 410 indique que la comparaison est positive. Cela signifie que le ou les services pour lesquels un accès a été requis par l'utilisateur distant peuvent être mis à sa disposition. Le HSS 401 envoie au terminal distant 400 un message 41 1 indiquant au terminal distant 400 que celui-ci s'est correctement authentifié.

La figure 5 présente un dispositif informatique pouvant mettre en œuvre le procédé d'attribution de données temporaires d'authentification. Ce dispositif comprend une unité centrale de traitement (CPU) 501 reliée à un bus de communication interne 500. Une mémoire à accès aléatoire (RAM) 507 est également connectée au BUS.

Le dispositif comprend en outre un contrôleur de périphérique de stockage de masse 502 dont la fonction est de gérer les accès à une mémoire de masse, tels qu'un disque dur 503.

La mémoire de masse mémorise des instructions de programmes informatiques et des données permettant la mise en œuvre du procédé d'attribution de données temporaires d'authentification.

La mémoire de masse peut être composée de toutes les formes de mémoire non-volatile, comme par exemple des EPROM, des EEPROM, des mémoires flash, des disques magnétiques tels que disques durs internes et des disques amovibles, des disques magnéto-optiques, et des disques CD-ROM 504.

Le dispositif comporte également un adaptateur de réseau 505 gérant l'accès à un réseau de télécommunication 506.

De manière optionnelle, le dispositif peut également comporter un équipement haptique 509 tel qu'un dispositif de commande de curseur, un clavier ou tout autre équipement similaire. Un équipement de commande de curseur peut ainsi être utilisé dans le dispositif pour permettre à l'utilisateur de positionner un curseur à un emplacement donné sur un écran 508. En outre, le dispositif de contrôle du curseur permet à l'utilisateur de sélectionner diverses commandes et de générer des signaux de contrôle. Le dispositif de commande de curseur peut être une souris, l'un des boutons de ladite souris étant utilisé pour déclencher la génération des signaux d'entrée.