Security overview
OpenFin is a security first, JavaScript/HTML5 runtime environment built on top of Google’s Chromium project that also incorporates GitHub’s Electron project. However, with the use of Electron as part of OpenFin OS, we take the following precautions:
-
Maintain the fidelity of the Chromium Security model.
-
Remove Node as an option in the renderer process.
-
Prohibit exposure of any Electron API (private or public) to a third party app or website.
In addition, OpenFin provides Group Policy controls around all APIs that can access sensitive resources, such as the file system.
Core Principles
OpenFin organizes its security philosophy around these core principles:
• Leverage the Chromium security team’s great work
• Co-stability with Chromium
• Strongly limit vulnerability to Cross Site Scripting
• Downloaded code must always run in Chromium sandbox
• All native applications must be signed
• Any code that sits on the file system must be checksummed/signed and validated prior to loading
• Not for use as a general purpose web browser
• Expose full process isolation for application owners to use
Sandbox
The Chromium sandbox is widely regarded as the strongest and most tested security sandbox available.
Chromium Security
OpenFin OS incorporates the full Chromium code base and therefore is able to expose core Chromium functionality that others do not provide. To the extent that Electron supports some capabilities provided by Chromium and Chrome extensions, these are done in a non-standard way that has proven to be problematic and ultimately unworkable for major customers. Because of this, we custom engineer Chromium back into OpenFin OS to give Desktop Owners and Developers additional security controls.
Below are two examples of capabilities provided by OpenFin via Chromium.
Blocking and allowing URLs
OpenFin enables defining URLs to block or to allow, via the application configuration file. With this feature, Application Providers and Desktop Owners can allow and bock URLs to enable or restrict which applications can run in their application environment. Electron does not expose this part of Chromium.
Group Policy
Not all organizations have the same policies. Application Developers and Desktop Owners need the ability to configure security options as needed. With OpenFin, Desktop Owner administrators have the ability to customize the Runtime environment to manage controls around specific API features. These controls enable Application Providers to use all API features, but give Desktop Owner administrators the option to turn them off via Group Policy. These additional settings are an extension of the Chromium base Group Policy flags. Electron does not expose this portion of Chromium which makes internal deployment at banks problematic as most have strict security policies around certain API functionality.
Inter-application Messaging
OpenFin applications on the Inter-Application Bus (IAB) expose the URL location from which they are loaded as well as the protocol used. This means that one can validate that an application was securely (HTTPS) loaded from a specific domain and thus be sure of its identity. Applications that are running outside of the OpenFin Runtime (native applications) but that are connected to the bus, expose their code signing signatures so that their identity can also be validated.
Application identity on the IAB gives application developers the tools, outlined below, needed to validate the applications they are interacting with are indeed who they say they are. The IAB requires applications to subscribe to a specific topic in order to receive any published or sent messages from a provider. Securing the IAB is at the discretion of the developer. Below are examples of two IAB methods, publish and send, and their use cases. These use cases will help you choose which method to implement based on the level of security you need to employ.
Encryption and Signing
All OpenFin binaries and libraries are signed by COMODO RSA CODE CA. All OpenFin code loaded from the file system is checksummed, signed, and validated prior to running. Signatures for application assets are exposed via the API for applications to validate.
Security Realms
A security realm is a mechanism used for protecting your running web application from other OpenFin applications on the same machine. It gives you the ability to protect a resource with a defined security constraint and then define the ways that external applications can access the protected resource.
Security realms provide applications providers the following:
Feature | Description |
---|---|
Isolated Browser Process | The browser process is typically a shared resource in a web environment. Security realms further isolate your application from other applications running on the same machine by giving you a dedicated browser process. |
Separate Cache | Ensures all applications, not in your security realm do not have access to your application's cache. |
Configure
To configure a security realm via an application config, Application Providers add an argument key to the “runtime” election for their application’s config — at the same level as version. (Or add this option to your existing arguments key). The realm value can be any string that is valid as a Window’s folder name.
"arguments":"--security-realm=[MYREALMID]",
Example
The realm value can be any string that is valid as a Window's folder name.
},
"runtime": {
"arguments": "--security-realm=[MYREALMID]",
"version": "beta",
"forceLatest": true
},
Multi Runtime Configure
To re-enable multi runtime features while using a security realm, Application Providers can pass in the ––enable-mesh
flag to the runtime arguments. This keeps your app in a separate browser process with its own cache, but allows the use of OpenFin API’s with mesh enabled applications on different runtimes.
"arguments": "--enable-mesh",
Example
},
"runtime": {
"arguments": "--security-realm=[MYREALMID] --enable-mesh",
"version": "beta",
"forceLatest": true
},
Have questions? Get in touch with us at [email protected].
Updated about 1 year ago