In this document:
SCORM CROSS HOST SCRIPTING SOLUTION
Introduction
The SCORM API requires that the content use ECMAScript (a.k.a. JavaScript) to communicate with an API object provided by the LMS. This can of course a problem if the LMS and the content come from different servers, because of the "single origin" security rule that is strictly enforced by browsers to prevent cross-scripting exploits and vulnerabilities. This has been often been referred to as the "Cross-domain scripting" issue.
Figure 1 - Browser security blocks cross-scripting
Since the first version of SCORM was published, this has been a topic for much discussion and speculation. Many proposed solutions rely on somehow convincing a browser, through the use of a special Java applet or through Domain Name Service (DNS) manipulation, that there is a trust relationship between the LMS and the SCORM content. Most of those proposals have fallen victim to the increasingly restrictive defensive measures taken by browser developers to close vulnerabilities. Clearly, the solution does not lie in compromises at the client level or in weakening browser security. Because of the security issues, the solution must be manageable. It should also not require Java applets or special browser add-ons.
There is a straightforward solution to this problem, but it does not lie in the content or even in the LMS itself. The solution is in network infrastructure, using techniques that have proven to be both efficient and secure. Basically, the solution is what is called a reverse proxy.
What is a reverse proxy?
A reverse proxy appears to a client computer as an ordinary web server. Typically, a reverse proxy is used to provide access to one or more origin servers but make them look as the same server. A load balancer, for example, is a specialized reverse proxy that distributes client requests among a number of servers. Reverse proxies can also be used to distribute client requests for specific content paths to different specialized servers. For example, requests for http://xyz.com/foo/something might go to one server while those for http://xyz.com/bar/something might go to a different server.
Figure 2 - Reverse proxy.
Where SCORM is concerned, a reverse proxy allows the client web browser to see both the LMS and the content as coming from the same server. There is no browser cross-scripting issue and therefore no browser security issue.
Adding a remote repository to a LMS requires the intervention of the reverse proxy administrator, who is typically a network administrator rather than a LMS or content management administrator. Because LMS and content management administrators and users are typically insulated from network infrastructure and configuration management, this solution has usually not been on the radar screen of most LMS implementers and users struggling with cross-host scripting issues in SCORM.
Reverse proxies increase security
The word "proxy" is scary to a lot of people because some proxies allow all kinds of abuse. But it is important not to confuse a reverse proxy with a forward proxy. A forward proxy will, as its name indicates, usually forward any request anywhere. A reverse proxy, on the other hand, blocks anything that is not specifically allowed. An Apache based reverse proxy, for example, forwards only specific requests for virtual directories that are hard-wired into the reverse proxy configuration. Forwarding to an origin server that has not been specified is specifically forbidden in a typical reverse proxy configuration. Only the administrator of the reverse proxy can modify the configuration to add mappings to additional origin servers.
All traffic through a reverse proxy can be filtered and monitored. It is usually recorded in the proxy server logs, just like any other web server traffic.
The business case
There are a number of scenarios where having access to content from a repository that is different than the LMS server is required or desirable. For example, the US Department of Defense SCORM content registry provides a catalog of content that may reside in a number of different repositories. In many cases, that content cannot be moved or copied to the local repository of a LMS. It may be that the content vendor does not allow the content to be copied onto a server that is not under content vendor control. Or it may be that the content requires a particular back end server configuration and it is not practical or cost-effective to replicate that back end server in the LMS server.
The reverse proxy solution meets a number of business requirements, such as
- Allow the content provider to retain full control of the content. For example it is easy for a content provider to specify which clients can access the content by configuring their system to specifically allow only particular reverse proxy servers to access to the content.
- Provide a simple way for a content vendor to meter usage by an enterprise client by monitoring access to the content by the enterprise client's reverse proxy server.
- Allow an enterprise LMS to use both secure internal content repositories and external third party content repositories.
- Allow management, control and logging of access to specific content.
- Use off the shelf solutions.
Some typical configurations
Enterprise networks and learning management systems are configured in many different ways. We will look at two examples; there are many more possibilities of course. Figure 2 shows a typical use of a reverse proxy in a hosted LMS scenario. In this scenario, the LMS must allow access to some SCORM content that is served by third party content providers. Figure 3 shows the use of a reverse proxy in an enterprise setting where confidential learning content must be served from inside the firewall, while also making third party commercial content available to the users of the LMS.
Figure 3 - Hosted LMS and third party content repositories
Figure 4 - LMS using content from both inside and outside the enterprise firewall.
Proof of concept
Seeing is believing. A live, interactive demonstration of secure cross-domain scripting through the use of a reverse proxy can be found here (Clicking on link opens a new window).
References
Wilbert Kraan, "A feature or a bug; SCORM and cross domain scripting ", CETIS, 2003. Retrieved on 2006-06-05 from http://www.cetis.ac.uk/content/20030622203659 (Clicking on link opens new window)
Apache Documentation Team, "Apache Module mod_proxy", The Apache Software Foundation, 2005. Retrieved on 2006-05-21 from http://httpd.apache.org/docs/2.2/mod/mod_proxy.html (Clicking on link opens new window)
Ivan Ristic, "Web Security Appliance With Apache and mod_security", SecurityFocus, 2003. Retrieved on 2006-05-21 from http://www.securityfocus.com/infocus/1739 (Clicking on link opens new window)
Michael Mullins, "Implement a reverse proxy to secure corporate data", TechRepublic.com, 2005. Retrieved on 2006-06-05 from http://techrepublic.com.com/5100-1009_11-5572483.html (Clicking on link opens new window)
Claude Ostyn, "SCORM Cross Host Scripting Solution Using Apache 2.X", Ostyn Consulting, 2006. Retrieved on 2006-06-03 from http://www.ostyn.com/standardswork/xdomain/apache2x.htm (Clicking on link opens new window)
Claude Ostyn, "SCORM Remote Content Demo", Ostyn Consulting, 2006. Retrieved on 2006-06-03 from http://www.ostyn.com/standardswork/xdomain/remotecontentdemo.htm (Clicking on link opens new window)