WO2012152813A1 - A method for authentication between a content delivery network service provider and a content owner - Google Patents

Abstract

A method for authentication between a Content Delivery Network service provider and a content owner The method comprises: a) establishing a TCP connection between an end point of a CDN service provider and an authentication server of the content owner: b) for content requested by an end user over said established TCP connection, the end point sending an authentication request to the authentication server of the content owner; c) receiving, the authentication server, the authentication request and performing an authentication thereof, for the end user; and d) sending, the authentication server, a response to the end point, through the TCP connection, indicating if the authentication request has been granted or not. The method further comprises maintaining the 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.

Description

A method for authentication between a Content Delivery Network service provider and a content owner

Field of the art

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.

Prior State of the Art

The terminology and definitions that might 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 access point to the Internet that houses servers, switches, routers and call aggregators. ISPs typically have multiple PoPs.

Content Delivery Network (CDN): This refers to a system of nodes (or computers) that contain copies of customer content that is stored and placed at various points in a network (or public Internet). When content is replicated at various points in the network, bandwidth is better utilized throughout the network and users have faster access times to content. This way, the origin server that holds the original copy of the content is not a bottleneck.

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 (or HTTP) Redirection: 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. For the purpose of the present invention, 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).

Bucket: 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.

Operating Business (OB): 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.

Content Distribution Internetworking (CDI): Content Distribution Internetworking is the ability to connect many independently administered CDNs to form a federation of CDNs. This allows a CDN to extend beyond its administrative domain to increase the reach of content.

Transport Control Protocol (TCP): 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.

Cnounce: 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.

For more than a decade now, people have conducted an increasing number of transactions on the web every month. They buy books and music online; they go online to buy flight tickets and concert tickets. Increasingly, they conduct most of the bank transactions and pay bills online. The explosive growth in e-commerce has meant that companies have had to scramble to offer consumers varying degree of authentication mechanisms so that our transactions can be conducted online with a high degree of confidence.

They have continued to spend increasing number of hours every week online. In the early part of this decade, they spent many hours online reading news and listening to music. By the middle of the decade, they relished the ability to view videos on YouTube [3] and share pictures online. Lately, their interests have evolved into spending time on social networks and viewing videos (YouTube [3] and Hulu [2] among others) and films online (from such services as Netflix [1]). As the demand for content increased, it created an opportunity for CDNs to distribute content and make better use of network resources by replicating content and placing a copy closer to the end user. Content generators increasingly look to protect their content and provide premium content to paying customers. As CDNs play an increasingly prominent role in content distribution for content owners and content generators, the burden of providing an authentication mechanism falls on the CDN service providers.

Content owners and content providers increasingly look for simple, scalable techniques to authenticate content for their end users. However, using a CDN for content distribution comes with its own challenges for authentication, authorization and accounting.

There are several authentication mechanisms in use today and they serve a variety of needs. This document is focused on the client-server model of authentication since the content providers would like to keep an accurate account of how many times a piece of content was viewed / downloaded for a variety of reasons: (1 ) to share money with content creators, (2) to account for amount of content consumed per user per day or per week or per month for billing or (3) to pay for access to an ISP.

Basic Authentication:

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.

Digest Authentication:

Just as in the case of Basic Authentication, 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.

Under client-certificate authentication, the client uses her X.509 certificate, a public key certificate that conforms to the X.509 Public Key Infrastructure [5] [8].

Under 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.

In Client-Server password based mutual authentication, 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.

All of the above authentication mechanisms are used between an end user and the content owner. Once the end user is authenticated, the content owner would still like to authenticate content at the CDN and have access to both authentication and accounting information. There are several possible ways to achieve this: (1 ) Authenticate content authentication between the end point and the origin server via basic and digest authentication; (2) Use of URL authentication and (3) Token based authentication.

Basic and Digest Authentication:

Here, 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].

URL Authentication:

When the content owner creates a content bucket, the authentication is defined to be URL. In addition, the format of the URL string is defined together with the name / IP address of the authentication server. Additionally, a cookie is defined as a parameter that will be used as part of the authentication. The URL-based authentication is now a three-step process.

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. In the first of the three steps, a URL authentication request is generated when an end point clicks on such content. In the second step, 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 ]. Once the authentication server approves the request, the end point sends the requested content to the end user. As a third and final step, once the end point 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.

Token Authentication:

Another authentication alternative (along the same lines as the URL authentication) is described in [1 1 ]. Here, an authentication token generated by a content owner is appended to the content URL. When an end user requests the content, the CDN service provider will check the validity of the token passed via 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 end point has to process each request twice, rejecting it once, and then accepting it. Additionally, both authentication mechanisms have the following issues:

