ES2401900B1 - AUTHENTICATION METHOD BETWEEN A CONTENT DISTRIBUTION NETWORK SERVICE PROVIDER AND A CONTENT OWNER - Google Patents

Abstract

Authentication method between a content distribution network service provider and a content owner comprising: #a) establishing a TCP connection between an end node of a CDN service provider and a content owner authentication server; # b) for content requested by an end user through said established TCP connection, send the end node an authentication request to the content owner's authentication server; #c) receive, the authentication server, the authentication request and perform an authentication of it for the end user; and # d) send, the authentication server, a response to the end node, through the TCP connection, indicating whether or not the authentication request has been granted.

Description

AUTHENTICATION METHOD BETWEEN A CONTENT DISTRIBUTION NETWORK SERVICE PROVIDER AND A CONTENT OWNER

Field of technique

The present invention generally relates to an authentication method between a content distribution network service provider and a content owner comprising opening a TCP connection between the content servers of the content distribution network service provider. content and the content owner to make authentication requests, and more particularly, to a method comprising keeping said TCP connection open to make subsequent connection authentication requests.

The invention is applied, in particular, to implement a fast authentication scheme for web services.

STATE OF THE PRIOR ART The terminology and definitions that could be useful to understand the present invention are included.

PoP: A point of presence is an artificial demarcation or interface point between two communication entities. It is an Internet access point that hosts servers, switches, routers, and call aggregators. ISPs typically have multiple PoPs.

Content Distribution Network (CON): This refers to a system of nodes (or computers) that contain copies of client content that is stored and located at various points on a network (or public Internet). When content is replicated at various points on the network, bandwidth is best used across the network, and users have faster access times to content. This way, the original server that contains the original copy of the content does not experience bottlenecks.

ISP DNS resolution system: Residential users connect to an ISP. Any request to resolve an address is sent to a DNS resolution system maintained by the ISP. The ISP's DNS resolution system will send the DNS request to one or more DNS servers within the ISP's administrative domain.

URL: In layman's terms, the Uniform Resource Locator (URL, locator

resource uniform) is the address of a web page on the world-web. There are no two identical URLs. If they are identical, they point to the same resource.

URL Redirection (or HTTP): URL redirection is also known as URL forwarding. It may be necessary to redirect a page (1) if its domain name has changed, (2) if significant aliases are created for long URLs or they change frequently (3) if the user misspells a domain name by typing it (4) if visitors are manipulated, etc. For the purposes of the present invention, a typical redirect service is one that redirects users to the desired content. A redirect link can be used as a permanent address for content that changes frequently from host to host (almost like ONS).

Container: A container is a logical compartment for a client that contains the content of the CON client. A container either establishes a link between the URL of the original server and the URL of the CON or it can contain the content itself (which is loaded into the container at the entry point). An endpoint node will replicate files from the original server to files in the container. Each file in a container can be mapped exactly to a file on the original server. A container has various attributes associated with it - the time from and the time until the content is valid, content geoblocking, etc. Mechanisms are also used to ensure that new versions of the content are automatically transmitted on the original server to the container on the end nodes and old versions are removed.

A customer can have as many containers as they want. A container is actually a directory that contains content files. A container can contain subdirectories and content files within each of these subdirectories.

Geolocation: It is the identification of real geographic locations of a device connected to the Internet. The device may be a computer, mobile device, or device that allows an end user to connect to the Internet. The geolocation data of the IP address may include information such as a user's country, region, city, postal code, latitude, or longitude.

Business Unit (OB): An OB is an arbitrary geographic area in which the CNO service provider is installed. An OB can operate in more than one region. A region is an arbitrary geographic area and can represent a country, or part of a country, or even a set of countries. An OB can be made up of more than one region. An OB can be made up of one or more ISPs. An OB has exactly one topology server instance.

Partition ID: This is a global mapping of IP address prefixes to integers. This is a one-to-one correlation. Therefore, there are no two OBs with the same PID in their domain.

Consistent hash function application: This method provides the functionality of a hash table so 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. Adding or removing 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. The nodes in an overlay network are connected by 1 logical virtual links. Each logical link can consist of a path consisting of multiple physical links in the underlying network.

Content Distribution Network Interconnection (COl): Content distribution network interconnection is the ability to connect many independently managed NOCs to form a NOC federation. This allows a NOC to extend beyond its administrative domain to increase the reach of content.

Transport Control Protocol (TCP): The Transport Control Protocol is one of the main protocols of Internet protocols. TCP is responsible for the orderly and reliable delivery of continuous data flows between two network hosts.

Nance: It is a pseudorandom number generated in an authentication protocol to guarantee that an old communication cannot form the basis of replay attacks. The nance are used in HTTP digest access authentication to compute the MD5 digest of the password. The nances are different every time a 401 authentication challenge response is presented.

Cnance: Each client request has a unique sequence number, making replay and dictionary attacks virtually impossible. This is used to create a "session key". for request authentication and

subsequent responses which is different for each authenticated session. This limits the

quantity of material with any key [13].

