## 3 Literature Review
### Access Control and Cross Communication  
The first area of mashup research found in prior literature examines issues surrounding access control to mashup data and cross communication between backend resources. Mashups connect disparate applications and data resources to provide their services. This requires mashup applications to gain access to disparate data sources that have a variety of different sensitivity levels from RSS feeds (open access) to legacy systems (restricted access). This creates security risks for both mashup users, who have to give their credentials to mashup sites, and legacy systems managers, which must open their systems to external access. From a logistical and security perspective, the technical challenges involved in mashing legacy systems is much different than mashing multiple RSS feeds. As is the case of enterprise mashups, where the back-end resources being utilized by the mashup are legacy systems or databases, access control becomes a legitimate concern for several reasons [68]. First, it can be difficult to include back-end systems in the mashup because of the access control systems that they have in place. Often times the workaround is for the user to give the mashup their credentials and for the mashup to go on and \begin{table}
\begin{tabular}{c c c}
**Research Topic** & **Description** & **Related References** \\ \hline Access Control \& & & \\ Cross Communication & & & \\ \end{tabular}
\end{table} 
Table 1: Mashup Research Categories. impersonate the user. In situations where the legacy system or database is not designed to permit provisional mashup access, the mashup receives all access. If a malicious mashup was developed and gained access to a back-end system there would be great risk to the owners and other users of the back-end system. Similarly, if a legitimate mashup was developed by a user and included the user's credentials to one or many back-end systems and the mashup was compromised by a malicious attack, the user's credentials could be leaked to many different sources. This access control \"problem\" has been addressed by several publications and continues to receive attention [17-19, 68]. There are three primary mechanisms being used to provide access control for mashups. The first approach is referred to as a \"strawman\" approach, in which a series of access checks are made to authenticate the user and then the mashup application is provided the user's credentials to allow it to access the system (e.g. acts as the user when interacting with the application). Two examples of this approach are Authsub [69] and OAuth [70]. Authsub is Google's protocol web services. Authsub requires users of web applications to complete an \"access consent\" page which provides the user with an authentication token. This token allows the web application to interface with Google, acting as an agent for the user. OAuth [70] is an open authentication specification that provides consumer applications requesting restricted data with an \"unauthorized token\" that is converted to an \"authorized access token\" when the user successfully logs. Once the service provider receives the authorized token it redirects the user to the consumer application where the authorized token is exchanged for an access token that contains a password. One complexity of the OAuth [70] approach is that it requires that the service maintain the state for all previously issued tokens. There are a number of downfalls to \"strawman\" schemes for mashup delegation [68]. First, the mashup receives all of the user's privileges to the back-end system. Since the user cannot restrict the mashup's access within the back-end system, the user must completely trust the mashup. Additionally, a comprised mashup can leak user credentials, making the user, who is completely trusting the mashup, extremely vulnerable. One alternative to \"strawman\" approach is an approach that mimics real-life permit-based authorization schemes.