WO2012152813A1 - Procédé d'authentification entre un fournisseur de service de réseau de distribution de contenu et un propriétaire de contenu - Google Patents

Procédé d'authentification entre un fournisseur de service de réseau de distribution de contenu et un propriétaire de contenu Download PDF

Info

Publication number
WO2012152813A1
WO2012152813A1 PCT/EP2012/058507 EP2012058507W WO2012152813A1 WO 2012152813 A1 WO2012152813 A1 WO 2012152813A1 EP 2012058507 W EP2012058507 W EP 2012058507W WO 2012152813 A1 WO2012152813 A1 WO 2012152813A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
content
end user
end point
authentication server
Prior art date
Application number
PCT/EP2012/058507
Other languages
English (en)
Inventor
Parminder Chhabra
Armando Antonio GARCÍA MENDOZA
Pablo Rodriguez Rodriguez
Mattias Barthel
Original Assignee
Telefonica, S.A.
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 Telefonica, S.A. filed Critical Telefonica, S.A.
Priority to EP12722697.5A priority Critical patent/EP2708004A1/fr
Priority to BR112013028995A priority patent/BR112013028995A2/pt
Publication of WO2012152813A1 publication Critical patent/WO2012152813A1/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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Definitions

  • the present invention generally relates to a method for authentication between a Content Delivery Network service provider and a content owner that comprises opening a TCP connection between the content servers of the content delivery network service provider and the content owner to perform authentication requests, and more particularly to a method comprising keeping the said TCP connection open for performing subsequent connection authentication requests.
  • the invention is particularly applied to implement a fast authentication scheme for Web Services.
  • PoP A point-of-presence is an artificial demarcation or interface point between two communication entities. It is an access point to the Internet that houses servers, switches, routers and call aggregators. ISPs typically have multiple PoPs.
  • CDN Content Delivery Network
  • ISP DNS Resolver Residential users connect to an ISP. Any request to resolve an address is sent to a DNS resolver maintained by the ISP. The ISP DNS resolver will send the DNS request to one or more DNS servers within the ISP's administrative domain.
  • URL Simply put, Uniform Resource Locator (URL) is the address of a web page on the world-wide web. No two URLs are unique. If they are identical, they point to the same resource.
  • URL redirection is also known as URL forwarding.
  • a page may need redirection if (1 ) its domain name changed, (2) creating meaningful aliases for long or frequently changing URLs (3) spell errors from the user when typing a domain name (4) manipulating visitors etc.
  • a typical redirection service is one that redirects users to the desired content.
  • a redirection link can be used as a permanent address for content that frequently changes hosts (much like DNS).
  • a bucket is a logical container for a customer that holds the CDN customer's content.
  • a bucket either makes a link between origin server URL and CDN URL or it may contain the content itself (that is uploaded into the bucket at the entry point).
  • An end point will replicate files from the origin server to files in the bucket.
  • Each file in a bucket may be mapped to exactly one file in the origin server.
  • a bucket has several attributes associated with it - time from and time until the content is valid, geo- blocking of content, etc. Mechanisms are also in place to ensure that new versions of the content at the origin server get pushed to the bucket at the end points and old versions are removed.
  • a customer may have as many buckets as she wants.
  • a bucket is really a directory that contains content files.
  • a bucket may contain sub-directories and content files within each of those sub-directories.
  • Geo-location It is the identification of real-world geographic location of an Internet connected device.
  • the device may be a computer, mobile device or an appliance that allows for connection to the Internet for an end user.
  • the IP-address geo-location data can include information such as country, region, city, zip code, latitude / longitude of a user.
  • An OB is an arbitrary geographic area in which the service provider's CDN is installed. An OB may operate in more than one region. A region is an arbitrary geographic area and may represent a country, or part of a country or even a set of countries. An OB may consist of more than one region. An OB may be composed of one or more ISPs. Each region in an OB is composed of exactly one An OB has exactly one instance of Topology Server.
  • Partition ID It is a global mapping of IP address prefixes into integers. This is a one-to-one mapping. So, no two OBs can have the same PID in its domain.
  • Consistent Hashing This method provides hash-table functionality in such a way that adding or removing a slot does not significantly alter the mapping of keys to slots. Consistent hashing is a way of distributing requests among a large and changing population of web servers. The addition of removal of a web server does not significantly alter the load on the other servers.
  • Overlay Network An overlay network is a computer network that is built on top of another network. Nodes in an overlay network are connected by virtual / logical links. Each logical link may consist of a path that is made up of multiple physical links in the underlying network.
  • CDI Content Distribution Internetworking
  • Transport Control Protocol is one of the core protocols of the Internet Protocols. TCP is responsible of an ordered and reliable delivery of data stream between two network hosts.
  • Nonce It is a pseudo-random number generated in an authentication protocol to ensure that old communication cannot form the basis of replay attacks. Nounces are used in HTTP digest access authentication to calculate MD5 digest of the password. The nounces are different each time a 401-authentication challenge response is presented.
  • Each client request has a unique sequence number, making replay and dictionary attacks virtually impossible. This is used to create a 'session key' for authentication of subsequent requests and responses that is different for each authenticated session. This limits the amount of material with any one key [13].
  • Cookie A cookie refers to the state information that is passed between a server and a client. The state information is stored at the client. Cookies have several applications: remember information about the user who visited a website, session management, remembering the content of a shopping cart as a user navigates a website, personalizing preferences etc., among others.
  • Content owners and content providers increasingly look for simple, scalable techniques to authenticate content for their end users.
  • using a CDN for content distribution comes with its own challenges for authentication, authorization and accounting.
  • the web-server When a user makes a request for a protected content, the web-server returns an error HTTP 401 together with Authorization required. The web server also returns a dialog box requesting a username and password. Once the client returns the username and password, the server validates the credentials, and if successful, the server gives the client access to the protected content.
  • the username is appended with a colon and concatenated with the password.
  • the resulting string is encoded with the Base64 algorithm before transmission [6].
  • the Base64-encoding while unreadable to the naked eye, is easy to encode and decode. This makes the basic authentication mechanism a non secure one.
  • the Digest Authentication mechanism [7] is also based on the user providing username and password as an authentication mechanism. Digest authentication ensures that the password is encrypted by MD5 before it is transmitted, ensuring a secure encoding. However, not all browsers support digest authentication. Passing information via Cookies:
  • a cookie consists of one or more name-value pairs containing bits of information.
  • the cookie is sent as an HTTP header by a web server to an end user's web browser and then sent back unchanged by the browser each time it accesses that server.
  • a cookie may also be encrypted for security and to protect the privacy of end users [9] [10].
  • Cookies have been used since the inception of the browser for session tracking, personalizing services and session management. Cookies expire and are not sent to the server at the end of a session. An end user may also explicitly delete them. Using Certificates:
  • the certificate authentication is more secure than any basic form of authentication. It uses HTTP over SSL. There are several possible certificate authentication mechanisms: (1 ) Client-certificate authentication, (2) Client-Server certificate based mutual authentication and (3) Client-Server password based mutual authentication.
  • the client uses her X.509 certificate, a public key certificate that conforms to the X.509 Public Key Infrastructure [5] [8].
  • Client-Server mutual certificate authentication when a client requests access to a protected content at the server, the server responds with its certificate. The client then authenticates the server's certificate and if successful, sends its certificate to the server. The server verifies the client's credentials and if successful, grants the client access to protected content.
  • the authentication mechanism comprises the following steps: The server sends a certificate in response to access request to protected content at the server.
  • the client authenticates the server's certificate. If the server's credentials are successfully verified, the client sends its username and password to the server. Once the server verifies the client's credentials, the server grants the client access to protected content.
  • Other authentication techniques include Kerberos [12], opened [13]. However, not everyone provides such authentication mechanisms (Kerberos) or trusts other third parties to provide it for them, as in the case of openlD.
  • the content bucket may be defined as supporting either basic or digest authentication.
  • the content owner provides the appropriate username and password. So, when an end point gets a request for content that requires basic or digest authentication, the origin server behaves as a web server to authenticate the request.
  • the HTTP communication for the authentication occurs between the origin server and the end point that is chosen to serve the end user.
  • the end points returns the tuple ⁇ username:password> to the origin server with Base64 encoding or with MD5 encryption depending on whether the bucket supports Basic or Digest authentication [4] [6] [7].
  • the authentication is defined to be URL.
  • the format of the URL string is defined together with the name / IP address of the authentication server.
  • a cookie is defined as a parameter that will be used as part of the authentication.
  • a user may have logged into the content owner's site using any authentication mechanism the content owner chooses. As a consequence, a cookie at the end user is set.
  • a URL authentication request is generated when an end point clicks on such content.
  • the received request is first identified as needing URL authentication (as defined in the bucket meta-data).
  • the received URL is appended with the IP address and cookie value as received from the HTTP header of the end user and sent to the authentication server of the content owner [9] [10] [1 1 ].
  • the end point sends the requested content to the end user.
  • the connection is closed and the authentication server is notified of the number of bytes downloaded by the end user for billing.
  • the authentication is between the end point and the origin server alone. It requires two round-trip-times between the end point and origin server + TCP connection setup time.
  • the cookie sent will be in cleartext and will be sniffable.
  • Any authentication mechanism between the CDN service provider and an authentication gateway requires the setting up a TCP connection, performing the authentication and tearing down the TCP connection (or closing the socket).
  • the present invention relates to a method for authentication between a Content Delivery Network service provider and a content owner, comprising: a) establishing a TCP connection between an end point of said CDN service provider and an authentication server of said content owner:
  • the method of the invention comprises, in a characteristic manner, maintaining said established TCP connection open between the end point and the authentication server of the content owner and performing subsequent connection authentication requests through said maintained open TCP connection.
  • said subsequent authentication requests are performed for different end users, said steps b) to d) being performed for each of said subsequent authentication requests.
  • Said authentication server generally comprises a webservice front-end, an authentication gateway and a backend database.
  • the method of the invention will be denominated as a method for fast authentication, as it provides an authentication process which is faster compared to the prior art proposals.
  • the method of the invention comprising recognizing, the end point, that a requested content supports a fast authentication, and performing: - said steps a) to d) and said maintaining of the TCP connection, only once said content has been recognized as supporting said fast authentication; or
  • the method of the invention comprises using buckets with associated meta-data to indicate said fast authentication support for said content.
  • Figure 1 shows how content owners authenticate request to content when using a CDN according to a conventional authentication method
  • Figure 2 shows how content owners authenticate their requests using the method of the invention, for an embodiment
  • Figure 3 shows the contents of a bucket for content supporting the fast authentication provided by the method of the invention
  • Figure 4 shows the different steps of the method of the invention, performed in the form of messages interchanged between an end user, and end point and an authentication server, for an embodiment for which the requested authorization is granted;
  • Figure 5 shows the different steps of the method of the invention, for an embodiment for which the requested authorization is not granted
  • Figure 6 shows the sequence diagram of the steps of the method of the invention, for an embodiment providing a redirection for accessing the content requested;
  • Figure 7 shows another embodiment of the method of the invention, by a sequence diagram with the messages exchanged an between the end user, end point and authentication server, for progress updating requests; and Figure 8 shows the sequence diagram for an Abort Request message sent by the authentication server of the content owner to the end point, according to an embodiment of the method of the invention.
  • the infrastructure consists of Origin Servers, Trackers, End Points and Entry Point.
  • the Publishing Point Any CDN customer may interact with the CDN service provider's infrastructure solely via the publishing point (sometimes also referred to as the entry point for simplicity).
  • the publishing point runs a web services interface with users of registered accounts to create / delete and update buckets.
  • a CDN customer has two options for uploading content.
  • the customer can either upload files into the bucket or give URLs of the content files that reside at the CDN customer's website.
  • Once content is downloaded by the CDN infrastructure the files are moved to another directory for post-processing. The post-processing steps involve checking the files for consistency and any errors. Only then is the downloaded file moved to the origin server.
  • the origin server contains the master copy of the data.
  • End Point An end point is the entity that manages communication between end users and the CDN infrastructure. It is essentially a custom HTTP server.
  • Tracker The tracker is the key entity that enables intelligence and coordination of the CDN service provider's infrastructure. In order to do this, a tracker maintains (1 ) detailed information about content at each end point and (2) collects resource usage statistics periodically from each end point. It maintains information like number of outbound bytes, number of inbound bytes, number of active connections for each bucket, size of content being served etc.
  • the tracker uses the statistical information at its disposal to determine if (1 ) the content can be served to the requesting end user and if so, (2) determines the closest end point and one with the least load to serve an end user.
  • the tracker acts as a load-balancer for the CDN infrastructure.
  • Origin Server This is the server(s) in CDN service provider's infrastructure that contains the master copy of the data. Any end point that does not have a copy of the data can request it from the origin server. The CDN customer does not have access to the origin server. CDN service provider's infrastructure moves data from the publishing point to the origin server after performing sanity-checks on the downloaded data.
  • the architecture of a wire protocol for performing fast-authentication between a CDN service provider and a content owner is detailed with said protocol implementing the method of the invention for different embodiments.
  • the end users may access the content owner's web page via any authentication mechanism (e.g. username / password or certificate etc.) the content owner chooses to implement. Once the same end user wants to view the content owner's content file hosted by the service provider's CDN, the authentication server at the content owner must grant access to the protected content.
  • the protocol is flexible to accommodate any policies that the content owners may choose to implement for access to their content.
  • the authentication server may implement a web-service interface as a front- end. However, this in no way restricts the scope of the invention. In the rest of the document, the combination of web-service frontend (if any), authentication gateway and authentication backend (typically, a database) will be referred as the authentication server for simplicity.
  • This invention has the ability to handle a very large number of requests from end users because the end point that serves the content maintains an open TCP connection with the authentication server at the content owner and as a consequence, does not have not to open a new TCP connection for every end user content request.
  • the authentication server can do fine-grained control on how to deal with a request. It can redirect to other URLs (if the original URL is not available), inject payload (saying that the client has exceeded the duration for which the content was active, or for accounting). The authentication server can return a HTTP error code that must be returned to the requesting end user.
  • the end user requests content from a web site. This involves the end user engaging in an authentication mechanism to log into the website. This could be a combination of any one of user / password, certificate based authentication.
  • the end user is granted access to the website on verifying the credentials.
  • the user is granted access to the website.
  • the website sets a cookie at the end user's browser. This invention does not restrict the content owners from implementing any authentication mechanism to access their website they see fit.
  • a CDN service hosts the content for the content owner. So, the request for the content goes to the CDN.
  • the CDN identifies the end point that is best suited to serve content. As a result, the end point may get the content from the origin server at the CDN or the content owner (not shown in the figure for simplicity). The end user connects directly to end point 2 to get access to content.
  • the end point 2 opens a new TCP connection and makes an authentication request for the requested content.
  • the authentication mechanism may be either one of URL or Token authentication mechanism that uses the cookie set at the end user.
  • This communication may be either an API call [10] [1 1] or via HTTP.
  • the authentication server content owner receives the authentication request and authenticates each of the end users 1 , 2 and 3.
  • Figure 2 shows how the authentications mechanism proceeds in the fast- authentication protocol, i.e., according to the method of the invention. Since labels 1 -3 are similar to those already explained with reference to Figure 1 , their description will not be repeated.
  • the key differences with the conventional implementation of Figure 1 are: while for Figure 1 the bucket meta-data is configured to do URL or token authentication with appropriate meta-data configuration for either (format of URL and end user cookie or an authentication token as in [1 1]), the bucket for Figure 2 is configured to support fast-authentication and requires the IP address of the authentication server and port number.
  • end point 2 (EP-2) is chosen as best suited to serve the content.
  • the end point however recognizes the content as supporting fast-authentication. So, EP-2 opens a TCP connection to the authentication server of the content owner.
  • This TCP connection is kept open by EP-2. Subsequent connection authentication requests are sent on the same open TCP connection. This open TCP connection is also used by the end point EP-2 to send content download updates to the authentication server at the content owner.
  • the authentication server at the content owner authenticates the end user request. Once the content owner grants access, the end user is granted access to the content.
  • the response from the authentication server determines if access is granted to the end user. Communication for all end users receiving content from EP-2 is sent on the same open TCP connection.
  • EP-2 sends the requested content to the requesting end user(s) if the authentication succeeds.
  • the implementation of the fast-authentication protocol requires support in the CDN infrastructure and with the content owner. Next, a description of how the protocol may be supported and detailing the rules of execution of the protocol, both at the content owner and the CDN service provider, is given.
  • a CDN customer In order to support the fast authentication protocol at the CDN, a CDN customer must define the following information when defining a content bucket:
  • Figure 3 shows an example of the contents of a bucket including the above- mentioned information, for an authentication server that is listening on port 9100 for any authentication requests.
  • the CDN end points have the following information for any end user they serve: 1 . IP address of the end user
  • the end point implements all of the request messages defined below.
  • the communication occurs over very short messages.
  • the information about end users in points (1 )-(3) above may be used to identify the end users in the messages exchanged.
  • FIG. 4 shows the sequence diagram for an authentication request as received from an end user. The following steps describe the sequence diagram:
  • the end user requests resource with a URL of the form b87/films/A- Token/harrypotter.flv.
  • b87 is the bucket id.
  • the end point recognizes this bucket as supporting fast-authentication. So, the end point has an open connection with the authentication server and port number of the CDN customer (content owner).
  • the A- token is the authentication token that is generated by the content owner.
  • the end point extracts the authentication token, A-token, together with locally generated session ID and end user IP address, builds a FA_BeginDownloadRequest message and sends it to the authentication server.
  • the authentication server checks the validity of the A-token and uses the combination of end user IP and A-token to authenticate the end user.
  • the server also uses end user IP address and session ID to maintain accounting information of the end user. If the A-token is valid, the authentication server returns the authorization code (0 or 1 ) together with the session ID (that it received in the request) so that the end point can identify the response.
  • An HTTP code that must be returned to the end user is also returned (the communication with the authentication server need not be over HTTP).
  • the authentication server determines that the end user should not be allowed further access (because the end user has exceeded their quota), it returns a HTTP error code 403.
  • startdate indicates when the content becomes valid for delivery and enddate indicates the time beyond which the CDN may not serve the content. If the authentication server determines that the request for content is past the enddate (date and time when the content may be served), it may return HTTP error code 404.
  • the end point returns HTTP code 200 (OK, authorized) and sends the requested object to the end point (here, harrypotter.flv file).
  • the end point sends a FA_EndDownload message together with end user IP, session ID and the number of bytes sent to the end user in the session. This is important for the content owner to maintain accounting information for customers.
  • the end user requests resource with a URL of the form b87/films/A-
  • Token/harrypotter.flv. The end point recognizes this bucket as supporting fast- authentication. So, the end point has an open connection with the authentication server and port number of the CDN customer (content owner).
  • the end point extracts the token, A-token, together with locally generated session ID and end user IP address, builds a FA_BeginDownloadRequest message and sends it to the authentication server.
  • the authentication server checks the validity of the A-token and uses the combination of end user IP address and A-token to authenticate the end user.
  • the authentication server recognizes the request as coming from an unauthorized user.
  • the authentication server returns a not authorized response together with session ID of the request and an HTTP error code (In this example, HTTP 403) that needs to be sent back to the end user.
  • HTTP error code In this example, HTTP 403
  • the end point returns a HTTP 403 message to the end user as requested by the authentication server.
  • Figure 6 shows the sequence diagram to send a redirect request to the end user under the fast-authentication protocol. All steps until the FA_BeginDownloadRequest message is sent to the authentication server are the same as before.
  • the authentication server checks the validity of the A-token and uses the combination of end user IP and A-token to authenticate the end user.
  • the content owner can define policies to redirect authenticated end users to other (newer) versions of content. Some examples of such policies are:
  • the content owners are free to define policies as they see fit.
  • the content owner returns a FA_RedirectResponse message in case of a redirection.
  • This message contains a URL of the redirection as a payload in the message.
  • the end point On receiving a FA_RedirectResponse message, the end point generates a HTTP 302 message and sends the URL received (from the content owner) to the end user.
  • the fast authentication protocol in this invention supports authenticated access to content for end users. Some pieces of content may be several gigabytes in size. So, it is imperative that the CDN infrastructure informs the content owner of the progress of each download session. As shown in the embodiment of Figure 7, periodically, (every 60s for example) the end point sends a FA_ProgressUpdateRequest to the authentication server. This message contains the session ID and the number of bytes sent to the end point in the last 60s. This allows the content owner to maintain very up-to-date information on the amount of content accessed by an end user.
  • the authentication server sends an FA_AuthorizeResponse message to the end point.
  • This message contains the session ID of the end user sent in the FA_ProgressUpdateRequest.
  • a content owner may implement policies for content access. Examples of such policies are: Limiting an end user to view a fixed amount of content for free every day / week / month. Limiting an end user when the paid for monthly quota is reached.
  • the content owner desires to stop an end user from viewing the content any further due to policies implemented by the content owner, the content owner sends a FA_EndStreamRequest message. Rather than request the end point to abruptly end the stream, the authentication server sends the following information in the message:
  • a payload stream that is any multimedia content that must be sent to the end user on the content stream
  • the end point On receiving the FA_EndStreamRequest, the end point waits until the end user reaches the offset, and stops the content stream. Subsequently, the end point inserts the multimedia content received from the content owner and transfers it to the end user. This may be a pop-up or an advertisement telling the end user why their stream was stopped with a link to upgrade their account.
  • the end point closes the socket to the end user.
  • FIG 8 shows the sequence diagram for an embodiment of the invention, when a FA_AbortRequest is sent by the Authentication server of the content owner to the end point at the service provider's CDN.
  • the CDN end point closes the TCP connection to the authentication server in response to this request.
  • the authentication server may send such a request if (1 ) it detects that an end user continues to receive content though several attempts to close the connection via FA_EndStreamRequest have failed, (2) the authentication server needs to undergo maintenance and needs to shut all open connections.
  • This token may be created when an end user logs into a content owner's page. Ensure that when a piece of content is requested by an end user, the token is part of the URL request that is sent to the CDN service provider. - Support to process the request messages received from the CDN service provider.
  • the CDN service provider merely acts as a proxy for the content owners to return HTTP error response to the end users.
  • the CDN service provider merely aims to grant or deny access to a requesting end user in no more than one round trip time.
  • the first request at an end point that supports a fast- authentication bucket results in an open socket connection with the content owner's authentication server. Subsequent requests for content will be sent to the authentication server on the same open connection. It must be noted that multiple requests for authentication may be pipelined and sent to the server.
  • the end point will retry and connect to the authentication server.
  • Session IDs from different end points may be the same. However, the authentication server knows the IP address of each end point and together with session ID and end user IP address, can infer the number of concurrent streams opened by each end user.
  • Applications of the invention The invention described in this document has a large number of applications.
  • the method allows a content owner to add any multimedia content they desire (Audio, Video, Pop-up) to the end user's stream. This mechanism may be used to
  • the authentication is a wire protocol over an open TCP connection with the authentication server.
  • This mechanism prevents users from passing HTTP links around, forcing users to gain access to a service individually in order to view content.
  • AAA Authentication, Authorization and
  • CDN customers (content owners) have the flexibility to define their own authentication token.
  • the CDN customers also have the flexibility to define the IP address and port number of the web-service that will authenticate the requests received from the CDN end points.
  • the CDN customers have the flexibility to redirect the end users (who are their customers) to newer version of the content based on policies they choose to implement.
  • the CDN service provider merely acts as a proxy for the HTTP code that is returned.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention porte sur un procédé d'authentification entre un fournisseur de service de réseau de distribution de contenu et un propriétaire de contenu. Le procédé consiste à : a) établir une connexion TCP entre un point d'extrémité d'un fournisseur de service de réseau de distribution de contenu (CDN) et un serveur d'authentification du propriétaire de contenu ; b) pour un contenu demandé par un utilisateur final sur ladite connexion TCP établie, envoyer, par le point d'extrémité, une requête d'authentification au serveur d'authentification du propriétaire de contenu ; c) recevoir, par le serveur d'authentification, la requête d'authentification et réaliser une authentification de celle-ci, pour l'utilisateur final ; et d) envoyer, par le serveur d'authentification, une réponse au point d'extrémité, par l'intermédiaire de la connexion TCP, indiquant si la requête d'authentification a été ou non accordée. Le procédé consiste en outre à maintenir la connexion TCP établie ouverte entre le point d'extrémité et le serveur d'authentification du propriétaire de contenu et à réaliser des requêtes d'authentification de connexion ultérieures par l'intermédiaire de ladite connexion TCP ouverte maintenue.
