Automatic authentication via a gateway for access to a resource by a device

Abstract

A method for accessing a resource (R) accessible on a server (S) connected to a first telecommunications network (WAN) by a device (T) connected to a second telecommunications network (LAN) linked to said first telecommunications network by a gateway (P), wherein said gateway: - determines (S1) authentication data for said resource; - provides (S2) authentication data to said server (S) upon receipt of an authentication request received from said server (S) and intended for said device; - transmits (S3) said resource received from said server (S) to said device (T). Figure for the abbreviation: Fig. 1

Description

Title of the invention: Automatic authentication via a gateway for access to a resource by a device. FIELD OF THE INVENTION

[0001] The present invention relates to secure access to resources available on servers from equipment connected to the server via a gateway. It applies to resources secured by the requirement for the equipment to provide authentication data. These resources are typically web resources.

[0002] Many resources accessible on the servers are secured to allow access only after user authentication. These resources can be web pages, audio-video content, etc. Authentication is necessary when these resources should only be accessible to specific users, for example, because they contain personal data (banking website, etc.) or because a prior action (payment, subscription, etc.) is required.

[0003] It is customary for the user to have to authenticate with the server hosting the requested resource by providing authentication data, typically a pair consisting of a user identifier (or "login" according to the usual English language terminology) and a password.

[0004] Because authentication data is sensitive, users are often required to define passwords that meet stringent requirements (number of characters, various types of characters, etc.) and to change these passwords regularly. As a result, remembering and managing passwords has become a complex task for users.

[0005] Specific applications are proposed for managing these passwords. These applications, or "vaults", generally have to be installed manually by the user for each device used and are not necessarily available on all devices.

[0006] Some equipment, such as connected objects (connected speakers, etc.) do not have open interfaces allowing the user to install new applications.

[0007] Furthermore, when a user (or typically a family) has multiple devices that can access the same resource, it is necessary to install and then configure each of these devices, storing the authentication data. When it becomes necessary to modify this authentication data Periodically, he must perform this reconfiguration on each of the equipment, via their specific interfaces and procedures.

[0008] This situation can arise when a user wishes to be able to access an audiovisual content delivery service from one or more televisions, one or more computers, the mobile phones of each family member, connected speakers (to broadcast radio, on-demand music, etc.)...

[0009] It is understood that the need to configure each piece of equipment individually can become a tedious task, especially when there is a plurality of accesses to manage in the same way.

[0010] There is therefore a need to improve current proposals of the state of the art, to allow for more ergonomic management of access to resources, particularly in the case of a plurality of equipment. Summary of the invention

[0011] The invention aims to enable access to a remote resource by at least one device through automated and transparent authentication performed by a gateway. In particular, it avoids the need to modify the device environment and can therefore be adapted to any type of device, including those that do not allow the addition of applications or configuration.

[0012] To this end, according to a first aspect, the present invention can be implemented by a method for accessing a resource accessible on a server connected to a first telecommunications network by equipment connected to a second telecommunications network linked to said first telecommunications network by a gateway, in which said gateway - determines authentication data for said resource; - provides authentication data to said server upon receipt of an authentication request received from said server and intended for said equipment; - transmits said resource received from said server to said equipment).

[0013] According to preferred embodiments, the invention comprises one or more of the following features which can be used separately or in partial combination with each other or in total combination with each other: - The authentication data is determined from an identifier corresponding to the resource, transmitted by the equipment during the initial request. Typically, this initial request is to a domain name server or DNS server. Thus, the gateway can determine the identifier corresponding to the resources in subsequent requests, leveraging standard protocol exchanges without requiring additional signaling. - The gateway stores an association between identifiers corresponding, respectively, to a set of resources, including the said resource, and the said authentication data. These stored associations can thus be maintained in the medium or long term and allow access to resources at any time by the equipment connected to the gateway. - said gateway makes access to said resource subject to an identifier of said equipment. It is thus easy to foresee an access control mechanism inherent to the proposed process. - said association is further associated with at least one identifier of an authorized device, and in which, upon receipt of a request to access said resource by said device, said gateway checks whether an identifier of said device is associated with said resource in order to determine said authentication data. - A user can provision these associations using an administration interface of the gateway. This mechanism allows for the sharing of the administrative task that each user would otherwise have to perform for all their devices.

[0014] Another aspect of the invention relates to a gateway for accessing a resource accessible on a server connected to a first telecommunications network by equipment connected to a second telecommunications network linked to said first telecommunications network by said gateway, wherein said gateway is adapted for: - determine authentication data for said resource; - provide authentication data to said server upon receipt of an authentication request received from said server and intended for said equipment; - transmit said resource received from said server to said equipment.