Cookie: A cookie refers to the status information that is passed between a server and a client. Status information is stored on the client. Cookies have several applications: remembering information about the user who visited a website, session management, remembering the contents of a shopping cart while a user browses a website, customizing preferences, etc., among other things.

For more than a decade now, people have been making more and more transactions on the web per month. They buy books and music online; They go online to buy airline tickets and concert tickets. Increasingly, they carry out most of the bank transactions and pay bills online. The spectacular growth of electronic commerce has meant that companies have had to strive to offer consumers varying levels of authentication mechanisms so that our transactions can be carried out with a high degree of security.

They continue to dedicate an increasing number of hours each week to connecting online. At the beginning of this decade, they spent many hours online reading the news and listening to music. In the middle of the decade, they were excited by the possibility of watching videos on YouTube [3] and sharing photos online. Lately, her interests have evolved to spend time on social networks and watch videos (YouTube [3] and Hulu [2] among others) and online movies (from services such as Netflix [1]). As demand for content increased, an opportunity was created for NOCs to distribute content and make better use of network resources by replicating content and making a copy closer to the end user. Content generators increasingly sought to protect their content and provide premium content to paying customers. As CONs played an increasingly prominent role in content delivery for content owners and content generators, the burden of providing authentication mechanisms fell on CON service providers.

Content owners and content providers increasingly looked for simple and scalable techniques to authenticate content for their end users. However, using a CON for content distribution carries its own authentication, authorization and accounting challenges.

There are various authentication mechanisms in use today and they serve

for a variety of needs. This document focuses on the model of

client-server authentication, since content providers would like

keep an accurate count of how many times content has been viewed / downloaded

5

for a variety of reasons: (1) to share money with creators of

content, (2) to keep track of the amount of content consumed per user

daily or weekly or monthly for billing purposes, or (3) to pay for access

to an ISP.

1O

Basic authentication:

When a user makes a request for protected content, the server

web returns HTTP 401 error along with required authorization. The web server

also returns a dialog box requesting a username and a

password. Once the client returns the username and password, the

fifteen

server validates credentials and if successful the server gives the client access to the

protected content.

The username is attached with a colon and concatenated to the

password. The resulting string is encoded with the Base64 algorithm before the

transmission [6]. Base64 encoding, while unreadable to the naked eye, is easy to

twenty

encode and decode. This makes the basic authentication mechanism not

sure.

Authentication using summaries (digest):

As in the case of basic authentication, the

25

authentication by summaries [7] is also based on the user providing

a username and password as an authentication mechanism. The

summarization authentication ensures that the password is encrypted using MD5

before transmission, ensuring secure encryption. However, not all

Browsers support authentication through summaries.

30

Pass information through cookies:

A cookie consists of one or more name-value pairs that contain bits of

information. The cook is sent as an HTTP header by a web server to the

an end user's web browser and then it is sent back unchanged by the

browser every time you access that server. A cookie can also be encrypted for added security and to protect the privacy of end users [9] [1 0].

Cookies have been used since the beginning of the browser for session tracking, service customization and session management. Cookies expire and are not sent to the server at the end of a session. An end user can also explicitly delete them.

Use of certificates:

Certificate authentication is more secure than any basic form of authentication. Use HTTP over SSL. There are several possible certificate authentication mechanisms: (1) client certificate authentication,

(2) mutual authentication based on client-server certificates and (3) mutual authentication based on client-server password.

Under client certificate authentication, the client uses its X.509 certificate, a public key certificate that conforms to the X.509 public key infrastructure [5] [8].

Based on mutual client-server certificate authentication, when a client requests access to protected content on 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.

In client-server password-based mutual authentication, the authentication mechanism comprises the following steps: The server sends a certificate in response to a request to access protected content on the server. The client authenticates the server's certificate. If the server credentials are verified successfully, the client sends their username and password to the server. After the server has verified the client's credentials, the server grants the client access to the protected content.

Other authentication techniques include Kerberos [12], open [13]. However, not everyone provides such authentication mechanisms (Kerberos)

Or trust third parties to provide them on your behalf, as in the case of openiD.

All of the above authentication mechanisms are used between an end user and the content owner. Once the end user has authenticated, the content owner will still want to authenticate the content to the CON and have access to both authentication and accounting information. There are several possible ways to accomplish this: (1) authenticate content between the end node and the original server through basic authentication and through summaries; (2) use URL authentication and (3) witness-based authentication.

Basic and summary authentication:

In this case, the content container can be defined as supporting either basic authentication or summaries. The content owner provides the appropriate username and password. Thus, when an end node receives a content request that requires summarization or basic authentication, the original server behaves like a web server to authenticate the request. HTTP communication for authentication takes place between the original server and the end node that has been chosen to serve the end user. Endpoint nodes return tuple lt; username: passwordgt; (lt; username: passwordgt;) to the original server with Base64 encoding or MD5 encryption depending on whether the container supports basic or digest authentication

[4] [6] [7].

Authentication by URL:

When the content owner creates a content container, authentication is defined as a URL. Also, the format of the URL string is defined together with the name 1 IP address of the authentication server. Additionally, a cook is defined as a parameter that will be used as part of the authentication. URL-based authentication is currently a three-stage process.

