IES20020438A2 - Content access system - Google Patents

Abstract

A system for controlling access by a client to content on a content server (such as a web server) is disclosed. The system comprises a portal server and an intermediation server. The client directs a request for content to the content server through the portal server. The portal server intercepts the request and determines whether access to the content is restricted. If it is restricted, the portal server to determine whether the client is authorised to access the content, authority to access the content being granted by the intermediation server. The portal server itself does not deal with grant of authorisation, receipt of payment, and so forth.

Description

The present invention relates to a computer method and system for mediating client access to resources over a communications network, more particularly, to a method and system that enforces a set of configurable authentication and authorisation controls before granting access rights to resources in a communication network.

The Internet is a worldwide system of computer networks - a network of networks - in which users at any one computer can, if they have permission, retrieve information from any other computer, and sometimes talk directly to users at other computers.

Originally conceived as a network that would allow users of a research computer at one university to be able to communicate with research computers at other universities, the Internet has evolved into a public, cooperative, and self-sustaining facility accessible to hundreds of millions of people worldwide. The interconnected computers exchange information using various services such as email and the World Wide Web (WWW). The latter service allows a server computer system (a Web Server) to send Web pages consisting of text and graphics information to a remote client computer system. The remote client computer can then display these pages typically Using a special purpose application, called a browser that manages the request for and display of web pages. Each resource on the WWW is uniquely identifiable using a Uniform Resource Locator (URL). To view a specific page the client computer specifies the URL for that page in a Hyper Text Transfer Protocol (HTTP) request.

The WWW is especially conducive to conducting electronic commerce. A multitude of Web servers have been developed through which vendors promote and sell a diverse set of products and services. A server computer system may provide an electronic version of a catalogue that lists items available for purchase. A potential purchaser may browse the catalogue and select items for purchase using a browser application. The items can include both physical goods (e.g. books) delivered though conventional distribution UNDER SECTION 28 AND RULE 23 / .1 channels and digital goods (e.g. music) delivered electronically to the purchaser. New technologies that are presently evolving, such as Internet-enabled mobile communication devices and digital television, further expand the significance of electronic and mobile commerce services. In these environments, goods and services can be bought by customers while travelling or while viewing a television programme.

In any situation where a purchaser and a vendor are remotely located to each other they may not already have knowledge of each other. Before the parties begin to trade electronically, a trust must be created between them.

At present, this can be achieved using an independent third party who possesses established credentials and is recognised and accepted by both trading entities as a trustworthy (the “intermediation model”). The trusted party operates a server computer system (an intermediation server) that provides a range of secure transaction services that include, for example, authentication and/or payment authorisation and clearing. The intermediation server is electronically invoked by the vendor’s server system during a purchase episode after the purchaser has selected the required items.

It is desirable to centralise all actions related to payment on the intermediation server. This enables modification and expansion of the transaction services without requiring any subsequent adaptation of applications executing on the vendor’s server system.

The intermediation server and vendor server systems must share some transactionspecific information to support authentication and payment decision processes. It is desirable that information shared be limited to the subset of the transaction information that is necessary for these services to be executed correctly. For example the intermediation server needs to be informed of the currency and amount of the item being purchased but privacy of client purchase details is maintained by not providing any descriptive information on the item(s) being purchased. Equally, the vendor’s server system does not need to possess client confidential information such as payment details, but instead accepts an approval or decline response from the intermediation server as proof of payment authorisation.

The applications managing the catalogue on vendor’s server system must be suitably adapted to invoke the intermediation server. This generally requires specialist knowledge on the part of the individual making the appropriate adaptations and specialist support from the service provider to ensure adaptations are operating correctly in all circumstances. Integration with applications executing on the vendor server system is undesirable as it introduces complexity and creates dependencies between applications in a heterogeneous computing environment and those executing on the intermediation server.