[0015] According to a particular embodiment, the gateway includes a digital vault for storing said authentication data. This allows authentication data to be stored securely, as on a personal device, but in a centralized and shared manner.

[0016] Another aspect of the invention relates to a computer program suitable for implementation on a gateway, the program comprising code instructions which, when executed by a processor, carries out the steps of the process as previously defined.

[0017] Another aspect of the invention relates to a data carrier on which at least one series of program code instructions for the execution of a process as previously defined has been stored.

[0018] Other features and advantages of the invention will become apparent from the following description of a preferred embodiment of the invention, given by way of example and with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE FIGURES

[0019] [Fig. 1] illustrates a context for implementing a process according to embodiments of the invention,

[0020] Figure [Fig. 2] illustrates an example of the functional architecture of a management entity according to one embodiment of the invention,

[0021] Figure [Fig. 3] schematically represents a timing diagram of a process according to one embodiment of the invention.

[0022] DETAILED DESCRIPTION OF IMPLEMENTATION METHODS OF THE INVENTION

[0023] Figure 1 illustrates an example of the context for implementing the proposed method.

[0024] A device wishes to access a resource R accessible on a server S connected to a first WAN telecommunications network.

[0025] This equipment T can be any device adapted to access a telecommunications network. To do this, it has suitable hardware interfaces and corresponding software modules (implementing in particular the protocol stack corresponding to the hardware interface and the type of telecommunications network).

[0026] The equipment T can be of different kinds: computer ORD (portable or fixed), mobile communication terminal of type “smartphone”, MOB, digital tablet, connected television, TV, etc.

[0027] The television can be natively connected or connected via an associated device such as a TV stick connected to the television, generally via HDMI. An example of an external device communicating with a TV is Chromecast. Chromecast is a real-time media streaming device (media gateway) developed and marketed by Google. The device plugs into the HDMI port of a television and communicates, via Wi-Fi, with another device connected to the Internet (computer, smartphone, tablet, etc.) in order to display on the television the media content received from an application compatible with Google Cast technology, from the Google Chrome browser on a computer, or from certain Android devices.

[0028] The resource R can also be of different kinds: generally speaking, it can be any resource that can be identified by an address or URL ("Unified Resource Locator"). It can be a file in any format that can be accessed by any equipment.

[0029] In concrete terms, this can be a web page, that is to say a computer file in HTML (“Hyper Text Markup Language”) format, or a set of web pages. It can also be an audio or video file, an audio-video resource in broadcast (or “streaming” in English), etc.

[0030] This resource is accessible on a server S. This server S must be understood here from a functional point of view: the server S can be concretely deployed on a single machine or within a set of machines operating in a "farm", or on a computing or cloud platform (or "cloud computing" in English).

[0031] It is assumed here that the resource is secure: in order to access this resource, the user of the equipment must authenticate themselves. According to a mechanism known per se, if authentication is successful, the server S verifies whether the equipment can actually access the requested resource.

[0032] This mechanism can be implemented in different situations.

[0033] A first example is one or a set of pages containing the user's personal data. This could be, for example, an e-commerce site, a banking institution's website, a government website, etc. In such a situation, it is important to protect against access to the resource by other users.

[0034] Another example is one or more pieces of content, for example audio-video, access to which is subject to a prior action, for example payment. The payment may be linked to this (or these) piece(s) of content in a "pay per view" type modality, or may be linked to a more general subscription (channel, service, etc.).

[0035] Other examples are obviously possible, and the proposed process is independent of the nature of the resource required by the equipment.

[0036] When a resource is secured, the server may require the provision of authentication data. This data is generally a pair consisting of a user identifier (or "login" according to common English terminology) and a password. However, other embodiments are possible.

[0037] This provision makes it possible to verify the identity of the user and thus allow him access to the resources to which he is entitled.

[0038] The server S is connected to a first telecommunications network of the "WAN" type (for "Wide Area Network" in English, or extended network).

[0039] This type of telecommunications network can typically be composed of several interconnected networks, including an access network allowing clients to connect to a main network (itself made up of an interconnection of subnets) or "backbone". This WAN is commonly called the Internet.

[0040] In general, the T equipment is connected to a second telecommunications network which can be a local network, LAN (for "Local Area Network" in English).

[0041] This could, for example, be a wireless local area network, commonly called WLAN for "Wireless Local Area Network". It could conform to the Wi-Fi, or wifi, protocols as specified in the IEEE 802.11 family of standards documents (or ISO / IEC 8802-11).