A user may have registered on the content owner's site using any authentication mechanism chosen by the content owner. As a consequence, a cookery is set in the end user. In the first of three stages, a URL authentication request is generated when an end node clicks on such content. In the second stage, the received request is first identified as requiring authentication by URL (as defined in the container metadata). The received URL is attached with the IP address and cook value received from the end user's HTTP header and sent to the content owner's authentication server [9] [1 O] [11]. Once the request is approved by the authentication server, the end node sends the requested content to the end user. As a third and final step, once the end node has finished sending 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.

Witness authentication:

Another authentication alternative (along the same lines as URL authentication) is described in [11]. In this case, an authentication token generated by a content owner is attached to the content URL. When an end user requests the content, the CON service provider will check the validity of the token passed through an HTTP GET request to a remote web service.

Some problems have been detected with the existing proposals:

-

For basic authentication and digest authentication, an endpoint node must process each request twice, rejecting it once, and then accepting it. Additionally, both authentication mechanisms have the following problems:

1) Authentication is done between the end node and the original server only. It requires two round trips between the end node and the original server plus the TCP connection setup time.

2) The two mechanisms require additional support at the end nodes in order to notify the content owner about access to the content and for accounting purposes.

-

Both URL and token authentication mechanisms require establishing a new connection to the authentication server for each request.

-

If the browser connects to the end user using the unencrypted HTTP protocol, the submitted cookie will be in plain text and will be "husmeable".

-Certificate-based authentication mechanisms, although secure, require trust from third parties (such as CA). These authentication mechanisms are expensive since they require a delay of several round trips between the end user and the CON end node.

-

Any authentication mechanism between the CON service provider and

An authentication gateway requires establishing a TCP connection, performing authentication, and terminating the TCP connection (or closing the socket).

-

All of the above authentication mechanisms require connection establishment times for each user between the CON service provider and the content provider's authentication server. This means that none of the aforementioned authentication mechanisms can be scaled, especially if the content is popular or if the content owner has a large number of end users (for example popular websites).

Description of the Invention

It is necessary to offer an alternative to the state of the art, which covers the gaps found in it, in particular those related to the establishment of the required TCP connections indicated above.

To this end, the present invention relates to an authentication method between a content distribution network service provider and a content owner, comprising:

a) establishing a TCP connection between an end node of said CON service provider and an authentication server of said content owner;

b) for content requested by an end user through said established TCP connection, sending the end node an authentication request to the content owner's authentication server;

e) upon receiving said authentication request, said authentication server perform an authentication of said request made by an end user; and

d) return, said authentication server, a response to said end node, through said TCP connection, indicating whether said authentication request has been granted or not.

Unlike the known proposals, the method of the invention characteristically comprises keeping said established TCP connection open between the end node and the content owner's authentication server and making subsequent connection authentication requests through said TCP connection that is kept open.

In one embodiment, 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 front-end web service interface, an authentication gateway and a rear-end database.

Hereinafter, and in different parts of the specification, the method of the invention will be called the rapid authentication method, as it provides an authentication process that is faster compared to the prior art proposals.

The method of the invention comprises recognizing, the end node, that a requested content supports fast authentication, and performing:

-

said steps a) to d) and said maintenance of the TCP connection, only once it has been recognized that said content supports said fast authentication; or

-

said steps b) to d) through a TCP connection that is already kept open, only once it has been recognized that said content supports said fast authentication.

According to an embodiment, the method of the invention comprises using containers with associated metadata to indicate said fast authentication support for said content.

Other embodiments of the method of the invention are described in the appended claims, and in a later section relating to the detailed description of various embodiments.

Brief description of the drawings

The foregoing advantages and features, and others, will be more fully understood from the following detailed description of embodiments, with reference to the accompanying drawings, which are to be considered illustrative and not limiting, in which:

Figure 1 shows how content owners authenticate content requests when they use a CON according to a conventional authentication method;

Figure 2 shows how content owners authenticate their requests using the method of the invention, in one embodiment;

Figure 3 shows the contents of a container for content that

supports the fast authentication provided by the method of the invention;

Figure 4 shows the different stages of the method of the invention, performed in the form of messages exchanged between an end user, an end node and an authentication server, in an embodiment where the requested authorization is granted;

Figure 5 shows the different stages of the method of the invention, in an embodiment in which the requested authorization is not granted;

Figure 6 shows the sequence diagram of the steps of the method of the invention, in an embodiment that provides a redirect to access the requested content;

Figure 7 shows another embodiment of the method of the invention, using a sequential diagram with the messages exchanged between the end user, the end node and the authentication server, for progress update requests; and

Figure 8 shows the sequence diagram for an Abort Request message sent by the content owner's authentication server to the end node, according to an embodiment of the method of the invention.

Detailed description of various embodiments

The following describes each component of a CON service provider subsystem. The infrastructure consists of original servers, trackers, end nodes, and entry point.

Publishing point: Any CON client can interact with the infrastructure of the CON service provider only through the publishing point (also sometimes called the entry point for simplicity). The publishing point runs a web services interface with registered account users to create 1 delete and update containers.