1 ) 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.

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

- Both URL and Token Authentication mechanisms require a new connection to be set up with the authentication server for each request.

- If the browser connects to the end user using the unencrypted HTTP protocol, the cookie sent will be in cleartext and will be sniffable.

- The certificate-based authentication mechanisms, while secure, require the trust of 3rd parties (like CA). These authentication mechanisms are expensive since they require a delay of several round trips between end user and CDN end point.

- 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).

- All of the above authentication mechanisms require connections setup time for each user between the CDN service provider and the authentication server of the content owner. This makes any authentication mechanism discussed above not scalable, especially if the content is popular or if the content owner has a large number of end users (e.g. popular websites).

Description of the Invention

It is necessary to offer an alternative to the state of the art which covers the gaps found therein, particularly those related to the above cited required TCP connection setting up.

To that end, 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:

b) for content requested by an end user over said established TCP connection, the end point sending an authentication request to the authentication server of the content owner;

c) on receiving said authentication request, said authentication server performing an authentication of said end user request; and

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

On contrary to the known proposals, 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.

For an 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 webservice front-end, an authentication gateway and a backend database.

Next, and in different parts of the specification, 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

- said steps b) to d) through an already maintained open TCP connection, only once said content has been recognized as supporting said fast authentication.

According to an embodiment, the method of the invention comprises using buckets with associated meta-data to indicate said fast authentication support for said content.

Other embodiments of the method of the invention are described in appended claims, and in a subsequent section related to the detailed description of several embodiments.

Brief Description of the Drawings

The previous and other advantages and features will be more fully understood from the following detailed description of embodiments, with reference to the attached drawings, which must be considered in an illustrative and non-limiting manner, in which:

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. Detailed Description of Several Embodiments

Next, each component of a CDN service provider's sub-system is described. The infrastructure consists of Origin Servers, Trackers, End Points and Entry Point.

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.

When an end user makes a request for content, 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. Thus, 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. Next, 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.

We detail the interaction between the service provider's CDN and an authentication server at the content owner. Anyone skilled in this art may extend this invention to a group of authentication servers at the content owner.

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.

Firstly, according to Figures 1 and 2, the differences between what a typical implementation does today compared to the fast-authentication protocol described in this invention will be detailed. The differences between high-level interactions that occur between the CDN end points 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 CDN are similar in both Figures 1 and 2. With reference to Figure 1 , there it can be seen that all three end users, 1 , 2 and 3 connect to the end point 2 (EP-2) to view content from the same content owner. So, the content owner authenticates the content requests from all three users. The actions indicated by the shown labels, or numerical references, on Figure 1 are described next:

1. 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.

2. The end user is granted access to the website on verifying the credentials. The user is granted access to the website. As part of the authorization, 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.

3. 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.

4. For each request received from the end users, 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.

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

6. Once the request is authenticated, the response is sent to the CDN end point on the respective TCP connections. The connections are then closed.

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

There is no inherent mechanism for the CDN service provider to send status of each download for the end users to the content owner. At the end of the transfer, the CDN service provider can notify the content owner of the termination of the download. 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.

Figure 2 will be explained from label 4 onwards.

4. When the first end user (EU1 ) makes the request for content to the CDN, 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.

5. 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.

6. The response from the authentication server (an integer, 0 for success and 1 for failure) 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.

7. 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.

Support at the CDN bucket:

In order to support the fast authentication protocol at the CDN, a CDN customer must define the following information when defining a content bucket:

1. Declare in the content meta-data that the content in the bucket will require support for fast-authentication.

2. Server IP address and port number of an authentication server at the web service owner.

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.

Support at End Points (Content Servers):

The CDN end points have the following information for any end user they serve: 1 . IP address of the end user

2. A session ID generated by the end point for every end user it serves. This is useful in order to account information at the CDN.

3. The IP address and port number of the authentication server that the end point needs to connect to.

4. The end point implements all of the request messages defined below.

All communication between the end point and the Authentication server occurs over a TCP connection. So, the wire protocol defined to support fast-authentication uses TCP as a transport mechanism and is hence, reliable.

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.

Fast Authentication Wire Protocol:

The following request messages are defined:

(1 ) Begin Download (FA_BeginDownloadRequest). (2) End Download (FA_EndDownload)

(3) Progress Update Request (FA_ProgressUpdateRequest)

The following response messages are defined.

(1 ) Authorized (FA_AuthorizedResponse)

(2) Not Authorized (FA_NotAuthorizedResponse)

(3) Redirect (FA_RedirectResponse)

(4) End Stream (FA_EndStreamRequest)

(5) Abort (FA_AbortRequest)