In an alternative model (the “portal model”), the need for adaptation of the catalogue application can be eliminated by using a portal executing on a central server, that moderates all exchanges between the purchaser, vendor and a payment intermediary. The portal application detects requests for chargeable items and automatically engages the appropriate authentication and payment transaction services. However, knowledge of the URL for the catalogue application may enable a client application to circumvent the portal and access the catalogue directly with consequential security exposure. Conventional methods for preventing direct access such as the use of an access control list on the vendor’s server system do not offer sufficient flexibility in design of the vendor’s site. A further drawback is that the portal model contains a single point of processing complexity that introduces the potential for a significant degradation in performance.

It is an aim of this invention to enhance the functionality and security of a vendor’s system, without a requirement to perform substantial adaptations to applications on the vendor’s system. Further, it is an aim of this invention to provide the benefits of both the intermediation and portal models while minimising their drawbacks.

Accordingly, from a first aspect, this invention provides a system for controlling access to content on a content server by a client, the system comprising a portal server and an intermediation server, wherein the client directs requests for content to the content server through the portal server; the portal server being operative to determine whether access to the content is restricted, and if it is, to determine whether the client is authorised to access the content, authority to access the content being granted by the intermediation server.

The system operates according to the centre based interaction scenario only when it’s necessary for the system to take a decision whether to grant access rights, switching to the peer-to-peer mode after that thus distributing the processing complexity across the system. The processing of authentication conditions of releasing the content is performed on the portal application side thus reducing the network overhead and eliminating the need for the content provider to implement any changes to their content. The content server only performs actions for which it was designed, namely content management. The delivery of the resource requested is controlled by the portal in such a way that the web server is not involved into any communications until the entitlement to access the requested piece of content is established.

The portal server preferably maintains a database that identifies content items to which access is restricted. The database typically includes, for each content item, one or more rules that specify the conditions under which access is authorised. Such rules may specify that access is authorised to specific clients, to specific individual users, on condition of payment being made, or in any combination of these or of other conditions.

Where there is no restriction in authority required to access the content (i.e., the content is freely available) typically the portal server automatically refers the request to the content server, and no invocation of the intermediation server takes place.

In the event that the portal server determines that the client does not have authorisation to access the content it does not allow the request to be processed by the content server. Preferably, in that event, it directs the client to access the intermediation server from which authorisation may be obtained.

The intermediation server may perform a range of actions to determine or establish the authority of the client to access the content, including but not limited to authentication of the identity of the client, authentication of the identity of the content provider and payment authorisation.

For example, authority may be granted by way of the intermediation server returning an access token to the client. The access token may include a payment authorisation code, a timestamp and the requested URL, typically contained in a contiguous sequence of bytes. This access token may include data that is subsequently incorporated into a URL 20438 tfxzs* that the client uses to access the content. In such embodiments, the portal server examines the URL to determine whether it contains a code that is valid for access to the requested content. Alternatively, the data from the token may be conveyed to the portal server by way of another suitable interface.

While the access token, in many embodiments, will be returned over a network connection, this is by no means the only way in which it can be returned. For example, it may be conveyed over any other suitable logical or physical channel, such as through an SMS message in the case of mobile telephony systems or as a printed code on a card (similar to those cards make available to subscribers to mobile telephony services) that might be sent to a user by post or bought at a retail outlet.

Note also that the operator of the content server can send (or cause to be sent) an access token to the client without involving the intermediation server. For example, these tokens might be promotional tokens that represent a certain amount of money that can be spent on accessing content on the provider’s site.

The system most typically comprises a data channel over which the client, the content server and the intermediation server can communicate. The channel typically includes a computer network link, such as the Internet. At least part of the data transmitted over the channel may be encrypted and/or digitally signed.

The intermediation server may be operative to conduct a dialogue with the client to determine its authorisation to access the content. The dialogue may be performed after the client has made a request to access the resource. For example, the dialogue may be initiated in response to the portal server denying access to the content. Alternatively, the dialogue may be made in advance of any attempt to access the content. In other words, the client obtains authorisation knowing that it will be needed to access content in due course. The dialogue may further include obtaining preference or option data from the client. For example, information relating to payment for content may be obtained from the client.