A CON client has two options for uploading content. The customer can either upload files to the container or give the URLs of the content files residing on the customer's website CON. Once the CON infrastructure downloads the content, the files are moved to another directory for further processing. The post-processing stages involve checking the consistency of the files and whether there are any errors. Only then does the file move

downloaded to the original server. The original server contains the master copy of the

data.

End node: An end node is the entity that manages the communication between end users and the CON infrastructure. Essentially it is a custom HTTP server.

Tracker: The tracker is the key entity that enables the intelligence and coordination of the infrastructure of the NOC service provider. To do this, a crawler maintains (1) detailed information about the content on each end node and (2) periodically collects resource usage statistics from each end node. It maintains information such as the number of outgoing bytes, number of incoming bytes, number of active connections for each container, size of the content provided, etc.

When an end user makes a content request, the crawler uses the statistical information at its disposal to determine if (1) the content can be provided to the requesting end user and if so, (2) determine the nearest end node and one with the least burden to serve an end user. Thus, the tracker acts as a load balancer for the CON infrastructure.

Original server: This is the server (s) in the CON service provider infrastructure that contain the master copy of the data. Any end node that does not have a copy of the data can request it from the original server. The CON client does not have access to the original server. The CON service provider infrastructure moves the data from the publishing point to the original server after performing security checks on the downloaded data.

Next, the architecture of a free protocol, or protocol at the application level, is detailed to perform rapid authentication between a CON service provider and a content owner, said protocol implementing the method of the invention in different embodiments. End users can access the content owner's website through any authentication mechanisms (for example username 1 password or certificate, etc.) that the content owner decides to implement. When that same end user wants to view the content file of the content owner hosted by the CON of the service provider, the authentication server at the content owner must grant access to the protected content. The protocol is flexible to adapt to

any policy content owners choose to implement to access

to its content.

The authentication server can implement a front-end web service interface. However, this in no way limits the scope of the invention. In the rest of the document, the combination of the front web service interface (if any), the authentication gateway, and the back end of authentication (typically a database) will be referred to as an authentication server for simplicity.

The interaction between the NOC of the service provider and an authentication server in the content owner is detailed. Anyone skilled in this art can extend this invention to a group of authentication servers on the content owner.

This invention has the ability to handle a very large number of end-user requests since the content-providing end node maintains an open TCP connection to the authentication server at the content owner and, as a consequence, does not have to open a new TCP connection for each content request made by an end user. The authentication server can perform fine-grained control on how to handle a request. You can redirect it 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 purposes). The authentication server may return an HTTP error code that must be returned to the requesting end user.

First, according to Figures 1 and 2, the differences between what a typical implementation currently does compared to the fast authentication protocol described in this invention will be detailed. The differences between high-level interactions that occur between the CON end nodes and the authentication server at the content owner are also explained. The interactions between the end user and the content owner and the interactions between the end user and the CON are similar in both Figures 1 and 2.

Referring to Figure 1, it can be seen that the three end users 1, 2, and 3 connect to end node 2 (EP-2) to view content from the same content owner. Thus, the content owner authenticates the content requests of the three users. The actions indicated by the displayed labels, or numerical references, in figure 1 are described below:

1. The end user requests content from a website. This implies that the user

Finally start an authentication mechanism to register on the website. It could be a combination of any of the user / password based authentications, certificate.

2.

End user access is granted to the website after verifying credentials. User access to the website is granted. As part of the authorization, the website sets a cook in the end user's browser. This invention does not prevent content owners from implementing any authentication mechanism to access their website that they deem appropriate.

3.

A CON service hosts the content for the content owner. Thus, the content request goes to the CON. The CON identifies the most suitable end node to provide the content. As a result, the end node can fetch the content from the original server at the CON or the content owner (not shown in the figure for simplicity). The end user connects directly to end node 2 to gain access to the content.

Four.

For each request received from end users, end node 2 opens a new TCP connection and makes an authentication request for the requested content. The authentication mechanism can be either a URL or token authentication mechanism that uses the password set in the end user. This communication can either be an API [1 O] [11] call or via HTTP.

5.

The content owner's authentication server receives the authentication request and authenticates each of end users 1, 2, and 3.

6.

Once the request is authenticated, the response is sent to the CON end node over the respective TCP connections. Then the connections are closed.

7.

If the authentication requests are successful, the content is sent to the end user. On the other hand, if authentication is not granted, an error message generated by the end node is returned to the end user. Thus, the content owner has no control over the returned error message.

There is no inherent mechanism for the CON service provider to send the status of each download for end users to the content owner. At the end of the transfer, the CON service provider can notify the content owner that the download is complete.

Figure 2 shows how the authentication mechanism in the

fast authentication protocol, that is, 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 in figure 1 the container metadata is configured to perform authentication by URL or by token with a metadata setting appropriate for any of them (URL format and cookie end user or an authentication token as in [11]), the container in Figure 2 is configured to support fast authentication and requires the authentication server's IP address and port number.

Figure 2 will be described from label 4.