Figure 4 shows the sequence diagram for an authentication request as received from an end user. The following steps describe the sequence diagram:

1. The end user requests resource with a URL of the form b87/films/A- Token/harrypotter.flv. Here 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.

2. 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.

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 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).

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

- If 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.

- Every piece of content has a startdate and enddate associated with it. 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.

4. The end point returns HTTP code 200 (OK, authorized) and sends the requested object to the end point (here, harrypotter.flv file).

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

6. As a final step, 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 effect of a successful authentication has been shown. If the authentication was to fail (for example, due to an unauthorized user using a URL from an authorized user), it will be seen an exchange of messages with reference to Figure 5:

1. 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).

2. 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.

3. 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.

4. 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:

- For premium users (who have no monthly limit), redirect the end users to a HD version of the content.

- If a piece of content is no longer available, offer the end users the choice of viewing other pieces of content.

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. 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.

In response, 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.

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

- Session ID of the end user - The offset at which the end user's stream must be stopped

- Size of payload

- A payload stream that is any multimedia content that must be sent to the end user on the content stream

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.

Subsequently, the end point closes the socket to the end user.

Figure 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.

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

Support from CDN Customers (Content Owners):

Next, a list of requirements stating what the CDN customer needs to do to support the fast-authentication wire protocol of the method of the invention will be given:

- Maintain at least one authentication server for the CDN service provider. This allows the end points to authenticate content requests.

- Any technique to build an authentication token for a piece of content. 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.

Support for the response messages FA_AuthorizedResponse, FA_NotAuthorized Response, FA_RedirectResponse, FA_EndStreamRequest, FA_AbortRequest.

- Appropriate policies / conditions for when the FA_RedirectResponse is sent. Similarly, define what HTTP error codes need to be sent for FA_NotAuthorized Response.

- Define policies for what content will be inserted for FA_EndStreamRequest message send to the CDN end points.

As see here, the CDN customers have maximum flexibility in defining and implementing policies for access to their content. 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.

Putting it together (as seen from an end point):

It must be noted that 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.

When an end point does a DNS lookup to connect to the authentication server, it gets a list of servers. It then issues a connect request on the servers one after another. If the connect does not succeed, the request for content fails. On the other hand, if the connect request succeeds (with any of the servers), a FA_BeginDownloadRequest message is sent to the authorization server.

If for any reason the connection to the authentication server fails, 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

a) Place an advertisement for a product or service

b) Inform the end user that they may have reached their daily / weekly / monthly or annual quota and pay or upgrade their account to get additional content,

c) As a graceful way to end the viewing of content.

- Prevent end users from accessing their content by passing around links to the content.

- Allows a content owner to define his or her own authentication token that may be based on: MD5 of the requested object, object version number, bucket ID in which the object resides, or any combination of the above.

Advantages of the invention:

The key advantages of the invention are:

- 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.

- A safe, reliable, secure way to offer AAA (Authentication, Authorization and

Accounting) to content owners while using a CDN service.

- The 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.

- Gives the CDN customers the flexibility to define what HTTP error code they would like to return to a requesting end user. So, the CDN service provider merely acts as a proxy for the HTTP code that is returned.

- Gives the CDN customers the flexibility to insert content to a content stream destined to an end point. This allows for the addition of content like advertisements, a request to update / renew subscription (depending on policies of the content owners). - The short message exchanged between a CDN end point and the content owner's authentication server is over a single connection. The requests (and responses) are pipelined. This results in no more than one RTT between CDN end point and authentication server for authentication for object access. This makes the solution scalable.

- Even if a CDN service provider has a number of end points, since each end point has only one connection to the authentication server, the solution scales with the number of end points.

A person skilled in the art could introduce changes and modifications in the embodiments described without departing from the scope of the invention as it is defined in the attached claims.

ACRONYMS AND ABBREVIATIONS

ADSL ASYMMETRIC DIGITAL SUBSCRIBER LINE

CDN CONTENT DISTRIBUTION NETWORK

DNS DOMAIN NAME SERVICE

POP POINT OF PRESENCE

TLD TOP LEVEL DOMAIN

FTP FILE TRANSFER PROTOCOL

HTTP HYPERTEXT TRANSFER PROTOCOL

MD5 MESSAGE-DIGEST ALGORITHM 5

URL UNIFORM RESOURCE LOCATOR

ISP INTERNET SERVICE PROVIDER

TTL TIME TO LIVE

OB OPERATING BUSINESS

CDI CONTENT DISTRIBUTION INTERNETWORKING

TCP TRANSPORT CONTROL PROTOCOL

PKI PUBLIC KEY INFRASTRUCTURE

SSL SECURE SOCKET LAYER