[0042] This local area network (LAN) can be an internal network within a home (home network), for example, allowing all the equipment, or clients, of a user or family to be connected. The LAN can also be an internal network of a company, allowing the equipment, or clients, of the various users of the company to be connected.

[0043] The local LAN network can be connected to the WAN network via a gateway P.

[0044] Gateway P is therefore in charge of routing and forwarding data packets between the two communication networks, LAN, WAN.

[0045] It can also provide additional functionalities such as that of a Wi-Fi router, in order to constitute the LAN communication network itself. However, this functionality can, depending on the embodiment, be transferred to another piece of equipment.

[0046] An example of such a gateway is the Livebox™ from the company Orange.

[0047] According to one aspect of the proposed method, the gateway acts with respect to the server S to authenticate the user of the equipment T in its place.

[0048] Figure 2 represents a flowchart illustrating a process that can be implemented work via the footbridge.

[0049] Gateway P can implement the following steps: - SI step: determination of authentication data for the R resource that the equipment wishes to access; - Step S2: provision of authentication data to server S upon receipt of an authentication request received from this server S and intended for equipment T; - Step S3: transmission of the resource R received from server S to the equipment T.

[0050] Thus, when a request from equipment T triggers the transmission of an authentication request from server S, this request can be processed by gateway P, in step S2, by providing the authentication data previously determined in step SL

[0051] Once authentication has been performed, the server S can grant (or deny) access to the requested resource R. This access can be concretely manifested by the transmission of the resource R from the server S to the equipment T, via the gateway P.

[0052] Figure 3 illustrates more precisely an example of the implementation of this process in the form of a chronogram.

[0053] In a first preliminary step, S0, authentication data can be provisioned in the gateway P.

[0054] This can therefore include a memory (preferably local, but it can possibly be remote) to store this authentication data.

[0055] According to one embodiment, the gateway P includes a digital safe for storing these authentication data.

[0056] Such a digital safe is a software, or primarily software, mechanism that allows a set of digital data to be secured within an online platform or equipment, such as here the gateway P.

[0057] A digital safe can implement different technologies to achieve this data security objective: - Data encryption. Various tools and mechanisms can be implemented such as AES (Advanced Encryption Standard), RSA (Rivest-Shamir-Adleman), TLS / SSL (Transport Layer Security / Secure Sockets Layer)... - Authentication, usually two-factor authentication, to access the digital vault - And, optionally, physical security to increase security, with technologies such as HSM for "Hardware Security Module" in English, or TPM for "Trusted Platform Module", based on the addition of a dedicated microelectronic chip.

[0058] Software tools also exist for implementing such digital vaults, with varying security performance characteristics, and designed for different operating systems. These tools can therefore be easily deployed on gateway P depending on the operating system it uses.

[0059] According to one embodiment, during the preliminary step S0, the gateway stores an association between at least one identifier corresponding to the resource R and the corresponding authentication data.

[0060] The identifier corresponding to the resource can directly and uniquely identify the resource, that is, be an identifier of the resource. It can be a URI (for "Uniform Resource Identifier") of that resource, for example.

[0061] According to another embodiment, the identifier corresponding to the resource can identify a set of resources of which the requested resource is a part. For example, the identifier can be that of a website, for example, or that of the host associated with the requested resource.

[0062] In such a situation, any particular resource belonging to that host can be associated with the same authentication data, so that it is sufficient to remember a host identifier, rather than remembering the identifiers of each resource individually. Furthermore, the user is not necessarily aware of these R resources at the time of provisioning, but only of a website or a host.

[0063] For example, an R resource belonging to a site "mysite" to have as its corresponding identifier "www.mysite.com / R" or, preferably, "www.mysite.com"

[0064] It is thus easy for the gateway P to determine later that a request to a resource R corresponds to an association provisioned in its memory.

[0065] Gateway P may have an administration interface that allows a user to provision these associations. The user can thus choose the websites for which they wish to delegate automatic authentication to Gateway P.

[0066] This task is similar to that performed in proposals of the technique where the user must perform this provisioning on their equipment. However, according to the proposed method, the provisioning is performed on a gateway P, which makes it possible to share this provisioning for several devices (which access the resources R via the gateway P) and, possibly, for several users.

[0067] The administration interface can already be provided and adapted to allow the additional functionality of provisioning (and modifying) this association. It can be a web-type interface to which the user can connect via a device T. It can be an API (Application Programming Interface) type interface to which the user can connect using a specific application installed on a device T. Other embodiments are obviously also possible.