4. When the first end user (EU1) makes the content request to the CON, end node 2 (EP-2) is chosen as the most suitable to provide the content. The end node, however, recognizes that the content supports fast authentication. Thus, the EP-2 opens a TCP connection to the content owner's authentication server.

This TCP connection is kept open by the EP-2. Subsequent connection authentication requests are sent over the same open TCP connection. This open TCP connection is also used by the EP-2 end node to send content download updates to the authentication server at the content owner.

5.

The authentication server at the content owner authenticates the request made by an end user. Once the content owner grants access, the end user is granted access to the content.

6.

The response from the authentication server (an integer, O for success, and 1 for failure) determines whether access is granted to the end user. Communication for all end users receiving content from the EP-2 is sent over the same open TCP connection.

7.

EP-2 sends the requested content to the requesting end user (s) if the authentication is successful.

Implementation of the fast authentication protocol requires support on the CON infrastructure and with the content owner. The following provides a description of how the protocol can be supported and details the rules for

protocol execution, both in the content owner and in the provider of

CON service.

Support in the CON container:

5

In order for the CON to support the fast authentication protocol, a

CON client must define the following information when defining a content container:

1. Declare in the content metadata that the content in the container

will require support for fast authentication.

2. Server IP address and port number of an authentication server

1 O

in the web service owner.

Figure 3 shows an example of the contents of a container, including

the aforementioned information, for an authentication server that

it listens on port 9100 for any authentication requests.

fifteen

Support on end nodes (content servers):

CON end nodes have the following information for any

End user they serve.

1. IP address of the end user

2. A session ID generated by the endpoint node for each end user at

twenty

that gives service. This is useful for account information purposes at the CON.

3. The IP address and port number of the authentication server to which the

end node needs to connect.

4. The end node implements all the defined request messages

later.

25

All communication between the end node and the authentication server

It occurs through a TCP connection. Thus, the wire protocol, or protocol in

application level, defined to support fast authentication uses TCP as

transport mechanism and is therefore reliable.

Communication occurs through very short messages. Information

30

on end users in points (1) - (3) above can be used to identify

end users in exchanged messages.

Wire protocol, or protocol at the application level, for quick authentication:

The following request messages are defined:

(one)

Start Download (FA_BeginDownloadRequest).

(2)

Finish Download (FA_EndDownload).

(3)

Request to Update Progress (FA_ProgressUpdateRequest).

The following response messages are defined:

(one)

Authorized (FA_AuthorizedResponse)

(2)

Unauthorized (FA_NotAuthorizedResponse)

(3)

Redirect (FA_RedirectResponse)

(4)

End Continuous Flow (FA_EndStreamRequest).

(5)

Abort (FA_AbortRequest).

Figure 4 shows the sequence diagram of an authentication request received from an end user. The following stages describe the sequence diagram:

one.

The end user requests resources with a URL in the form b87 / films / A-Token / harrypotter.flv. In this case b87 is the container ID. The endpoint node recognizes that this container supports fast authentication. Thus, the end node has an open connection to the authentication server and the port number of the client CON (content owner). The A-token is the authentication token that the content owner generates.

2.

The endpoint node extracts the authentication token, A-token, along with the locally generated session ID and end-user IP address, constructs a FA_BeginDownloadRequest message, and sends it to the authentication server.

3.

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 the end user's IP address and session ID to maintain accounting information for the end user. If an A-token is valid, the authentication server returns the authorization code (O or 1) along with the session ID (which it received in the request) so that the end node can identify the response. An HTTP code is also returned and must be returned to the end user (communication with the authentication server does not have to be via HTTP).

This gives the content owner maximum control over the error codes that they want to return to end users. Some examples are:

-

If the authentication server determines that no further access should be allowed

returns to the end user (because the end user has exceeded their quota) an HTTP 403 error code.

-

Each content has a startdate (start date) and an enddate (end date) associated with it. Startdate indicates when the content begins to be valid for delivery and enddate indicates the moment from which the CON should not provide the content. If the authentication server determines that the content request is later than enddate (date and time the content can be delivered), it may return an HTTP 404 error code.

Four.

The end node returns the HTTP 200 code (OK, authorized) and sends the requested object to the end node (in this case the harrypotter.flv file).

5.

Once the end node has finished sending the requested object to the end user, it closes the connection to the end user.

6.

As a final stage, the end node sends a FA_EndDownload message along with the end user's 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 clients.

The effect of successful authentication has been shown. If authentication fails (for example, because an unauthorized user uses a URL from an authorized user), you will see a message exchange referring to Figure 5:

one.

The end user requests resources with a URL in the form b87 / films / A-Token / harrypotter.flv. The endpoint node recognizes that this container supports fast authentication. Thus, the end node has an open connection to the authentication server and the port number of the client CON (content owner).

2.

The endpoint node extracts the token, A-token, along with the locally generated session ID and end user IP address, constructs a FA_BeginDownloadRequest message, and sends it to the authentication server.

3.

The authentication server checks the validity of the A-token and uses the combination of the end user's IP address and A-token to authenticate the end user. The authentication server recognizes that the request comes from an unauthorized user. The authentication server returns an unauthorized response along with the request session ID and an HTTP error code (in this example, HTTP 403) that has to be sent back to the end user.

