+

WO2013186461A1 - Procede d'attribution de donnees d'authentifications temporaires pour l'acces a des services ims - Google Patents

Procede d'attribution de donnees d'authentifications temporaires pour l'acces a des services ims Download PDF

Info

Publication number
WO2013186461A1
WO2013186461A1 PCT/FR2013/051265 FR2013051265W WO2013186461A1 WO 2013186461 A1 WO2013186461 A1 WO 2013186461A1 FR 2013051265 W FR2013051265 W FR 2013051265W WO 2013186461 A1 WO2013186461 A1 WO 2013186461A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication data
ims
subscriber
access
temporary authentication
Prior art date
Application number
PCT/FR2013/051265
Other languages
English (en)
Inventor
Fabrice Petesch
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2013186461A1 publication Critical patent/WO2013186461A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time

Definitions

  • the invention relates to a method for assigning temporary authentication data for access to IMS services. It applies in particular to the field of IMS telecommunications networks.
  • the IMS an acronym from the IP Multimedia Subsystem, is a standardized network architecture that allows operators to provide multimedia services over fixed and mobile networks.
  • the creation of an IMS account is usually done according to two alternatives.
  • a first alternative is to create the IMS account statically when the subscriber to a telecommunications operator subscribes to a service.
  • a second alternative is to create the IMS account dynamically, that is, when the subscriber is trying to use a service for the first time.
  • the IMS account is then implemented using platforms belonging to the IMS network.
  • One of the actions performed by the IMS network at the time of account creation is to generate credentials, usually referred to as the "credentials". These authentication data allow a user to use his IMS account and the services to which he has subscribed.
  • VoIP Voice over IP
  • access to digital TV channels means of data exchange for online video games .
  • Authentication data is particularly important because it allows you to use the IMS account and IMS services subscribed by a subscriber.
  • the latter may be assigned a post-paid IMS account, that is to say an account for which the user will be billed based on his use of the services to which he has subscribed.
  • This user will then need the authentication data that have been allocated to him and which are associated with his IMS account and / or his services in order to access them.
  • the subscriber can for example access pay TV channels using his modem box as an access point or a voice telephony service on I P.
  • the authentication data are usually stored and encrypted in the modem box .
  • a user who has subscribed to an IMS service may want to share their access rights to this service with other people, such as family members.
  • Users may also want to use subscribed IMS services through a third-party application that would use the authentication credentials assigned to the subscriber, for example to charge the user for use of the service through the application. third party on the same invoice as its IMS services.
  • third-party application we mean here an application that differs from the initial application allowing the subscriber to access the IMS service because it is implemented by a third-party service provider different from the telecommunications operator from the subscriber has subscribed to an IMS service, or because the user uses a remote terminal of the access point assigned by the telecommunications operator, or because the user is not the subscriber who initially subscribes to the IMS service.
  • remote means remote from the access point (s) assigned to a subscriber.
  • This access point may be a modem box as mentioned above, but may also be of another type, for example a mobile radio cell to which the subscriber is attached.
  • An object of the invention is in particular to overcome the aforementioned drawbacks.
  • the subject of the invention is a method for assigning temporary authentication data by an entity of an IMS network to allow access by a third party application to an IMS service subscribed by a subscriber, said method comprising the steps following:
  • This method has the decisive advantage of allowing secure remote access to subscribed IMS services by a subscriber without it is necessary to modify the architecture of the IMS network to implement it and at no additional cost.
  • This delegation of authentication can be implemented on any type of terminal, for any user previously authorized by the subscriber or for any third-party application, and for all types of IMS services provided by a telecommunications operator.
  • the third-party application is embedded in a remote terminal.
  • the third-party application is used by a user other than the subscriber.
  • the temporary authentication data assigned to a user is erased from the database when the subscriber terminates the IMS access authorization for the third-party application.
  • this mechanism makes it possible to block in a simplified way the access to IMS services to which a given user or a third-party application could access by the authorizations which had been granted to him.
  • the temporary authentication data correspond to at least one element belonging to the group comprising: an IMPI identity, an IMPU identity, a temporary password, a reachability address of the registrar.
  • the IMPI and IMPU identities are standardized data within the framework of the IMS, their management can be implemented simply by using existing standard mechanisms.
  • the access rights to the IMS services subscribed by the subscriber-subscriber are stored by a server of the network of a telecommunications operator implementing a client space, in the HSS database or in the platform hosting the relevant IMS service.
  • This embodiment allows the user to manage easily and in a user-friendly way the rights of access to the IMS services to which he has subscribed.
  • Temporary authentication data can be generated by the platform hosting the IMS service.
  • the platform hosting the service is configured to:
  • the IMS sends a message to the third-party application to transmit the temporary authentication data to it, this message also containing a URI redirection address to which the third-party application will address its access requests to the IMS service later.
  • the third-party application is able to authenticate itself directly with the right entity of the IMS network in order to access the requested IMS service.
  • the redirection address is the address of a registrar of the IMS network.
  • a confirmation is requested from the subscriber before generating temporary authentication data for an authorized user.
  • the subscriber who subscribes to the IMS services can thus validate the access request. This mechanism improves the security of access to IMS services.
  • the invention also relates to a method for authenticating a user wanting to access an IMS service of an IMS network subscribed by a subscriber, via a third party application.
  • This authentication method comprises the steps of sending by the third-party application to an entity of the IMS network a request for access to the IMS service, and reception by the third-party application of temporary data of different authentication of the data. initially assigned to the subscriber.
  • the authentication method also comprises the following steps:
  • the temporary authentication data may, for example, have been allocated to the third-party application by the temporary data allocation method described above.
  • the invention also relates to a device comprising means adapted to implement the method of assigning temporary authentication data described above.
  • the invention also relates to a server comprising said device.
  • the invention also relates to a computer program comprising instructions for executing the process for assigning temporary authentication data as described above, when the program is executed by a processor.
  • the subject of the invention is also a processor-readable recording medium on which is recorded a program comprising instructions for the execution of the temporary authentication data allocation method described above, when the program is executed by a user. processor.
  • the invention also relates to a telecommunication terminal comprising means for sending an access request to an IMS service and means for receiving temporary authentication data as part of the authentication method described above.
  • the terminal also comprises means for storing temporary data. authentication method and means for using them as part of the authentication method described above.
  • the subject of the invention is also a computer program comprising instructions for executing the method of authenticating a user as described above according to any one of the described embodiments, when the program is executed by a user. processor.
  • the subject of the invention is also a recording medium readable by a processor on which is recorded a program comprising instructions for executing the method of authenticating a user as described above according to any one of the realization described, when the program is executed by a processor.
  • FIG. 1 illustrates the oAuth mechanism and gives an example of messages exchanged between an internet browser, an intermediation application and a third party service
  • FIG. 2 presents a simplified diagram of the procedure for allocating temporary authentication data according to the invention
  • Figure 3 shows a simplified diagram of the authentication procedure when a third-party application uses temporary authentication data
  • FIG. 4 shows a preferred embodiment of the method according to the invention using a message exchange scheme between several entities of an IMS architecture
  • FIG. 5 presents a computing device that can implement the method for assigning temporary authentication data.
  • Figure 1 illustrates in a simplified manner a message exchange typical of the oAuth mechanism.
  • FIG. 1 illustrates the oAuth mechanism and gives an example of messages exchanged between an internet browser 100, an intermediation application 101 and a third party service 102.
  • the intermediation application 101 is for example a blog hosted on a server and putting Interaction with the third party service 102.
  • the third party service 102 corresponds, for example, to a service offered by a social network to its subscribers.
  • the blog plays the role of intermediation application and can for example broadcast information about subscribers to the social network if they want and have authorized.
  • the intermediation application 101 be authorized to access the third party service 102.
  • the oAuth mechanism In order to prevent the authentication information associated with the accounts of the subscribers to the third party service 102 from being directly transmitted to the intermediation application 101, the oAuth mechanism generates a temporary password specific to the application 101, to the user. user 100 and the type of access requested. It is this temporary password that will be used by the intermediation application 101 to access the third party service 102.
  • FIG. 1 appear the user 100, the intermediation application 101 and the third party service 102, these three entities exchanging messages as part of the oAuth mechanism.
  • the user 100 accesses the Internet portal of the intermediation application 101 using his terminal and sends him a message 103 indicating that he wishes to give him access to data provided by the service.
  • third party 102 a precondition being that the user is well authenticated with the platform hosting the third party service 102.
  • the intermediation application If the intermediation application does not have at this stage of data authorizing access to the third party service 102, it redirects the user to the oAuth authentication site of the third party service for generating temporary authentication data. For this, a redirection message 104 is sent by the intermediate application 101 to the user 100. This redirection message comprises in particular the address of the oAuth authentication site hosted on one of the servers implementing the third party service 102. The user 100 then sends a request 105 to the authentication site oAuth of the third party service 102. This message includes a redirection address to the application 101 which will be used for subsequent requests for access to the third party service.
  • This message 105 also includes an identifier of the service to which the intermediation application wishes to access as well as a user identifier and a set of data making it possible to define the type of access desired to the third party service 102.
  • the oAuth site of the third party service 102 then responds by sending a message 106 asking the user 100 to identify himself with his authentication data. For this, the user 100 transmits a message 107 to the oAuth site of the third party service 102 in which the said authentication data are contained. In response to this message 107, the oAuth site of the third party service 102 responds with a message 108 to the user 100 after the latter has accepted all or part of the access types defined in the message 105. This message 108 contains a temporary password, also called token, and a redirection address to the application 101. Following receipt of this temporary password, the user 100 sends a message 109 to the intermediation application 101 in order to transmit it to him.
  • a temporary password also called token
  • the intermediation application 101 can therefore identify itself and authenticate with the third party service 102. For this, it sends a message 1 10 including this temporary password to the third party service 102. The intermediation application is then authenticated and authorized to access the third party service. A confirmation message 1 1 1 is then transmitted to the intermediation application 101 and another confirmation message 1 12 is transmitted to the user 100.
  • the intermediation application can then access the third party service subscribed by the user without the authentication data to the third party service of the user has been transmitted.
  • the IMS account is usually associated with a single set of authentication data, such as a user ID associated with a password.
  • a user is subscribed to a telecommunication operator providing access to the Internet via a modem box connected to his network, he can use his IMS IDs and passwords to access the services to which he has subscribed.
  • the subscriber when the subscriber wishes to access a new IMS service to which he has not yet subscribed, he does not have an IMS ID and password for that.
  • the user In order to obtain an identifier and a password, the user will have to identify himself to his operator. For this, a user interface implemented by the operator can be used. Once the new service is subscribed, its IMS ID and password can be transmitted to it by using for example an encrypted link for more security. Using this IMS authentication data, the subscribed user can then access the IMS services to which he has subscribed.
  • the subscriber-subscriber wishes to access these services remotely from his access point from a mobile terminal, for example, he must generally use a password and an IMS identifier. If the subscriber-subscriber wants to allow one of his relatives to access the same service, he will have to communicate his password and his IMS ID. In addition, if after using a mobile terminal that is not his, the IMS ID and password are stored there, any user of this terminal will be able to access his IMS service. As mentioned earlier, it is clear that this type of mechanism lacks security.
  • the method according to the invention notably allows a user authorized by the one who has subscribed to the IMS services to access it remotely without the authentication data being communicated to him.
  • This user is preferably also subscribed to the same telecommunication operator.
  • FIG. 2 presents a simplified diagram of the procedure for allocating temporary temporary authentication data according to the invention.
  • subscriber-subscriber designates a subscriber who has subscribed to an IMS service from his telecommunication operator.
  • a user who may be the subscriber-subscriber or a different user of the subscriber-subscriber, sends an access request to the IMS services using a third-party application 200. If this request corresponds to a first request for access to said IMS service, temporary authentication data will be generated.
  • a verification step 201 has for objective to consult a database of the operator of to ensure that the third-party application is authorized to access the service. If so, temporary authentication data is generated 202.
  • step 201 verifies that the third-party application is authorized to access said service based on data of the user using the third-party application and / or according to the data of the terminal used. by the user to access the service.
  • HSS is an acronym from the English expression "Home Subscriber Server”.
  • An HSS database notably stores the information relating to the IMS accounts of the users of the network, such as, for example, authentication data.
  • step 203 the temporary authentication data is also transmitted to the third-party application.
  • the temporary authentication data are then stored 204 by both the HSS database.
  • the temporary authentication data are transmitted to the platform hosting the IMS service and stored by the platform.
  • the platform hosting the IMS service implements step 202 for generating the temporary authentication data.
  • the third-party application can then access the services subscribed by the subscriber and for which access rights have been granted to them.
  • FIG. 3 shows a simplified diagram of the authentication procedure when a third-party application uses temporary authentication data.
  • these authentication data may have been allocated according to the authentication method described in connection with FIG. 2 or another method.
  • the third-party application following the sending by the third-party application to an entity of an IMS network of an access request, the third-party application has received temporary authentication data.
  • the third-party application 300 sends an authentication request to the registrar of the IMS network.
  • a registrar usually designated by the English word "registrar" is an entity of the IMS network whose particular function is to manage authentication in the IMS world and requests from users to report their current position.
  • the authentication request also contains the registrar's address as well as the temporary authentication data.
  • An authentication step 301 is then implemented. This step corresponds to a data exchange between the registrar and the HSS of the IMS network in order to compare the temporary authentication data contained in the request at step 300 as well as the temporary authentication data stored in the HSS. When these temporary authentication data are identical, a digital data exchange step 302 makes it possible to access the IMS services.
  • the authentication method described with reference to FIG. 3 may for example be implemented by a communication terminal comprising communication means such as, for example, a network interface for sending to an entity of the IMS network an access request to the IMS service, and receive temporary authentication data different from the authentication data initially assigned to the subscriber.
  • the terminal also comprises means for storing the temporary authentication data such as, for example, a RAM or ROM memory and a processing unit such as, for example, a processor making it possible to implement the steps of the authentication method.
  • the communication means also make it possible to send the authentication request to the registrar of the IMS network.
  • FIG. 4 shows a particular embodiment of the method according to the invention using a message exchange scheme between several entities of an IMS architecture.
  • This figure shows four entities communicating with each other.
  • a first entity 400 corresponds to a remote terminal used by a user wanting to access an IMS service.
  • the third-party application is embedded in the remote terminal.
  • This remote terminal may be a smart mobile phone usually designated by the term "smart phone", a touch pad, a modem box or any other type of connected terminal adapted to use the IMS service.
  • This remote terminal 400 thus plays the role of IMS client.
  • a second entity 401 corresponds to the HSS database of the IMS architecture.
  • These authentication data are usually associated with an IMS account and correspond in particular to:
  • IP Multimedia Private Identity
  • a third entity 402 corresponds to the registrar of the IMS architecture.
  • a database makes it possible to store information such as IP addresses associated with uniform resource identifiers URI, an acronym derived from the English expression "Uniform Resource Identifier”.
  • a fourth entity 403 corresponds to the platform hosting the IMS service that seeks to use the third-party application 400 embedded in the remote terminal. This platform is for example composed of a plurality of servers belonging to the telecommunications operator of the subscriber-subscriber.
  • the remote terminal 400 sends a message 404 to the server 403.
  • the message 404 also includes an identifier of the IMS service and an identifier of the remote user.
  • the remote user will have to be authenticated with the server 403.
  • the message 404 furthermore includes information concerning the type of access required to the IMS services of the operator.
  • the information regarding the type of access corresponds, for example, to information of the type: national call, international call, fixed calls, mobile calls, premium rate number, geographical location, VoIP call, television services.
  • the subscriber-subscriber must have previously authorized the delegation of his IMS rights to the user of the remote terminal 400.
  • the telecommunication operators usually make available to their subscribers a client space implemented by at least one server in their network. .
  • the subscriber-subscriber can decide to share his access to subscribed services with other users and inform the network using this customer area.
  • the list of users authorized to access a service subscribed by a subscriber-subscriber can be stored in one of the servers of the customer area, in one of the servers of the platform of said service or in the database HSS.
  • the method according to the invention will verify that it is an authorized user, that is to say a user with which subscriber-subscriber wants to share access to an IMS service.
  • the verification of the access authorization to the service is performed within the equipment storing the list of authorized users.
  • the platform 403 implementing the IMS service also sends a message 407 containing the temporary authentication data to the terminal of the remote user 400.
  • This message includes a redirection address to the server from which the terminal will have to authenticate to access the IMS service, for example the registrar 402.
  • This redirection address is for example a URI.
  • the temporary authentication data is IMS standardized data.
  • the method according to the invention may use the entire IMS protocol for authentication and use of the IMS 403 remote service.
  • the implementation of the proposed mechanism is very simple.
  • the temporary authentication data thus generated and transmitted correspond for example to at least one identifier associated with a temporary password.
  • the identifier corresponds, for example, to a new IMPI identity or to a new IMPU identity.
  • a combination of two new identities IMPI and IMPU can also be used as an identifier.
  • Temporary authentication data sets can thus be allocated to authorized users. For example, a subscriber-subscriber may want to allow other members of his family to use a given service to which he has subscribed.
  • a user interface can be implemented so as to enable it to manage the authorizations to this service per user but also by terminals through the allocation of temporary IMPI.
  • This fleet of terminals corresponds for example to his son's mobile phone, his daughter's digital tablet and his wife's laptop.
  • this mechanism also makes it possible to block in a simplified way the access to IMS services to which a given user could access by the authorizations which had been granted to him.
  • the blocking is done for example by prohibiting the use of this or that temporary dataset previously allocated.
  • This has the advantage of preventing the subscriber-subscriber from modifying the authentication data associated with his IMS account and services and transmitting them to the users for whom he wishes to maintain access to his service (s).
  • the user and / or his remote terminal 400 When the user and / or his remote terminal 400 is in possession of the temporary authentication data necessary to access the IMS 403 service, he can access it. For this purpose, it sends a message 408 to the registrar 402 of which it holds the URI address. This message 408 also contains the temporary authentication data that has been allocated to it, for example an identifier IMPU associated with a temporary password.
  • a message 409 is sent to the HSS 401.
  • This message 409 is a request containing the temporary authentication data so that it is compared with the temporary authentication data stored for the same services by the HSS 401.
  • the HSS 401 then sends a message 410 in response to indicate to the registrar 402 the result of this comparison. If the temporary authentication data transmitted by the message 408 are identical to those stored in the HSS 401, the message 410 indicates that the comparison is positive. This means that the service or services for which access was requested by the remote user can be made available.
  • the HSS 401 sends to the remote terminal 400 a message 41 1 indicating the remote terminal 400 that it has correctly authenticated.
  • FIG. 5 presents a computing device that can implement the method for assigning temporary authentication data.
  • This device comprises a central processing unit (CPU) 501 connected to an internal communication bus 500.
  • Random access memory (RAM) 507 is also connected to the BUS.
  • the device further includes a mass storage device controller 502 whose function is to manage accesses to a mass memory, such as a hard disk 503.
  • a mass storage device controller 502 whose function is to manage accesses to a mass memory, such as a hard disk 503.
  • the mass memory stores computer program instructions and data for implementing the temporary authentication data assignment method.
  • the mass memory can be composed of all forms of non-volatile memory, such as for example EPROMs, EEPROMs, flash memories, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and 504 CD-ROM discs.
  • non-volatile memory such as for example EPROMs, EEPROMs, flash memories, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and 504 CD-ROM discs.
  • the device also includes a network adapter 505 managing access to a telecommunications network 506.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procédé d'attribution de données d'authentifications temporaires pour l'accès à des services IMS 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 (200) d'une requête d'accès en provenance de l'application tierce; la vérification (201) que l'application tierce est autorisée par l'abonné à accéder au service IMS; la génération (202) de données temporaires d'authentification différentes des données d'authentification attribuées initialement à l'abonné; la transmission (203) des données temporaires d'authentification à l'application tierce et à une base de données du réseau IMS.

