A Web API brings with it a number of benefits to an organisation. However an organisation providing an API lacks the ability to monitor where and how its data is being used. One way to control this consists in specifying a set of Terms of Agreement. However this does not actually provide any guarantees nor a possibility to understand which client is violating such terms. In this paper we propose an approach to solve this problem in real-time and provide an application which can be controlled by the API organisation itself.

1 Introduction and Background

The Web has advanced towards an application development platform where organisations can opt to provide their data and services to third parties by creating and offering an API, whereas web developers, willing to create a mashup, combine data or functionalities from several APIs to create new innovative services.

APIs provide benefits to API holders and end users, in that:

i) API owners: allow reaching, promoting and selling the company’s content or functionality to other websites and therefore reaching a larger client base as it increases the number of users making use of its functionality.

(ii) Web developers can focus on making use of a service rather than developing a service. "The result is that instead of the Web being a collection of pages, it becomes a collection of capabilities, and a platform where thousands of programmers can create new services quickly and inexpensively."3

Therefore, APIs foster a win-win situation. Nevertheless organisations opening up public APIs may lead to a loss of data control. In fact the data and functionalities, which are provided by an organisation’s API, were previously exclusively used by the organisation itself, safe guarded and kept within the organisation’s boundaries.

Therefore API providers enlist a set of Terms of Agreement, which web developers are to follow. However at present these Terms of Agreement are listed merely for the sake of reference, the reason being that at present there exists no system which enforces API Terms of Agreement in real time. Therefore providing a means of enforcing these clauses would be of added value for the organisation.

Web applications which rely on data provided by Web APIs are called mashups. Essentially there exist two types of mashup implementations:

(i) either by generating a mashup on server-side of which flow of data is depicted in Figure 1.

Mashup server-

Mashup Application Code

Client’s BrowserAPI serverFigure 1

(ii) or by generating a mashup on client-side as depicted in Figure 2.

Client’s Browser

Mashup Application Code

API serverMashup server-

Mashup Application Code

Figure 2

Ideally a system which enforces API Terms of Agreement should be able to handle both kinds of mashups. This is further discussed in the aims and objectives.

2 Aims and Objectives

The principal objective of the system is to allow an API owner to control where and how API content is rendered. This is done by injecting javascript code into the client’s browser, whose task is to detect elements within the mashup web page which are desirable by the API owner. Therefore, the Terms of Agreement listed by API owners must be interpreted into a javascript application. Thus the system requires a means of injecting these scripts onto the client’s browser in a persistent manner.

The below lists the aims and objectives of a system capable of enforcing API Terms of Agreement as seen from an API owner’s point of view and the supplementary requirements which are essential to a system which must be robust, efficient and does not alter the current implementation strategies of mashups or APIs.

This enforcement system is able to enforce TOAs for mashups which are generated on the client side only. In this mashup framework, the mashup application replicated on the client’s browser requests data from the API server and not the mashup server.

The development and implementation of this enforcement system revolves around two key tasks, namely:

(i) the analysis of a mashup Web Page to detect breaches of API Terms and conditions

(ii) and a system which does not alter the current modus operandi.

For these to be true the following objectives had to be achieved:

An application which is transparent to all actors, that is a system which can be readily implemented without the need of going into extra costs of changing the existing setup in terms of coding by the API or the mashup.

Enforce TOAs in real-time

Ability to increase the selection of TOA enforcements over time

A system which requires a substantial amount of effort in order to be bypassed.

A scalable system which should not hinder the current efficiency in delivering API data to the client’s browser

Provides a user interface which allows API owners to register their APIs and provides the option to link different TOA enforcements to each API as he deems fit.

These requirements will facilitate the API owner in enforcing his TOAs and ease in binding the system to the current modus operandi of communication between APIs and mashups.

3. Design

The following describes the design of the application:

3.1 The Enforced TOAs

The TOAs enforced by the system, need to be implemented in javascript. The system handles the following TOA enforcements:

Disallow links which lead to malicious pages.

The system is able to detect such elements within the mashup web page by using an API provided by Google. This API gives access to a database which provides a list of URLs which are considered by Google’s indexing mechanism as malicious pages. These URLs are then compared to the ones embedded within the mashup webpage and therefore enables the enforcement system to determine if malicious links are presented to the client by the mashup webpage.

Disallow adverts which promote pornography or drugs:

The system detects such elements in real-time by using Delicious API as a source of information related to the content of advertisement. Delicious is a community driven web service which allows users to tag web sites with their appropriate use or content. Thus this TOA enforcement script detects advert links, which in turn queries the Delicious API for its content. The result of the tags returned by delicious would then allow the enforcement system to determine whether API data is to be sent.

Enforce the embedding of an organisation’s logo within the mashup Web Page:

The corporate data, product and brand can travel anywhere, gaining visibility in new places, therefore reaching a larger client base. This is only true if the Web Developer decides to do so. Therefore this script will be instructed to detect a specific image URL within the mashup’s Web page, which is specified by the API owner.

Enforce the embedding of a Hyperlink which links back to the organisation’s web page.