4. The end node returns an HTTP 403 message to the end user based on

requested the authentication server.

Figure 6 shows the sequence diagram for sending a redirect request to the end user according to the fast authentication protocol. All stages up to sending the FA_BeginDownloadRequest message 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:

-

For premium users (with no monthly limit), redirect end users to an HD version of the content. -If content is no longer available, offer end users the option to view other content.

Content owners are free to define policies they deem appropriate. The content owner returns a FA_RedirectResponse message in the event of a redirect. This message contains a redirect URL as a payload in the message. Upon receiving a FA_RedirectResponse message, the endpoint node generates an HTTP 302 message and sends the received URL (from the content owner) to the end user.

The fast authentication protocol of this invention supports authenticated access to content for end users. Some content can be several gigabytes in size. Thus, it is imperative that the CON infrastructure informs the content owner of the progress of each download session.

As shown in the embodiment of Figure 7, periodically (every 60 s for example) the end node sends FA_ProgressUpdateRequest to the authentication server. This message contains the session ID and the number of bytes sent to the end node in the last 60 s. This allows the content owner to keep highly updated information on the amount of content the end user has accessed.

In response, the authentication server sends a FA_AuthorizeResponse message to the endpoint node. This message contains the end user session ID sent in the FA_ProgressUpdateRequest.

A content owner can implement policies to access the

content. Examples of such policies are: Limiting an end user to view a fixed amount of content free of charge per day 1 week 1 month. Limit an end user when the monthly fee paid is reached.

If the content owner wants an end user to stop viewing content due to policies implemented by the content owner, the content owner sends a FA_EndStreamRequest message. Rather than asking the endpoint to end the stream abruptly, the authentication server sends the following information in the message:

-

End user session ID

-

The offset at which the user stream must stop

-

Payload size

-

A continuous payload stream that is any multimedia content that must be sent to the end user in the continuous stream of content

On receiving FA_EndStreamRequest, the end node waits until the end user reaches the lag, and stops the continuous flow of content. The end node then inserts the multimedia content received from the content provider and transfers it to the end user. It can be a pop-up or advertisement that tells the end user why their continuous flow has been stopped with a link to improve their account.

The end node then closes the connection, or TCP connection, with the end user.

Figure 8 shows the sequence diagram for an embodiment of the invention, when the content provider authentication server sends FA_AbortRequest to the end node in the NOC of the service provider. The CON end node closes the TCP connection to the authentication server in response to this request. The authentication server can send such a request if (1) it detects that an end user continues to receive content even though several attempts to close the connection using FA_EndStreamRequest have failed,

(2) the authentication server has to undergo maintenance and must close all open connections.

As a consequence of this request, the end node closes all open connections with end users who are downloading content. Such a request is due to an extreme situation. However, a subsequent content request on an endpoint for the same content owner will reopen the TCP connection to the authentication server. Subsequent content requests can reuse the same open TCP connection.

Support from CON clients (content owners):

The following is a list of requirements that indicate what the NOC client has to do to support the fast authentication wire protocol of the method of the invention:

-

Maintain at least one authentication server for the CON service provider. This allows the end nodes to authenticate requests for content.

-

Any technique to build an authentication token for content. This token can be created when an end user logs on to a content owner's page. Ensures that when an end user requests content, the token is part of the URL request that is sent to the CON service provider.

-

Support for processing request messages received from the CON service provider.

-

Support for FA_AuthorizedResponse, FA_NotAuthorizedResponse, FA_RedirectResponse, FA_EndStreamRequest, FA_AbortRequest response messages.

Policies / conditions appropriate for when FA_RedirectResponse is sent. Similarly, define what HTTP error codes have to be sent for FA_NotAuthorizedResponse.

-

Define policies for what content will be inserted for the FA_EndStreamRequest message sent to the endpoints of the CON.

As seen in this case, NOC clients have maximum flexibility to define and implement policies for access to their content. The CON service provider merely acts as a proxy for content owners to return an HTTP error response to end users. The CON service provider merely intends to grant or deny access to a requesting end user in a single round trip.

In summary (from the perspective of an end node):

It should be noted that the first request on an end node that supports

a fast authentication container results in an open TCP connection to the content owner's authentication server. Subsequent requests for content will be sent to the authentication server over the same open connection. It should be noted that multiple authentication requests can be piped and sent to the server.

When an endpoint performs a DNS query to connect to the authentication server, it gets a list of servers. It then issues a connection request to the servers one after another. If the connection is unsuccessful, the content request fails. On the other hand, if the connection request is successful (with any of the servers), a FA_BeginDownloadRequest message is sent to the authentication server.

If for any reason the connection to the authentication server fails, the end node will try again and connect to the authentication server.

The session IDs of different endpoints can be the same. However, the authentication server knows the IP address of each end node and, together with the session ID and end user IP address, it can infer the number of concurrent streams open 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 desired multimedia content (audio, video, pop-up) to the end user stream. This mechanism can be used to:

a) Place an advertisement for a product or service