Description

Procédé d'attribution de données d'authentifications temporaires pour l'accès à des services IMS
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.

Claims

REVENDICATIONS
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é auprès d'un opérateur de télécommunications, ladite application tierce étant 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 audit service IMS, ledit procédé comprenant les étapes suivantes :
a. la réception (200) d'une requête d'accès (404) en provenance de l'application tierce ;
b. la vérification (201 ) que l'application tierce est autorisée par l'abonné à accéder audit service IMS ;
c. la génération (202) de données temporaires d'authentification différentes des données d'authentification attribuées initialement à l'abonné par l'opérateur de télécommunications pour accéder audit service IMS;
d. la transmission (203) des données temporaires d'authentification à l'application tierce (400) et à une base de données (401 ) du réseau IMS.
Procédé selon la revendication 1 dans lequel l'application tierce est embarquée dans un terminal distant (400).
Procédé selon la revendication 1 dans lequel l'application tierce est utilisée par un utilisateur différent de l'abonné (400).
Procédé selon l'une des revendications 1 à 3 dans lequel les données temporaires d'authentification attribuées à un utilisateur sont effacées de la base de données (401 ) lorsque l'abonné résilie l'autorisation d'accès au service IMS pour l'application tierce. 5- Procédé selon l'une quelconque des revendications 1 à 4 dans lequel 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.
6- Procédé selon l'une des revendications précédentes dans lequel les autorisations d'accès aux services IMS souscrits par l'abonné sont mémorisées par un serveur du réseau de l'opérateur de télécommunication mettant en œuvre un espace client, dans la base de données (401 ) ou dans une plateforme (403) hébergeant le service IMS concerné.
7- Procédé selon l'une des revendications précédentes dans lequel les données temporaires d'authentification sont générées par une plateforme (403) hébergeant le service IMS. 8- Procédé selon la revendication 7 dans laquelle la plateforme (403) hébergeant le service IMS envoie un message (407) à l'application tierce (400) 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.
9- Procédé selon l'une des revendications précédentes dans lequel une confirmation est demandée à l'abonné avant de générer des données temporaires d'authentification pour un utilisateur autorisé.
10- Procédé d'authentification d'un utilisateur voulant accéder à un service IMS d'un réseau IMS, souscrit par un abonné auprès d'un opérateur de télécommunications, par l'intermédiaire d'une application tierce 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 audit service IMS, le procédé d'authentification comportant les étapes suivantes : a. envoi (200) par l'application tierce à une entité du réseau IMS d'une requête d'accès au service IMS,
b. réception (203) par l'application tierce de données temporaires d'authentification différentes des données d'authentification attribuées initialement à l'abonné par l'opérateur de télécommunications pour accéder audit service IMS.
1 - Procédé d'authentification selon la revendication 10 comportant les étapes suivantes :
a. l'envoi (300) 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 ;
b. l'accès au service IMS (302) par l'utilisateur, suite à l'authentification (301 ) 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.
2- Dispositif 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é auprès d'un opérateur de télécommunications, ladite application tierce étant 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 audit service IMS, le dispositif comprenant des moyens adaptés pour mettre en œuvre le procédé d'attribution de données d'authentifications temporaires selon l'une des revendications 1 à 9.
13- Serveur comprenant un dispositif selon la revendication 12.
14- Programme d'ordinateur comportant des instructions pour l'exécution du procédé d'attribution selon l'une quelconque des revendications 1 à 9, lorsque le programme est exécuté par un processeur.
15- Terminal de télécommunication comportant 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 selon la revendication 1 1 .
PCT/FR2013/051265 2012-06-11 2013-06-04 Procede d'attribution de donnees d'authentifications temporaires pour l'acces a des services ims WO2013186461A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1255458A FR2991838A1 (fr) 2012-06-11 2012-06-11 Procede d'attribution de donnees d'authentifications temporaires pour l'acces a des services ims
FR1255458 2012-06-11