CA CERTIFICATE AUTHORITY

NONCE NUMBER USED ONCE

CNOUNCE CLIENT NUMBER USED ONCE

REFERENCES

[I] 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, "HTTP Authentication: Basic and Digest Access Authentication", 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, "HTTP State Management Mechanism." RFC 2109, RFC 2965.

[10] HTTP Cookie. At http://en.wikipedia.org/wiki/HTTP_cookie

[I I] 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)

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

Claims

Claims \ .- 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:

b) for content requested by an end user over said established TCP connection, the end point sending an authentication request to the authentication server of the content owner;

c) on receiving said authentication request, said authentication server performing an authentication of said end user request; and

d) returning, said authentication server, a response to said end point, through said TCP connection, indicating whether said authentication request has been granted or not;

wherein the method is characterised in that it comprises 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.

2. - A method as per claim 1 , wherein said subsequent authentication requests are performed for different end users, said steps b) to d) being performed for each of said subsequent authentication requests.

3. - A method as per claim 1 or 2, wherein said authentication server comprises an authentication backend at the content owner.

4. - A method as per claim 3, comprising said end point sending content download updates to said authentication server through said maintained open TCP connection.

5. - A method as per any of the previous claims, comprising the end point recognizing that a requested content supports fast authentication protocol 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.

6. - A method as per any of the previous claims, comprising the end point recognizing that content requested by an end user requires fast authentication and the end point performing said steps b) to d) through an already open TCP connection.

7. - A method as per claim 5 or 6, comprising using buckets with associated meta-data to indicate said fast authentication support for said content.

8. - A method as per claim 7, comprising using buckets with associated metadata also to indicate the IP address and port number of the authentication server.

9. - A method as per claim 7 or 8, comprising a content owner using the service provider's CDN creating said bucket, defining meta-data of said bucket or modifying meta-data of said bucket after uploading content to said bucket.

10. - A method as per claim 8 or 9, comprising performing the next steps:

- said end user gaining access to a web page of said content owner using an authentication mechanism that results in an authentication token generation at the content owner, the latter sending said authentication token to said end user;

- said end user requesting content by sending to an end point, a URL including file name, a bucket ID of a bucket supporting fast authentication, and said authentication token;

- said end point on receiving said URL, recognizing said bucket as supporting fast authentication, extracting the received token and building a Begin Download Request message with the received token together with a locally generated session ID and end user IP address, and sending said message to the authentication server of the content owner though said TCP connection, opening it if it wasn't already open; and

- the authentication server checking the validity of said message and the received token using a combination of end user IP address and the received token to authenticate the end user, and also using said end user IP address and session ID 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 point can identify the response, and an HTTP

OK code which must be returned to the end user by the end point; or

- a redirect response message containing a URL of the redirection as a payload in the message;

- if the token is not valid, the authentication server returns, through the TCP connection, a not authorized response together with the received session ID, so that the end point can identify the response, and an HTTP error code which must be returned to the end user by the end point;

- sending, the end point to the requesting end user:

- said HTTP OK code and the requested content, or - said URL of the redirection together with an HTTP code; or

- said HTTP error code;

and if said HTTP OK code has been sent:

- the end point closing the connection to the end user once the end point has finished sending the requested content thereto; and

- the end point sending to the authentication server, an End Download message together with end user IP, session ID and the number of bytes sent to the end user in the session, for the content owner to maintain accounting information for its customers.

1 1 . - A method as per claim 10, comprising sending the content as a stream, and:

- said end point periodically sending to the said authentication server, through the said TCP connection, a Progress Update Request message containing the session I D and the number of bytes sent to the end point in the last pre-determined time period, thus allowing the content owner to maintain up-to-date accounting of the amount of content accessed by an end user;

- the authentication server, returning in response to said Progress Update Request message:

- an Authorize Response message to the said end point containing the session ID of the end user sent in the Progress Update Request message, an authorization code if it authorizes the end user to continue receiving content of said stream; or

- an End Stream Request message, if the content owner desires to stop an end user from receiving the stream content any further due to policies implemented by the content owner where the said End Stream Response message including the session ID of the end user, an offset at which the end user's stream must be stopped, and a payload attached as a payload stream that must be sent to the end user;

and if said End Stream Request message has been sent:

- the end point on receiving said End Stream Request message, waiting until the end user reaches said offset and once reached, stopping the content stream and subsequently, transfers said payload stream to the end user; and .

- the end point closing the connection to the end user.

12. - A method as per claim 10 or 1 1 , comprising:

- the authentication server sending to the end point, an Abort Request message through said TCP connection; and - the end point closing the TCP connection to the authentication server and the connection to the end user once it has received said Abort Request message.