PCT/EP2012/058507 2011-05-12 2012-05-09 Procédé d'authentification entre un fournisseur de service de réseau de distribution de contenu et un propriétaire de contenu WO2012152813A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP12722697.5A EP2708004A1 (fr) 2011-05-12 2012-05-09 Procédé d'authentification entre un fournisseur de service de réseau de distribution de contenu et un propriétaire de contenu
BR112013028995A BR112013028995A2 (pt) 2011-05-12 2012-05-09 método para autenticação entre um provedor de serviço de rede de liberação de conteúdo e um proprietário de conteúdo

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ESP201130759 2011-05-12
ES201130759A ES2401900B1 (es) 2011-05-12 2011-05-12 Método de autenticación entre un proveedor de servicios de red de distribución de contenido y un propietario de contenido

Publications (1)

Publication Number Publication Date
WO2012152813A1 true WO2012152813A1 (fr) 2012-11-15

Family

ID=46147423

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/058507 WO2012152813A1 (fr) 2011-05-12 2012-05-09 Procédé d'authentification entre un fournisseur de service de réseau de distribution de contenu et un propriétaire de contenu

Country Status (6)

Country Link
EP (1) EP2708004A1 (fr)
AR (1) AR086341A1 (fr)
BR (1) BR112013028995A2 (fr)
CL (1) CL2013003222A1 (fr)
ES (1) ES2401900B1 (fr)
WO (1) WO2012152813A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017155514A1 (fr) * 2016-03-08 2017-09-14 Hewlett Packard Enterprise Development Lp Action basée sur un indicateur de publicité dans un paquet de réseau
EP3253026A4 (fr) * 2015-07-31 2018-03-21 Huawei Technologies Co., Ltd. Procédé de contrôle d'accès basé sur un cdn et dispositif apparenté

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001077783A2 (fr) * 2000-04-07 2001-10-18 Movielink, Llc Systeme et procede de distribution de contenu sur un reseau
US20030097564A1 (en) * 2000-08-18 2003-05-22 Tewari Anoop Kailasnath Secure content delivery system
WO2005015919A2 (fr) * 2003-08-06 2005-02-17 Motorola, Inc. , A Corporation Of The State Of Delaware Methode et appareil pour permettre une authentification de fournisseur de contenu
US7552338B1 (en) * 2004-10-29 2009-06-23 Akamai Technologies, Inc. Dynamic multimedia fingerprinting system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8453229B2 (en) * 2006-06-14 2013-05-28 Anamorphic Systems, Inc. Push type communications system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001077783A2 (fr) * 2000-04-07 2001-10-18 Movielink, Llc Systeme et procede de distribution de contenu sur un reseau
US20030097564A1 (en) * 2000-08-18 2003-05-22 Tewari Anoop Kailasnath Secure content delivery system
WO2005015919A2 (fr) * 2003-08-06 2005-02-17 Motorola, Inc. , A Corporation Of The State Of Delaware Methode et appareil pour permettre une authentification de fournisseur de contenu
US7552338B1 (en) * 2004-10-29 2009-06-23 Akamai Technologies, Inc. Dynamic multimedia fingerprinting system

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
D. KRISTOL; L. MONTULLI: "HTTP State Management Mechanism", RFC 2109, RFC, pages 2965
FRANKS, J.; HALLAM-BAKER, P.; HOSTETLER, J.; LAWRENCE, S.; LEACH, P.; LUOTONEN, A.; L. STEWART: "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999 (1999-06-01)
KERBEROS (PROTOCOL, Retrieved from the Internet <URL:http://en.wikipedia.org/wiki/Kerberos_(protocol) OpenID. At http://en.wikipedia.org/wiki/OpenID>
OFTLAYER CONTENT DELIVERY AUTHENTICATION TOKEN AUTHENTICATION TOKEN, Retrieved from the Internet <URL:http://sldn.softlayer.com/wiki/index.php/SoftLayer_Network_ContentDelivery_Authentic ation>
RFC 2617 - HTTP AUTHENTICATION: BASIC AND DIGEST ACCESS AUTHENTICATION, Retrieved from the Internet <URL:http://tools.ietf.org/html/rfc2617>

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3253026A4 (fr) * 2015-07-31 2018-03-21 Huawei Technologies Co., Ltd. Procédé de contrôle d'accès basé sur un cdn et dispositif apparenté
US10693858B2 (en) 2015-07-31 2020-06-23 Huawei Technologies Co., Ltd. CDN-based access control method and related device
WO2017155514A1 (fr) * 2016-03-08 2017-09-14 Hewlett Packard Enterprise Development Lp Action basée sur un indicateur de publicité dans un paquet de réseau
US11546235B2 (en) 2016-03-08 2023-01-03 Hewlett Packard Enterprise Development Lp Action based on advertisement indicator in network packet

Also Published As

Publication number Publication date
ES2401900R1 (es) 2013-07-30
AR086341A1 (es) 2013-12-04
BR112013028995A2 (pt) 2017-02-07
CL2013003222A1 (es) 2014-08-01
EP2708004A1 (fr) 2014-03-19
ES2401900A2 (es) 2013-04-25
ES2401900B1 (es) 2014-03-05

Similar Documents

Publication Publication Date Title
TW578417B (en) Unique on-line provisioning of user terminals allowing user authentication
US9380028B2 (en) Proxy server operation
CN1656772B (zh) 用于相关流协议集合的保密参数关联
WO2008033552A2 (fr) Système et procédé de répartition et acheminement distribués de média
WO2003045036A2 (fr) Protocole de gestion des cles et systeme d&#39;authentification destines a l&#39;architecture de gestion des droits de protocole internet securise
CN109792433B (zh) 用于将设备应用绑定到网络服务的方法和装置
US20030217163A1 (en) Method and system for assessing a right of access to content for a user device
US9875371B2 (en) System and method related to DRM
US9553863B2 (en) Computer implemented method and system for an anonymous communication and computer program thereof
US20030059053A1 (en) Key management interface to multiple and simultaneous protocols
US20220337590A1 (en) Mitigating multiple authentications for a geo-distributed security service using an authentication cache
EP2708004A1 (fr) Procédé d&#39;authentification entre un fournisseur de service de réseau de distribution de contenu et un propriétaire de contenu
EP2605477A1 (fr) Fonctionnement de serveur proxy
Jeong et al. A study on the xml-based single sign-on system supporting mobile and ubiquitous service environments
EP2792119B1 (fr) Fonctionnement de serveur proxy
Sánchez et al. An access control system for multimedia content distribution
EP2605479A1 (fr) Validation de terminal de réseau
EP2605478A1 (fr) Redirection de récupération des données

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: 12722697

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2013003222

Country of ref document: CL

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2012722697

Country of ref document: EP

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112013028995

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112013028995

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20131111