b) Inform the end user that they may have reached their daily 1 weekly 1 monthly or annual quota and that they can pay or improve their account to obtain additional content.

e) As an elegant way to end the viewing of content.

-

Prevent end users from accessing your content by passing between them

links to content. -Allows a content owner to define their own authentication token that can be based on: MD5 of the requested object, version number of

object, container ID in which the object resides, or any combination of the

previous.

Advantages of the invention:

The main advantages of this invention are:

-

Authentication is a free protocol, or application-level protocol, over an open TCP connection to the authentication server.

-

This mechanism prevents users from passing HTTP links between them, forcing users to access a service individually to view content.

-

A safe, reliable and secure way to offer AAA (Authentícatíon, Authorízatíon and Accountíng, (authentication, authorization and accounting)) to content owners when they use a CON service.

-

CON clients (content owners) have the flexibility to define their own authentication token.

CON clients also have flexibility to define the IP address and port number of the web service that will authenticate requests received from the CON end nodes.

-

CON clients have the flexibility to redirect end users (who are their clients) to a newer version of the content based on policies they choose to implement.

-

Gives clients WITH flexibility to define what HTTP error code they want to return to a requesting end user. Thus, the CON service provider merely acts as a proxy for the returned HTTP code.

-

Gives customers WITH flexibility to insert content into a continuous stream of content intended for an end user. This allows you to add content such as advertisements, a request to update 1 renewal of a subscription (depending on the policies of content providers).

-The short message exchanged between a CON end node and the content owner's authentication server is over a single connection. Requests (and responses) are piped. This results in no more than one RTT between the CON end node and the authentication server for authentication for access to the object. This makes the solution scalable.

-

Even if a CON service provider has multiple end nodes,

since each end node only has one connection to the server

authentication, the solution scales to the number of end nodes.

Changes and modifications may be made by one skilled in the art to the described embodiments without departing from the scope of the invention as defined in the appended claims.

ACRONYMS AND ABBREVIATIONS

ADSL

ASYMMETRIC DIGITAL SUBSCRIBE UNE; line OF SUBSCRIBER

ASYMMETRIC DIGITAL

WITH

CONTENT DISTRIBUTION NETWORK; NET OF DISTRIBUTION OF

CONTENT

DNS

DOMA / N NAME SERVICE; DOMAIN NAMES SERVICE

POP

POINT OF PRESENCE; POINT OF PRESENCE

TLD

TOP LEVEL DOMA / N; UPPER LEVEL DOMAIN

FTP

FILE TRANSFER PROTOCOL; TRANSFER PROTOCOL OF

RECORDS

HTTP

HYPERTEXT TRANSFER PROTOCOL; PROTOCOL OF

HYPERTEXT TRANSFER

MD5

MESSAGE-DIGEST ALGORITHM 5; ALGORITHM OF SUMMARY OF THE

MESSAGE 5

Url

UNIFORM RESOURCE LOCATOR; LOCATOR UNIFORM OF

RESOURCES

ISP

INTERNET SERVICE PROVIDER; PROVIDER OF SERVICES OF

INTERNET

TTL

TIME TO UVE; TIME OF LIFE

OB

OPERATING BUSINESS; BUSINESS UNIT

Cabbage

CONTENT DISTRIBUTION INTERNETWORKING; INTERCONNECTION OF

CONTENT DISTRIBUTION NETWORKS

TCP

TRANSPORT CONTROL PROTOCOL; CONTROL PROTOCOL

TRANSPORT

PKI

PUBUC KEY INFRASTRUCTURE; INFRASTRUCTURE OF KEY

PUBLIC

SSL

SECURE SOCKET LAYER; LAYER OF SOCKETS INSURANCE

AC

CERTIFIES TE AUTHORITY; CERTIFICATION AUTHORITY

NONCE

NUMBER USED ONCE; NUMBER USED ONCE

CNONCE ACCOUNT NUMBER USED ONCE; CUSTOMER NUMBER USED ONCE

BIBLIOGRAPHY

[1] Netflix. At http://www.netflix.com

[2] Hulu. At http://www.hulu.com

[3] Youtube. At http://www.youtube.com