Publications (1)

Publication Number Publication Date
WO2013186461A1 true WO2013186461A1 (fr) 2013-12-19

Family

ID=47227893

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2013/051265 WO2013186461A1 (fr) 2012-06-11 2013-06-04 Procede d'attribution de donnees d'authentifications temporaires pour l'acces a des services ims

Country Status (2)

Country Link
FR (1) FR2991838A1 (fr)
WO (1) WO2013186461A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110002341A1 (en) * 2008-03-14 2011-01-06 Ayodele Damola Method and apparatus for remote access to a local network
US20110040836A1 (en) * 2009-05-04 2011-02-17 Andrew Allen System and method for implementing media and media control transfer between devices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110002341A1 (en) * 2008-03-14 2011-01-06 Ayodele Damola Method and apparatus for remote access to a local network
US20110040836A1 (en) * 2009-05-04 2011-02-17 Andrew Allen System and method for implementing media and media control transfer between devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KE LIU ET AL: "OAuth Based Authentication and Authorization in Open Telco API", COMPUTER SCIENCE AND ELECTRONICS ENGINEERING (ICCSEE), 2012 INTERNATIONAL CONFERENCE ON, IEEE, 23 March 2012 (2012-03-23), pages 176 - 179, XP032170905, ISBN: 978-1-4673-0689-8, DOI: 10.1109/ICCSEE.2012.275 *