In typical embodiments, the content server includes a web server. However, it might equally be one of a large number of alternative types of server that are capable of delivering content in accordance with a request.

The invention further provides a portal server for use in an embodiment of the first aspect of the invention.

From a second aspect, this invention provides a portal application for execution on a portal server in a system embodying the first aspect of the invention.

More specifically, the invention typically provides a portal application operative: to receive from a client a request for access to content on a content server; to determine whether access to the content is restricted; and if access to the content is restricted, to determine whether the client is authorised to access the content, authority to access the content being granted by an intermediation server.

Typically, the portal application is a program or hardware device executing on a computer residing between a client and a content (web) server. It monitors requests made by the client and engages an intermediation server when requests for content at certain URLs are detected. It is important to distinguish between the concept of portal and proxy. Embodiments of the concept of proxy existing in known systems impersonate a client, thus creating security exposure of client’s payment details to all the vendors with which it deals, whereas the portal application only operates as a gateway that redirects the client to a authorisation and payment intermediary if necessary.

The portal application may provide a program for causing a computer system connected to a data network to act as a portal server. The portal application operates to: intercept a resource request message sent from a client application and intended for a server; query a local data store to retrieve any pricing rules and any other related access restrictions associated with the requested resource; determine from the query response if any pricing rules and/or access restrictions are defined; IE°^04ig send an authentication request message to an intermediation server in the event that any pricing rules and/or access restrictions apply; receive an authentication response message sent by the intermediation server indicating whether the client is approved to access the requested resource in the event that an intermediation server was invoked for authentication purposes; deliver the resource request to the server in the event that no access restrictions apply or the client is successfully authenticated.

It is preferable that the portal application provides means for minimising processing activity for frequently requested resources. Such means may involve caching of any pricing rules and related access restrictions associated with frequently requested URLs. When a URL is requested more than once, the determination of any constraints that may apply is made with reference to previously fetched information instead of requesting it from the stored source.

From a third aspect, the invention provides a portal server being a computer system executing a portal application being an embodiment of the second aspect of the invention.

Further, the invention provides an intermediation application for execution on an intermediation server to grant authority to access content in an embodiment of the preceding aspect of the invention.

The intermediation application is typically operative to receive a request for authorisation to access content from a client or from a portal application; return an authentication token to a client that can be passed by the client to a portal server in order to gain access to content on a content server.

The fifth aspect of the present invention further provides a program for causing a computer system connected to a data network to act as an intermediation server. The Intermediation Server operates to: 2043S receive an authentication request message sent from a vendor server system; query a local data store to retrieve vendor profile information; verify the source of the authentication request using retrieved vendor details; optionally obtain identifying details from the client; optionally query a local data store to retrieve client profile information associated with identifying details; optionally verify the identity of the client using retrieved client details; obtain client preferences for method of payment; form a payment authorisation request from price details and client profile 10 information; send payment authorisation request to external payment/billing system; receive authorisation response from external payment/billing system; and send an authentication response to the Portal Application.

It is preferable that the intermediation server provides means for minimising the 15 processing activity for verification of client identity. Such means may involve the use of a client cookie to retain client-identifying information thereby eliminating the need to a dialogue with the client in this regard.

From another aspect, the invention provides an intermediation server being a computer system executing an intermediation application being an embodiment of the preceding aspect of the invention.

Embodiments of the invention will now be described in detail, by way of example, and with reference to the accompanying drawings, in which: Figure 1 is a schematic representation of the architecture of an embodiment of the present invention; 820438 Figure 2 is a flowchart according to one embodiment of the present invention; and Figure 3 is a message sequence diagram according to one embodiment of the present invention.

With reference first to Figure 1, in a commercial transaction, a client 1 accesses content on a web server 3 that hosts content for a vendor’s web site.

