Locked domains

Domain locking is a security feature that isolates and protects OpenSocial widgets from third-party sources that might try to cause harm to other widgets, the browser, or your application. Locked domains are essential for products such as IBM® Domino® and IBM® iNotes® that allow users to add or render widgets from third-party sources.

Malicious content often tries to take advantage of a user's authenticated session to extract server data, modify other widgets on the page, or attack web services that have been authenticated and authorized through Open Authorization (OAuth). Locked domains prevent these security risks by sandboxing widgets into individual subdomains that cannot be penetrated by third-party sources or other widgets on the page.

Locked domains prevent widgets from having direct access to secure information in the browser and in other widgets on the page, including JavaScript and cookies. Even with a proxy, a piece of malicious or hacked JavaScript code that is loaded in the browser without locked domains can gain access to all of a user's single sign-on (SSO) cookies via the window.cookies object. Even though SSO cookies time out after a set expiration time, the malicious code can obtain blanket access to the enterprise for a given interval of time.

Therefore, in iNotes®, it is strongly recommended that you configure locked domains and never disable them.

Locked domains and host domains

A locked domain implementation consists of three separate domains:
  • A single sign-on (SSO) domain.
  • An unlocked container domain for your host application, that is, iNotes®. This unlocked domain can be part of the SSO domain, but ideally the two domains should be separate so that cookies such as SSO tokens are not unintentionally carried along with content requests.
  • Locked hosts that are derived specifically for each widget. Widgets run in individual subdomains of the locked host to prevent widgets from sharing data among themselves.
The unlocked domain handles initial calls such as proxy requests and has a specific host name, for example unlocked.gadgets.renovations.com. The locked host name used for widgets is derived by computing a hash of the widget URLs and pre-pending that hash to a locked domain name suffix such as -locked.gadgets.renovations.com. The locked domain suffix must be a separate top-level domain (TLD) that is separate from the container (host application) and SSO domains.

To re-associate Open Authorization (OAuth) tokens with the locked gadget, the container uses an encrypted string called the security token. Similar to SSO tokens such as Lightweight Third-Party Authentication (LTPA), the security token has a relatively short life span to ensure that access is not granted indefinitely if a widget is hacked. SSO tokens do not flow directly to the widget, even if the security token is compromised, so the widget can only access resources that it is authorized to access via the proxy.

Common deployment scenarios

The main factor that determines your deployment scenario is how and from where your OpenSocial widgets receive data. If they receive data only from within the enterprise firewall (intranet), your configuration setup will differ from setups for widgets that receive data from outside the company.

You may need to register your locked and unlocked domains externally with a trusted domain name registrar.