[0068] Thus, the gateway can store a table, or database, consisting of associations provisioned by the user or, possibly, by other means (for example, automatically retrieved from the T equipment by a synchronization tool, or retrieved from a remote service platform, etc.)

[0069] Later, a device T wishes to access a resource R available on a server S.

[0070] In this situation, it issues a first ml request. This first request contains an identifier corresponding to the R resource (for example its URL). Typically, this first request is intended for a domain name server or DNS (for "Domain Name Server" in English).

[0071] The role of this domain name server, DNS, is to provide the network address (or IP for "Internet Protocol") at which the requested resource is available.

[0072] This first request mi therefore contains an identifier corresponding to the resource R. The gateway P can therefore determine this identifier from this first request mb

[0073] In an SI step, the gateway P can determine authentication data for the resource R identified by the identifier corresponding to the resource transmitted by this first request mb

[0074] To do this, it can rely on the associations previously provisioned (step S0). In particular, it can determine the authentication data from the identifier corresponding to the resource transmitted in this first request mi by searching for it within these associations and selecting the corresponding authentication data.

[0075] The domain name server, DNS, responds to the first query mb with a message m2 indicating the address of the server S on which the resource R is accessible. This address is typically an IP (Internet Protocol) address, IPv4 or IPv6. The gateway P can then store an association between the IP address and the URL.

[0076] According to one embodiment, the gateway P can subject access to the resource R to the identifier of the equipment T.

[0077] The gateway can interpret the first mipour request to determine an identifier of the equipment, such as its IP address (in the case where this is fixed and not assigned to each connection) or its physical address, MAC.

[0078] It is then possible to grant access to the resource only for certain equipment.

[0079] These devices can be planned in advance, for example, during the provisioning of associations in step S0. In which case, the gateway can be configured to associate the provisioned associations with at least one identifier of an authorized device. Thus, upon receiving a request to access resource R from this device, the gateway P checks whether a device identifier is associated with the resource in order to determine the authentication data. If not, the gateway may not determine any authentication data.

[0080] It is also possible to grant access to the resource to any device T known to gateway T, but not to allow it for a new device. This prevents unauthorized devices or devices not belonging to the network's equipment from accessing the resource. family or business associated with the local LAN network may not be able to benefit from the proposed automatic authentication functionality.

[0081] The equipment T can then transmit a second m3 request to the server S on which the resource is available. This m3 request is addressed to the IP address sent by the m2 message from the DNS domain name server.

[0082] In response to this m3 request, the server S can respond with an authentication request m4.

[0083] Server S can detect that the resource R requested by equipment T and identified in request m3 is a secure resource. This detection can trigger an authentication request.

[0084] This authentication request may consist, in particular, - to check if the equipment (or its user) has the security data allowing access to the resource; - to verify that an account, or profile, associated with the user has sufficient rights to access the resource.

[0085] In both situations, the authentication request can, for example, take the form of a web page (i.e., in HTML format, which can encapsulate or refer to scripts) containing an input form for a pair consisting of a user identifier (or "login") and a password (or "password").

[0086] The authentication request rru is a response to the request m3 and is therefore intended for the equipment T from which this request was issued.

[0087] This could typically be a "200 OK" message according to the HTTP protocol, for example:

[0088] <form>

[0089] cinput login= / >

[0090] cinput password= / >

[0091] < / form>

[0092] The user is expected to fill in this form and return the entered data in a new message to the server S. In the proposed method, however, this authentication request can be intercepted and processed by the gateway P on behalf of the user.

[0093] Indeed, as we have seen previously, the authentication data has been previously stored (provisioned) in the gateway P in association with identifiers corresponding to the resources R.

[0094] Also, upon receiving the authentication request, in a step S2, the gateway P is able to provide this authentication data to the server S, in a message m5. It simply needs to search in memory for the association corresponding to the identifier corresponding to the resource R. This identifier is present in the different requests and the gateway P may have previously stored the correspondence between the identifier corresponding to the (logical) resource and its physical (IP) address present in the second request m3 and in the authentication request m4.

[0095] This m5 message can conform to prior art mechanisms, in particular it can be a POST request of the HTTP protocol (the difference being that it is issued by the gateway and not by the equipment). The server S receives the authentication data from the gateway P, but this message can be constructed as a response to the authentication request rru so that it is correctly interpreted by the server in the context of the dialogue with the equipment T.