The client 1 is an end user using a standard commercially available browser that can communicate with a remote server (such as a web server) using HTTP protocol or any other protocol capable of transferring requests for resources identified by URIs. (Alternative clients include, but are not limited to, WAP-enabled telephony devices, personal digital assistants, digital television devices and so forth.) The client browser application can receive a response to an earlier request and process the response according to the content type (e.g. HTML or MP3 for example) of the data returned. The browser supports identification items that are generated by the web server and returned to the browser. These items are stored locally and can be returned to the web server on request. The browser will return them only to the web server that supplied the items, and to no other server, in subsequent communication exchanges. These items are often referred to as “cookies”. They enable the web server to create a client session from multiple stateless or connectionless requests over a stateless proocol such as HTTP. Additional support for exchanging information between a client and a server is achieved using HTML GET and POST methods. These methods operate to allow a receiving server to automatically redirect a client request to another server and to include specific data items in the request header, which can be retrieved, by the second server.

A portal computer system 2 executes a portal application over a network link, such as the Internet. The portal application is a software component that monitors requests from multiple clients and engages a trusted server whenever a HTTP request is received for a URL that has pricing and/or access restrictions defined. The portal computer system 2 includes a portal application data store 6, being a file system, database or the like where pricing and any other access restrictions are stored. In addition, the portal application data store 7 provides a cache in which the portal application stores any pricing and access restrictions for frequently requested URLs.

The web server 3 is embodied in a standard commercially available HTTPD program (e.g. Netscape Enterprise Server, SUN iPlanet, Microsoft IIS or Apache) that delivers digital data in a variety of different content types in response to a client request. Supported content types include, but are not limited to HTML, WML, XML, MP3, MPEG and JPEG. The client 1 communicates with the web server 3 through the portal computer system 2. The web server includes a data store 5 that is a file system, database or the like where data is maintained that can be accessed by the client 1.

The portal application and the web server 3 may execute on the same computer system or they may execute on separate system connected by a network link.

The system further comprises an intermediation server 4 with which the client 1 can communicate. The intermediation server 4 also executes a standard commercially available HTTPD program that defines a common interface for range of value added secure transaction services. The intermediation server includes an intermediation server data store 8, being a file system, database or the like where provider profile information and optionally customer profile information can be stored.

A suitably competent individual responsible to the content provider (vendor) specifies in advance the resources, associated pricing rules and any other related access restrictions that are to be applied whenever the specified resource is requested by a client application. These are stored in the portal application data store 6.

The intermediation server 4 can provide services to multiple portal servers responsible for controlling access to content on various content servers operated by one or more content providers.

With reference to Figure 2, a transaction flow for the case where the client 1 requests a resource from web server 3 will now be described.

At step 21, the client 1 requests a page using the GET method from the web server 3, either by supplying a specific URL to the web browser or by following a hypertext link.

At step 22, the request is intercepted by portal application and the HTTP header is parsed to retrieve the URL. The portal application cache 7 is searched (step 23) to retrieve pricing and/or access constraint information associated with the requested URL.

If the cache 7 does not contain information for the requested URL then the local portal application data store 6 is searched to retrieve any constraints associated with the URL 24 (step 24).

To avoid the overhead of database retrievals in the event that a subsequent request is received for the URL in question at step 25, the local cache 7 is updated even if no pricing/access constraints exist.

At step 26, the constraints are examined and current price is calculated using the defined rules.

If no constraints apply, either because none are defined or current price is zero, the request is passed straight to the web server for execution (step 27) At step 28, the requested resource is delivered to the client 1.

If constraints apply (step 29), the POST parameters are examined to determine if a valid access token was supplied (the embedding of the access token in the POST parameters is described in detail below).

Step 30: If no token exists or an invalid token was supplied, an authentication request buffer is formed using relevant transaction data and inserted into the POST parameters of a HTML page that informs the client 1 the requested resource has access constraints and contains a hypertext link to the intermediation server 4. (The embedding of the authentication request buffer in the POST parameters is described in detail below.) When the customer follows the hypertext link, the client 1 sends an authentication request containing the authentication request buffer in POST parameters to the intermediation server 4 over a secure channel.

In step 31, the source and integrity of the authentication request buffer are verified by the intermediation server 4 using profile information 8 stored for the web server 3.