Also Published As

Publication number Publication date
FR2991838A1 (fr) 2013-12-13

Similar Documents

Publication Publication Date Title
US10389793B2 (en) System and method for providing feature-level delegation of service entitlements among users in a group
US10686770B2 (en) Apparatus and method for managing software applications of a mobile device server
US9258587B2 (en) Content blackout determinations for playback of video streams on portable devices
US9118653B2 (en) System and method of secure sharing of resources which require consent of multiple resource owners using group URI's
US9819987B2 (en) Content entitlement determinations for playback of video streams on portable devices
US9009787B2 (en) System and method of mapping and protecting communication services with OAuth
EP2156306B1 (fr) Méthode et système pour appel pré-authentifié pour des applications vocales
US8667579B2 (en) Methods, systems, and computer readable media for bridging user authentication, authorization, and access between web-based and telecom domains
US8516039B2 (en) Apparatus and method for managing mobile device servers
US20140289839A1 (en) Resource control method and apparatus
EP2560341A2 (fr) Authentification et association de plusieurs dispositifs
US20140325553A1 (en) Authentication and authorization for internet video client
US20090113481A1 (en) Systems, methods and computer program products for providing presence based services
US20080104411A1 (en) Methods and apparatus for changing passwords in a distributed communication system
EP2884716A1 (fr) Procédé d'authentification par jeton
EP1683388A2 (fr) Methode de gestion de la s curit d' applications avec un module de securite
CA2781960C (fr) Systeme et methode pour assurer la gestion de la duree utile utilisateur et l'orchestration du service de plusieurs services media sur plusieurs ecrans d'affichage
US9363663B2 (en) Method and apparatus for providing cellphone service from any device
JP2014506408A (ja) プレイスシフト（ｐｌａｃｅｓｈｉｆｔｉｎｇ）を用いたメディアコンテンツへの分散アクセスのためのシステム及び方法
US10757165B2 (en) System and method for delegating service entitlements across multiple media services
CN112217910B (zh) 视频服务访问方法、装置、网络设备和存储介质
US9232078B1 (en) Method and system for data usage accounting across multiple communication networks
CN117454399A (zh) 三权分置下数据产品使用管控的方法、装置及电子设备
WO2013186461A1 (fr) Procede d'attribution de donnees d'authentifications temporaires pour l'acces a des services ims
KR101074068B1 (ko) 홈네트워크 서비스를 위한 통합 인증 시스템 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13730038

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13730038

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载