[0096] Upon receipt of the identification data, as explained previously, the server can determine, in a way known per se, whether the authentication data provided allows access to the requested R resource or not.

[0097] If so, the server S transmits the requested resource in an m6 message.

[0098] In a step S3, the gateway P transmits the resource received from the server S to The T equipment, in a classic way in itself.

[0099] The rru message may also contain a certificate transmitted by the server S. This certificate, or "cookie" as it is commonly known in English, ensures that the device has been authenticated to the server: the device T can transmit this certificate for new requests to access other resources on the same site, for example, without having to authenticate again. This certificate may have a limited duration, after which the device must authenticate again.

[0100] Equipment T thus receives the requested resource without having to authenticate itself.

[0101] More specifically, it can be seen that the equipment T is not used during the authentication phase. Authentication is therefore transparent to the equipment T, which means that, on the one hand, the user has no action to perform, and on the other hand, it is not necessary to make any modifications or specific configurations to the equipment T. This can be a standard, state-of-the-art device, without any additional software modules.

[0102] As previously stated, if a user has several devices T, they can provision the associations within the gateway P and, automatically, Each of his devices will be able to access the resources without him having to perform any configuration operations on his devices.

[0103] If access to the resource is subject to a device identifier, for example to prevent access by unknown devices, then the authentication data is not automatically transmitted by the gateway. In such a situation, gateway P can retransmit the authentication request uq to device T. Device T must then authenticate itself using the prior art method.

[0104] It is also advantageous that the associations (and in particular the authentication data) can be stored locally in the gateway P.

[0105] This provides better security compared to storage on a remote platform such as the cloud. The latter presents an attractive target for a cyber attacker who, in a single attack, can obtain a large amount of authentication data. In contrast, the proposed method distributes authentication data across a large number of private devices, making a massive attack much more complex to carry out.

[0106] Furthermore, the proposed solution is more reassuring for users who keep sensitive data in their private homes. It is not always well received, in fact, to transfer sensitive data, such as authentication data, to a third-party platform, such as a "cloud".

[0107] Furthermore, since authentication data is no longer stored and provisioned on the equipment T itself, theft or hacking of this equipment (when the user is away, for example, with their mobile device) does not pose a risk to access to the resources R. This can be important for resources corresponding to sensitive sites (a banking site, for example). The probability of physical theft of a gateway P is much lower than that of a mobile phone.

[0108] Of course, the present invention is not limited to the examples and embodiment described and illustrated, but is defined by the claims. In particular, it is susceptible of numerous variations accessible to those skilled in the art.

Claims

Demands

1. A method for accessing a resource (R) accessible on a server (S) connected to a first telecommunications network (WAN) by a device (T) connected to a second telecommunications network (LAN) linked to said first telecommunications network by a gateway (P), wherein said gateway - determines (S1) authentication data for said resource; - provides (S2) authentication data to said server (S) upon receipt of an authentication request received from said server (S) and intended for said device; - transmits (S3) said resource received from said server (S) to said device (T).

2. A method according to claim 1, wherein said authentication data is determined from an identifier corresponding to said resource transmitted by said equipment during a first request.

3. Method according to the preceding claim in which said gateway (P) stores (SO) an association between identifiers corresponding, respectively, to a set of resources of which said resource R is a part, and said authentication data.

4. A method according to any one of the preceding claims, wherein said gateway subjects access to said resource to an identifier of said equipment (T).

5. A method according to the preceding claim and claim 3, wherein said association is further associated with at least one identifier of an authorized equipment, and wherein, upon receipt of a request to access said resource by said equipment, said gateway checks whether an identifier of said equipment is associated with said resource in order to determine said authentication data.

6. A method according to claim 3 or claim 5 wherein a user can provision said associations by means of an administration interface of said gateway (P).

7. Gateway for accessing a resource (R) accessible on a server (S) connected to a first telecommunications network (WAN) by equipment (T) connected to a second telecommunications network (LAN) linked to said first telecommunications network by said gateway (P), in which said gateway is adapted to: - determine (S1) authentication data for said resource; - provide (S2) authentication data to said server (S) upon receipt of an authentication request received from said server (S) and intended for said equipment; - transmit (S3) said resource received from said server (S) to said equipment (T).

8. Gateway according to the preceding claim, comprising a digital vault for storing said authentication data.

9. A computer program capable of being implemented on a gateway, the program comprising code instructions which, when executed by a processor, carries out the steps of the process defined in claims 1 to 6.

10. Data carrier on which at least one series of program code instructions for the execution of a method according to any one of claims 1 to 6 has been stored.

Images