The identity of the customer is established in step32 by requesting input of an identity claim (e.g. a User ID) and verification information (e.g. a password) and comparing this with known values stored in profile information 8 for the client 1.

An authorisation cookie is set on the client 1 (step 33) to avoid the need for repeated input of identification and verification details. The cookie is set to expire within a configurable elapsed timeframe.

Step 34: In the event that profile information 8 for the client 1 contains multiple payment options, the customer is requested to select their preferred option.

A Payment Authorisation message is formed step 35 from the combination of details in the authentication request buffer and selected payment credentials maintained for the client 1 in the profile information 8. The choice of payment method determines the destination billing/payment system and the syntax and content of the authorisation message. If a “payment approved” response is received, a valid access token is formed and placed in the POST parameters of a HTML page that informs the customer access is granted and contains a hypertext link to the requested URL.

The authentication request buffer is formed by the portal application using selected transaction data. The requested URL, calculated price and currency are arranged into a contiguous sequence of bytes. This is followed by a hash of the composite data generated using any cryptographically secure one-way hash function, which is signed using the private key of the portal application, and optionally encrypted using the public key of the intermediation server to provide full non-repudiation using a cryptographically secure asymmetric algorithm.

The access token is formed by the intermediation server 4 in the event that a client is approved to access the requested resource. It comprises the payment authorisation code, a timestamp and the requested URL arranged in a contiguous sequence of bytes. This is followed in tum by a hash of the composite data generated using any cryptographically secure one-way hash function which is signed using the private key of the intermediation server and optionally encrypted using the public key of the portal application to provide full non-repudiation. ΙΕΰ?0438 Figure 3 represents a message semantic diagram for the above-described process.

It will be appreciated by the person of skill in the technical field that various modifications may be made to the above-described embodiment without departing from the scope of the present invention. The above embodiment is described with reference to retrieving data from a web server however the invention may also be applied to retrieving data from other types of network servers and systems including but not limited to Internet, intranet, WAP networks and the like accessible from mobile devices, digital television, semantic web.

The invention relates to methods and arrangements for accessing resources over a 10 communications network where access to said resources is managed by another component, independent of the client and the system(s) managing said resource, that ensures resources are accessed only in accordance to pricing and access policies defined by the said system(s).

The steps of a method embodying the invention can be summarised as follows: 1. A client requests digital or physical goods (generally, “content”)identifiable by means of a URL that points to a content server. 2. A portal application, independent of both the client and content server, intercepts the request. 3. A determination is made of the price or other access conditions applying to requested content for the said client with reference to a set of previously defined pricing rules. 4. An intermediation server, acting as a “trusted third-party” component, is contacted in the event that the requested resource is chargeable.

. The intermediation server accepts payment, or other authorisation, from the said client and issues an authorisation token to the client. 6. The client re-requests the content with the authorization token attached to the request. 7. The portal application validates the authorization token submitted by the client. 8. The client request is delivered to the server where the content resides. 9. The requested piece of digital content is released to the client.

Alternatively, embodiments of the method may comprise the following steps: 1. A client requests content identifiable by means of a URL. 2. A portal application independent of both the client and the content server intercepts said request. 3. The price or other access conditions applying to requested goods for the client is determined with reference to a set of previously defined pricing rules. 4. The portal application requests the authorization token from the client.

. The client obtains the said authorization token by means of any suitable physical or logical channel (such as a scratch-card, an SMS message etc.). 6. The client supplies the previously obtained authorisation token to the portal application either as a part of the request or by means of some interactive interface. 7. The portal application validates the authorization token submitted by the client. 8. The client request is delivered to the server where the said resource resides. 9. The requested piece of digital content is released to the client.

Embodiments of the invention ensure that non-valuable or free content is readily accessible by all clients without imposing load on the access control system, but valuable content that requires client authentication and payment before access is granted is secured. Moreover, embodiments of the invention operate in such a way that they does not create any unnecessary security exposure, ensuring that every component has only visibility of data relevant to its functioning. Although the portal application makes a decision about whether to releasing the requested content, it does not have access to customer’s payment details, such as an account or a credit card number etc. The intermediation Server, which performs the payment authentication, does not have access to chargeable resources on the merchant site. Finally, the web server only performs actions it was designed for, namely content management - there are no added processing overhead or scalability constraints.