The enforcement system is specified with a URL, by the API owner, which must be located within the mashup web page. This script then uses the specified URL to detect its existence within the mashup web page.

3.2 The proxy & client-side component

Providing a means of detecting TOA breaches requires the use of an intermediary between the requests for API resources arising from the client’s browser and the related API. Therefore a proxy, together with a component embedded on the client side which the system is able to interact with, aids to determine what is being requested by the client. These components assist the enforcement system to decide which TOA enforcements should be taken care of. This leads to selecting the appropriate TOA enforcement script. The latter is then sent to the Security Manager component on the client side. The TOA enforcement script’s result is then evaluated by the proxy to determine if the client should be allowed to access API data. If the proxy establishes that the API resources are to be provided then it will connect to the relevant API server and request the API data on behalf of the client. This process is shown in figure 3.

Client’s Browser

Mashup Application Code

Mashup Application Code

PROXY

Filtering Rules

Mashup server-Security Manager

API Server

Figure 3

The system provides a user interface allowing API owners the possibility of choosing the TOA enforcements for specific functionality provided by the API. The selections are in turn used to instruct the proxy which TOAs will be enforced for a specific API request.

4 Implementation

In order to implement the functionality specified in the design, the application required the implementation of several components, mainly:

4.1 Proxy Creator

The ProxyCreator is a major component of the application which aids in the creation of a dedicated API proxy in real-time, thus allowing scalability. Once the proxy is created, it is immediately available and ready for use. Creating a dedicated proxy for each registered API, as shown in Figure 2, prevents the bottleneck of incoming API HTTP requests.

ProxyClient’s BrowserProxyProxyAPIAPIAPIFigure 44.2 Nonce

Nonce is a concept which plays an important role in a number of security implementations. A nonce is generally a random number which is issued for clients, were the server must ensure that no nonce is ever re-used. Therefore each number created would be generated only once.

A variation of nonce is used throughout the creation of the TOA Enforcement Files related to one specific API method. The system randomly picks a combination of TOAs and adds them up to create a TOA Enforcement File. The system will continue doing so until all the combination possibilities are exploited. The result will be a set of TOA Enforcement Files each of which will confirm a unique set of enforcements.

Moreover, all of the generated TOA Enforcement files are obfuscated to make it more difficult to interpret and determine the correct clear text. This obscures its purpose and logic to prevent tampering and deter reverse engineering.

Without the use of nonce, the application’s TOA enforcement script files selected by the API owner would be listed into a single Enforcement File. Therefore, without nonce, the application would always confirm the same set of TOAs thus increasing predictability.

4.3 One-Time-Password

To further improve the application’s robustness, upon every request to an API, the web developer must attach a key provided by the Security Manager to an API HTTP request. Therefore as the mashup is used by a client, upon each API request, a one-time-password is generated, which infact is already known by the application on server side. By making use of an OTP algorithm, each key for each API request is being discarded and cannot be reused. Therefore if the key on server-side is equal to the one received together with the API data request, this ensures that the Security Manager is actually running on the client-side

5 Results

Each developed component was tested on its own and subsequently followed tests to determine if the components still functioned correctly after being interfaced with each other. Finally acceptance testing was carried out to check if the system has met the specifications it was designed for and its overall performance. This was carried out by implementing mashups requesting different API data, namely:

New York Times Article Search API

Google Search API

YouTube Data API.

These mashups were edited in a way to breach the TOAs of the API whose data will be requested by the mashup.

These mashups were then deployed and accessed through a browser. The aim of this was to test the efficiency of the implemented system in the detection of TOAs breaches. As a result, each time the mashup did not adhere to the TOA being enforced by the system, the data requested to the APIs proxy resulted in a blank response.

Furthermore a test which addresses the added latency of the system was conducted. This consisted in comparing the time required to receive API data, directly from API, through the API’s dedicated proxy (no enforcement) and through the API’s dedicated proxy were the API was assigned a number of TOAs. The results of this test are shown in figure 5.

Figure 5

This test has shown a large variation between the enforcement system with and without TOA enforcements. The reason for such an increase in latency is caused by the script which detects malware. Reason being that the tables provided by the Google API are very large and searching for specific URLs in these tables is very time consuming. Therefore a second test was conducted. The malware enforcement was removed. The results obtained are shown in Figure 6.

Figure 6

The results obtained by the system show very little increase in times between the actual API and the client requesting data through the API. Therefore an improvement in the detection of malicious URLs would improve the overall system performance.

The results achieved by the system have concluded that it has successfully achieved the objective of enforcing the TOAs required by the API owner efficiently and in real-time.

6 Conclusion

The application has been successfully designed and implemented to enforce API Terms of Agreement. However this should be regarded only as the starting point for a system which could actually be the new way of securing API content. Further enhancements to this system would allow all organisations to market their APIs in the most efficient way possible. As discussed an organisation providing an API would be exploiting its key benefits, namely reach, relevance, new distribution channels, innovation and synergies.

Article name: Api Terms Of Agreement Enforcement System Computer Science essay, research paper, dissertation

Make Assignments Great Again

24/7 customer support: science/72144-api-terms-of-agreement-enforcement-system-computer.html