| Type | Title | Author |
|---|---|---|
| Forum topic | WebEx Connect Integration Availability | kreester |
| Notebook entry | Day One Dream Factory | chuckbrady |
| Notebook entry | how to animate a sprite | butcher |
| Type | Title | Author |
|---|---|---|
| Forum topic | WebEx Connect Integration Availability | kreester |
| Notebook entry | Day One Dream Factory | chuckbrady |
| Notebook entry | how to animate a sprite | butcher |
DreamFactory gives the end user or IT Department total control over the capabilities of the runtime virtual machine. The Security Policy can also be established at a central location and deployed across the enterprise network. The DreamFactory security architecture minimizes interaction with the client operating system and allows the safe deployment of advanced web services capabilities.
The DreamFactory security architecture is implemented on three different levels. At the lowest level, network security protocols for Kerberos Tickets, WS-Security, GXA-Security, and other security standards are usually just web service transactions that allow an end-user to authenticate themselves to a server. DreamFactory contributes to network security as a client by following the given security protocol for encrypting data or managing session tickets, etc. One level up, the DreamFactory project runs in much the same manner as a Java applet does in the browser. The DreamFactory virtual machine is carefully written to be a trusted container for potentially untrusted projects. Access to the client machine is limited, and DreamFactory prevents activities which could damage, corrupt or compromise the local computer. Projects run in private sandbox zones, preventing cross-project communication, and protecting user privacy. Lastly, DreamFactory project security provides a way for an author to protect a project from the end-user, but also regain access to the project when changes are needed. This includes the ability to password opening the project, unlocking the project file, and entering authoring mode where editing is allowed. This is an entire security level beyond and on top of the more familiar client-server and virtual machine security. The following three sections discuss DreamFactory's security architecture in more detail.
Network security is largely the domain of host servers and individual web service implementations. The desktop client's primary responsibility is to be a reliable transaction partner. A well implemented Service-Oriented Architecture will establish proper protocols and procedures for single sign-on, session management, and data integrity. DreamFactory supports Secure Sockets Layer transactions, MD5 Encryption, Base64 compression, and other technologies necessary to implement web service security protocols at the client. The DreamFactory virtual machine and website have deep support for HTTPS SSL encrypted transactions. Our website is certified as a Verisign Secure Site, and all resources, controls, and projects can be accessed with the HTTPS as well as the HTTP communication protocol. The DreamFactory runtime engine can also perform encrypted web service transactions over SSL, to do this simply use URL's with the HTTPS prefix.
The following section discusses the stability of the DreamFactory virtual machine, the protection of user privacy, the protection of the client computer, and the scripting commands and functions to implement various security permissions.
The DreamFactory virtual machine has been carefully written to prevent buffer overflow exploits, crashing through purposeful or inadvertent programming errors, or any other behavior that could corrupt or otherwise damage the client machine. In the area of buffer overflows, DreamFactory uses an innovative memory management system for the debugging version of the product that carefully monitors over-runs, under-runs, and memory leaks. A single error will break into the debugger and identify the offending line and file during testing. This abstraction layer is replaced by standard system memory calls in the release version for speed. Automated testing procedures have been developed to send partially correct and/or very large arguments to all commands and functions in a random manner to probe for buffer overrun exploits.
The DreamFactory portability layer has been in active use for over 10 years and has been tested extensively under demanding circumstances. On top of that foundation, DreamFactory implements native handlers for file management, memory management, Internet access, XML parsing, and other major software subsystems. This approach minimizes interaction with different operating systems and other installed applications that reside on the client. DreamFactory does not require any external libraries on either Windows or Macintosh. All of the user interfaces implemented by DreamFactory are completely synthetic graphical mockups of the real thing. This completely stops the interception of windows messages and prevents malicious programs from examining system data structures to exploit the environment. In effect the visible area of the DreamFactory application is a graphical illusion, allowing arbitrary user interface manipulation, total consistency of sizing and placement across platforms, and complete security. The DreamFactory documents themselves are complex and highly compressed binary formats that are resistant to tampering and inspection. Every internal object data structure is verified for consistency and format before use or execution in the virtual machine.
Downloaded projects are stored in a hierarchical structure of folders that mirrors the web layout of the originating host. Projects normally access files only in their private sandbox unless this is specifically disabled by the client security policy (Section 3.3). Projects that desire to share data can store files in public areas for other projects from the same host if desired. Sharing data or enforcing privacy mirrors the directory structure of the original server that the projects came from. Shared projects from the same domain can open each other unless this has been prevented with the project privacy setting discussed in the final section of this document (Section 4.0).
All sensitive data in the project is obscured from file readers, but this is not a foolproof way to protect information; sensitive data should be used in a transient manner and not stored in project files. This situation is similar to any open format like HTML or browser cookies. There are also limits on personal or system information available to the project. The scripting language itself limits system information to very basic data needed for memory management, speed estimation, machine capabilities, etc. Registry access can provide additional information, but by default this is constrained to the security sandbox. The default sandbox registry gives each project a limited and separate area for persistent storage.
At no time is information sent from our desktop client application to DreamFactory Software, Inc. Our server is a passive source of read-only installation packages and example projects for download. The Developer Forum and download registration page on our website are used solely for tracking product downloads, building customer relationships, and providing technical support. This information will never be transferred to a third party or become linked to any database external to DreamFactory Software, Inc.
DreamFactory implements an easy to use but very powerful sandbox security system that can be controlled by the end user or administered by a single policy distributed across the enterprise. The sandbox is similar in concept to the .Net or Java 2 security systems where individual capabilities can be granted or denied to projects running on the local machine or downloaded from a particular location on the Internet. This allows the distinction of projects based on their origin into various security zones. The DreamFactory client install creates a "downloads" folder (C:\Program Files\DreamFactory\downloads) that is the security sandbox. Domain sandbox folders and sub-folders are created in this location. DreamFactory provides a scripting command dialogpolicy() that brings up the security policy dialog, below. The radio buttons at left allow you to view the policy of the different security zones. These are similar to the zones in Microsoft Internet Explorer. The "Stand-Alone Project" zone is for all projects running outside the "downloads" folder. The next four radio buttons correspond to web sites that are the originating host for various projects. The names in the list are matched by the folders in the "downloads" area. If a site name does NOT appear in one of the zones then that site is covered by the security policy for the last option "All Other Internet." The "Add Site" and "Delete" buttons at lower right can be used to add or delete sites from the various zones.
The "Lock..." button will create a password for access to this dialog. This locks the security policy file "policy.dfsp" in the "DreamFactory" folder from unauthorized access. The security policy file can be included as part of the DreamFactory installation, see the DreamFactory Enterprise Installation Guide for details. This file can also be hidden, or encrypted with NTFS so that it cannot be thrown away by the local user. If the file is deleted, DreamFactory will create a new default security policy file upon launch, and that policy file can be edited as normal. This behavior is similar to the "java.policy" file that describes permissions for the Java 2 security environment. Under "Zone Policy" the "Edit..." button will bring up the security permissions dialog below:
This dialog allows granular policies to be established for the zone. The default permissionscorrespond roughly to well established security profiles. For example, the default "Stand-Alone Project" security is very weak, allowing projects outside the sandbox to perform most actions. This is similar to a trusted applet in Java 1.0, although the IT professional could curtail functionality as desired. The "Restricted Internet" zone runs like an untrusted applet in Java 1.0; there is no access to the file system and only URL access to the originating host. The default "All Other Internet" permissions roughly correspond to the Macromedia Flash MX security guidelines in that access to a private file sandbox is granted. All of these permissions can be granted or denied on a zone by zone basis, and they apply to both the browser-based (Netscape Plugin or ActiveX Control embedded in the browser) and stand-alone (runs outside the browser) versions of DreamFactory. The permissions can be centrally administered and distributed across the enterprise during installation of the DreamFactory application or control. The table below documents the default security permissions by zone.
The "Except..." button can be used to override the current URL Access security policy for specific domains on acase-by-case basis. This capability can be used to provide universal access to public web services hosted by establishedvendors that have their own user authentication systems and security protocols. Since these systems are available fromany Internet connected computer there is little reason to deny access from a particular location. Examples of theseService-Oriented Architectures include the sforce interface from salesforce.com and the Business Services Network fromGrand Central Communications. You can also use URL Access Exceptions to protect a private network behind the firewall thatwould otherwise be available for transactions. These exceptions effect the FTP, HTTP, and SOAP network permissions in all security zones.
The checkbox option above enables access to a dynamically generated list of public web services providers maintained by DreamFactory Software. These services are on the public Internet and guaranteed not to be a private service or network behind a firewall. The "show list" button will display the current servicesin the public list.
DreamFactory projects must have the appropriate permissions to perform the requested action or a scripting error will be generated.The "prompt" option means that the security administrator allows the end-user to decide the security policy for that permission.When this happens, a security request is presented to the user that explains the security issue at hand and the requested permission.If the end user "grants" the permission, then operation proceeds and the permission is added to the project file. If the permission is denied,the denial is added to the project file and a scripting error is generated. The author can prevent scripting errors from appearing to the user,see the discussion of project security in Section 4.0. DreamFactory authors can also test for the existence of different permissions to triggera request evaluation. This is very helpful for testing the capabilities of the client machine ahead of time and asking for permissions that willbe needed. For example, a new web site might ask to be included in a particular security zone, or to receive a certain permission needed forsuccessful completion of the project. The granting of permissions by end users can also be absolutely prohibited by the network administrator if desired.
When a project is first downloaded or created all permission prompts are reset. Be aware that editing the security policy will also reset prompts for the local projects. At that point the end user may have to grant or deny some permissions again under the new security policy. This ensures that previously granted permissions are reevaluated after any change in security policy.
All of the security measures are implemented at the virtual machine level, and there is a scripted interface to these capabilities. The Dialogpolicy() command invokes the security policy dialog, but all settings must be made manually at that point, unlike project security discussed below. The Projectpermissionget() function can be used to test the status of a given security permission. The names of the permissions appear below, and the function returns: grant, prompt, or deny. The Projectpermissionset() command will invoke the request for user evaluation of any prompt-able permissions. In this manner the author can ensure that necessary permissions are available, and invoke requests in advance of actual usage. Projects may also take alternative action or reduce functionality when permissions have not been granted.
|
The various permission names implemented by the configurable sandbox security system are listed below. These names are listed in the request dialog, and are parameters to the Projectpermissionget() and Projectpermissionset() commands and functions above.
|
|
|
|
The project security features are designed for a DreamFactory author (for example, a member of an IT department) to protect a DreamFactory project file from the end users of the project (for example, employees running DreamFactory in the browser on the local intranet). Not only can the project be locked up in a variety of ways, but the author can use password protection to unlock the project and make changes at a later date. The project security features are an entire security level beyond and on top of the more traditional client-server security discussed in previous sections. This is primarily designed to prevent end-users from altering the project and generating technical support calls. Project security is also useful when the author wants to persistently maintain sensitive information inside a project, although this is not common, normally sensitive information would be accessed through a web service and discarded. If an IT department is concerned about this possibility the entire project file can be internally locked, preventing storage of anything. Even if a deployed project were somehow corrupted or compromised, this just damages the local copy of the project for that end user. There is no way for an employee to deploy the corrupted project back across the enterprise without access to the server where the projects are stored. The panel below shows the standard project security panel, which drops down when the zoom button of the Utility Palette window is clicked:
The "password protection" radio button group at right provides a wide range of project security options, arranged from highest to lowest power. The "Open Project" option allows a password to be set for opening and running the project at all. The "Lock/Unlock" option controls locking and unlocking the project file, a locked project cannot be changed. The "Runtime/Edit" option controls access to all of the authoring interfaces, like the scripting windows, messagebox, debugger, and main menu bar. The "Private/Share" option controls going into private or shared mode; in private mode, other projects cannot access any data or variables from the private one. The checkboxes at left actually turn on and off these various features. The most popular option to deploy a finished project is to check "Runtime Mode" which hides all scripting and authoring interfaces, and then "Hide Utility Palettes" which makes sure that the palette above (and the other authoring palettes) are hidden when the project starts. Then the author could password protect project editing with the "Runtime/Edit" radio button, which means that these settings could not be changed at the client without the password. If a runtime scripting error occurs in runtime mode, the error dialog will document the error but will not provide access to the debugger or the script. If the "No Scripting Errors" button above is checked, scripting errors will fail silently, although in this case the project author might want to test for errors at various points (like network access) and inform the user of problems as desired. The "Privacy Mode" checkbox turns on project privacy, which means if another project opens this one or makes it the currently viewed project then all handlers will exit at that point, preventing the calling project from having access. Lastly the "Locked Mode" checkbox will lock the entire file from being changed at all. This is like a software read-only file lock, except it is stored internally and cannot be defeated by unlocking the file at the system level. This feature can also be password protected. The most draconian project security available is to actually remove all of the tool palettes and property dialogs, which can be done by right clicking on the DreamFactory desktop and selecting the remove option. The author needs to be careful about locking themselves out of the project. This can happen in a project that is password protected with no scripted interface to enter the password! Once the project is ready to deploy, the upload button can instruct the project to save itself back to the originating host with the appropriate FTP password, or some other deployment method might be used to put the new project file on the server for deployment. All of this is scriptable, so some IT departments may want to customize the standard project security panel or develop their own palettes for further security measures or convenience features.
The user interface for the standard project security panel is scripted, but the security measures themselves are implemented at the virtual machine level and cannot be circumvented by scripting. This is true even for the FTP back to the originating host; to implement this feature the DreamFactory project saves itself and makes a "zip" copy of the project. DreamFactory then FTP's this to the URL with the username in the FTP access section of the Utility Palette dialog box, and the password supplied at runtime. Inquiring minds can see how this works by looking into the "Upload Project" button to see the script. FTP access to the originating host must also be enabled in the DreamFactory Security Policy dialog (Section 3.3). This section briefly discusses the scripting commands and functions necessary for project security:
|
Project Security is associated with deployment strategies and scenarios. A major purpose of the project security infrastructure is to allow the IT department to change deployed projects with great ease and convenience. Where IT departments are sometimes required to implement new business rules on a daily basis, the ability to rapidly and flexibly update and maintain deployed applications from any web browser is a major advantage. Here is a typical deployment scenario:
First, the author builds or modifies a project. For a complex job he might use DreamFactory Professional which runs as a stand-alone application on the desktop and has the ability to edit projects outside the security sandbox. The author could also go to a DreamFactory URL and create or modify a project in the browser with DreamFactory Runtime. The browser-based version runs with the virtual machine security described in Section 3.0. The end result is a Dreamfactory Project that contains all of the user interfaces, scripts, media, and XML that your application requires in a single ".dfac" (DreamFactory Project) file.
Next, the author decides on a deployment strategy. If the end users are sophisticated, or if they need to modify the project, they can use it "as-is." The author may check the "Runtime Mode" box to prevent inadvertent project editing functionality from popping up. Going further the "No Scripting Errors" button could be checked to prevent notification of any errors at all. If the project is accessing sensitive data the author should avoid storing the data locally, or they could choose "Lock Project File" to guarantee that nothing can be saved locally. If there is any concern about the integrity or distribution of the deployed project any combination of these features can be locked in place with passwords.
Next, the author needs to save the project file to a central server for deployment. If they are set up to do so, they can use the "Upload" button to save the project to a password protected FTP site automatically. The author may also use any other method to copy the file to a secure server, much like copying a new HTML file for a web site. Now when any end user goes to that URL or hits the "Refresh" button they will download the new project. When they go back to the URL the project will be cached, so there will be no download unless the source file has changed. Essentially the project is a user interface shell for web services, so while the web services may change constantly, the project only needs to be downloaded when a new feature is added to the shell.
Now imagine that the author wants to change something in the project, or fix a scripting error. All they have to do is surf in the browser to the URL for that project. They unlock the authoring functionality, make the changes, test the changes, re-lock the project, and upload. On the next refresh the end users will get the new project automatically. That's it! No development environment, no source code, no server software, and no deployment hassles. Of course this might be too liberal for some projects or some companies, and they will institute more careful testing and development protocols. For example, they could rip the tool palettes and properties dialogs out of the project before deployment, preventing browser-based editing under any circumstances.
DreamFactory projects share many of the same concerns and issues as web pages when it comes to protecting the security of data. The DreamFactory file format is highly compressed and in general difficult to extract algorithms or sensitive data from, but this should not be relied upon as a security practice. This is similar to how HTML and JavaScript code can be easily viewed by users. In essence, any data, variables, or scripted code compiled into a downloaded DreamFactory project should not be considered secure. There are however a number of practices which can be employed to protect and utilize sensitive information in DreamFactory:
|
There are two ways that DreamFactory projects can be transferred via e-mail. The first way is to simply send the project as an e-mail attachment. In this case the project will fall under the "stand-alone" security zone described in Section 3.3. By default there are few restrictions placed on this zone, so the end user must exercise caution when accepting project files as e-mail attachments. The IT administrator can also tighten "stand-alone" security if desired. The second way is to embed the project in an HTML based e-mail with the intent of having the project run when the e-mail is viewed. In this case the project will fall under the appropriate security zone described in Section 3.3, just like any other project downloaded from a web site. In the case of projects embedded within e-mail, users may wish to consult the documentation for their e-mail client for instructions on how to enable or disable the automatic playback of ActiveX controls and Netscape plug-ins within e-mail.
Bill Appleton
CTO
DreamFactory Software, Inc.
billappleton@dreamfactory.com