Claims (10)

1. A system for controlling access to content on a content server by a client, the system comprising a portal server and an intermediation server, wherein the client directs requests for content to the content server through the portal server; the portal server being operative to determine whether access to the content is restricted, and if it is, to determine whether the client is authorised to access the content, authority to access the content being granted by the intermediation server.

2. A system according to claim 1 in which the portal server operates to maintain a database that identifies content items to which access is restricted.

3. A system according to claim 2 in which the database includes, for each content item, one or more rules that specify the conditions under which access is authorised.

4. A system according to claim 3 in which the rules specify that access is authorised only to specific clients, to specific individual users, on condition of payment being made, or any combination of these or of other conditions. 5. 29. An intermediation application operative to a, receive a request for authorisation to access content from a client or from a portal application; b. return an authentication token to a client that can be passed by the client to a portal server in order to gain access to content on a content server. 5 client has made a request to access the resource. 20. A system according to claim 19 in which the dialogue is initiated in response to the portal server denying access to the content. 21. A system according to claim 19 in which the dialogue is made in advance of any attempt to access the content. 10 22. A system according to any one of claims 18 to 21 in which the dialogue further includes obtaining preference or option data from the client. 23. A system according to claim 22 in which information relating to payment for content is obtained from the client. 24. A system according to any preceding claim in which the content server includes 15 a web server. 25. A portal application for execution on a portal server in a system according to any preceding claim. 26. A portal application operative: a. to receive from a client a request for access to content on a content 20 server; b. to determine whether access to the content is restricted; and c. if access to the content is restricted, to determine whether the client is authorised to access the content, authority to access the content being granted by an intermediation server. 27. A portal server being a computer system executing a portal application according to claim 25 or claim 26, 28. An intermediation application for execution on an intermediation server to grant authority to access content in a system according to any one of claims 1 to 24.

5. A system according to any preceding claim in which, when the portal server determines that there is no restriction in authority to access the content, the portal server automatically refers the request to the content server, and no invocation of the intermediation server takes place,

6. A system according to any preceding claim in which, in the event that the portal server determines that the client does not have authorisation to access the content, it does not allow the request to be processed by the content server.

7. A system according to any preceding claim in which, in the event that the portal server determines that the client does not have authorisation to access the content, it is operative to direct the client to access the intermediation server from which authorisation may be obtained.

8. A system according to any preceding claim in which the intermediation server can perform a range of actions to determine or establish the authority of the client to access the content, including but not limited to authentication of the identity of the client, authentication of the identity of the content provider and payment authorisation.

9. A system according to any preceding claim in which authority may be granted by way of the intermediation server returning an access token to the client. 10. A system according to claim 9 in which the access token includes data that is subsequently incorporated into a URL that the client uses to access the content. 11. A system according to claim 9 or claim 10 in which the access token includes a payment authorisation code, a timestamp and the requested URL. 12. A system according to claim 10 in which the portal server is operative to examine the URL to determine whether it contains a code that is valid for access to the requested content. 13. A system according to any one of claims 9 to 12 in which the access token is returned to the client over a network connection. 14. A system according to any one of claims 9 to 12 in which the access token is returned to the client through an SMS message or as a printed code. 15. A system according to any preceding claim that comprises a data channel over which the client, the web server and the intermediation server can communicate. 16. A system according to claim 15 in which the channel includes a computer network link, such as the Internet. 17. A system according to claim 15 or claim 16 in which at least part of the data transmitted over the channel is encrypted and/or digitally signed. 18. A system according to any preceding claim in which the intermediation server is operative to conduct a dialogue with the client to determine its authorisation to access the content. 19. A system according to claim 18 in which the dialogue is performed after the

10. 30. An intermediation server being a computer system executing an intermediation application being an embodiment of the preceding aspect of the invention.