[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, quot; HTTP Authentication: Basic and Digest Access Authenticationquot ;, RFC 2617, June 1999.

[5] X.509. Available at http://en.wikipedia.org/wiki/X.509

[6] Basic Access Authentication. http://en.wikipedia.org/wiki/Basic_access_authentication

[7] Digest Access Authentication http://en.wikipedia.org/wiki/Digest_access_authentication

[8] Cryptographic Nounce. At http://en.wikipedia.org/wiki/Cryptographic_nonce

[9] D. Kristol, L. Montulli, quot; HTTP State Management Mechanism.quot; RFC 2109, RFC 2965. [1 O] HTTP Cookie. At http://en.wikipedia.org/wiki/HTTP _cookie

[11] SoftLayer Content Delivery Authentication Token Authentication Token, At http://sldn.softlayer.com/wiki/index.php/SoftLayer_Network_ContentDelivery_Authentic ation Token

[12] Kerberos (Protocol). At http://en.wikipedia.org/wiki/Kerberos_(protocol) OpeniD. At http://en.wikipedia.org/wiki/OpeniD

[13] RFC 2617-HTTP Authentication: Basic and Digest Access Authentication. At http://tools.ietf.org/html/rfc2617

Claims (11)

one.

2.

3.

Four.

5.

Authentication method between a content distribution network service provider and a content owner, comprising: a) establishing a TCP connection between an end node of said CON service provider and an authentication server of said content owner ; b) for content requested by an end user through said established TCP connection, sending the end node an authentication request to the content owner's authentication server; e) upon receiving said authentication request, said authentication server perform an authentication of said request made by an end user; and d) returning, said authentication server, a response to said end node, through said TCP connection, indicating whether said authentication request has been granted or not; the method being characterized in that it comprises keeping said established TCP connection open between the end node and the content owner's authentication server and making subsequent connection authentication requests through said TCP connection that is kept open. Method according to claim 1, wherein said subsequent authentication requests are made for different end users, said steps b) to d) being carried out for each of said subsequent authentication requests. The method of claim 1 or 2, wherein said authentication server comprises a back end of authentication on the content owner. Method according to claim 3, comprising sending said end node, content download updates to said authentication server through said TCP connection that is kept open. Method according to any of the preceding claims, comprising recognizing, the end node, that a requested content supports a fast authentication protocol and performing said steps a) to d) and said maintenance of the TCP connection, only once it has been recognized that said content supports such fast authentication. 6. Method according to any of the preceding claims, comprising recognize, the end node, that the content requested by an end user requires fast authentication and perform, the end node, said steps a) to d) through an already open TCP connection.

7.

Method according to claim 5 or 6, comprising using containers with associated metadata to indicate said fast authentication support for said content.

8.

Method according to claim 7, comprising using containers with associated metadata to indicate the IP address and port number of the authentication server.

9.

Method according to claim 7 or 8, comprising creating, a content owner using the CON of the service provider, said container defining metadata of said container or modifying metadata of said container after loading content into said container.

1O. Method according to claim 8 or 9, comprising performing the following steps: - obtaining, said end user, access to a web page of said content owner using an authentication mechanism that results in the generation of an authentication token in the content owner, the latter sending said authentication token to said end user; - request, said end user, content by sending to an end node a URL that includes file name, a container ID of a container that supports fast authentication, and said authentication token; -recognize, said end node, upon receiving said URL, said container as supporting fast authentication, extract the received token and construct a Download Start Request message with the received token along with a locally generated session ID and an IP address end user, and send said message to the content owner's authentication server through said TCP connection, opening it if it was not already open; and - checking, the authentication server, the validity of said message and the received token using a combination of the end user IP address and the received token to authenticate the end user, and also using said end user IP address and ID of session to maintain accounting information of the end user, and:

-

if the token is valid, the authentication server returns, through

the TCP connection:

-

an authorization response together with the received session ID, so that the end node can identify the response, and an HTTP OK code that the end node must return to the end user; or

-

a redirect response message that contains a redirect URL as a payload in the message;

-

if the token is invalid, the authentication server returns, via the TCP connection, an unauthorized response along with the received session ID, so that the end node can identify the response, and an error code HTTP that the end node must return to the end user; -send, the end node to the requesting end user:

-

said HTTP OK code and the requested content, or-said redirect URL along with an HTTP code; or -said HTTP error code;

and if said HTTP OK code has been sent: -close, the end node, the connection to the end user once the end node has finished sending the requested content to it; and -send, the end node, to the authentication server, a Finish Download message along with the end user IP, session ID, and the number of bytes sent to the end user in the session, for the content owner to keep accounting information for your clients. 11. Method according to claim 1 OR, comprising sending the content as a continuous flow, and: periodically sending said end node to said authentication server, through said TCP connection, a Request Update Progress message containing the session ID and the number of bytes sent to the end user in the last predetermined period of time, thus allowing the content owner to keep an updated accounting of the amount of content that an end user has accessed; -return, the authentication server, in response to said Progress Update Request message:

-a message Authorize reply to said containing end node

the end user session ID sent in the Update Request message

Progress, an authorization code if you authorize the end user to continue

receiving content from said stream; or

5

-a Request to End Continuous Flow message, if the owner of

content wants an end user to stop receiving streaming content

ongoing due to policies implemented by the content owner,

including said message Answer End Continuous Flow includes the ID of

end user session, a lag in which continuous flow must stop

10

from the end user, and an attached payload as a continuous stream of payload that

it must be sent to the end user;

and if the message Request to End Continuous Flow has been sent:

-wait, the end node when receiving said message Request Finish

Continuous Flow, until the end user reaches this gap and, once

fifteen

reached, stop the continuous flow of content, and then transfer

said continuous flow of payload to the end user; and

-close, the end node, the connection to the end user.

12.

Method according to claim 1 O or 11, comprising:

-send, the authentication server, to the end node, a Request message

twenty

Abort, through said TCP connection; and

-close, the end node, the TCP connection to the authentication server and the

connection to the end user once the request message has been received

Abort.