This document assumes familiarity with the
SAND architecture whitepaper, and freely uses
terms defined there.
The SAND architecture provides a general security model based on
authenticated messaging, which enables a wide variety of authorization
models tailored to the specific needs of the individual application. It is
important to note that other access (most notably by sandman) may involve
protocols outside of messaging, which are not discussed in this document.
A sandbox may also provide additional security support through generated
code, custom nodes, additional tags or other mechanisms to support easy
application development and deployment. Refer to the sandbox documentation
Trusted and Untrusted communication:
In a typical diagram, messages are depicted as being sent directly
between cooperating nodes. For example consider a setup where an Admin
node validates UserUpdate business logic before sending the message on to
In this case communication is trusted: the Admin has direct access to
Now consider a setup where a FrontController HTTP protocol adaptor node (e.g. a node declaration that extends HttpServlet) needs to send a UserUpdate to the server. Furthermore, assume that the server cannot trust this node. Communication now requires several steps:
Streaming input and output:
Many enterprise systems consume streaming information from an external
source, and also produce streaming output for external consumption. These
are unidirectional message flows, but they follow the same authorization
As an input example, consider a realtime feed of currency exchange rates
being received by an ExchangeRate node. ExchangeRate is responsible for
verifying its input is trustworthy, using a mechanism appropriate for the
feed. Trusted nodes can subscribe to ExchangeRate directly.
Now assume that we want to pass this information on as system output,
but with a 20 second delay. To do this we create a new node called
DelayedExchangeRate, which subscribes to ExchangeRate and buffers the
information before sending it on. DelayedExchangeRate is set up for public
Any incoming subscription request passes along an AuthWrapper, which
contains the encrypted username/password information. By default, this
AuthWrapper null, meaning that access is gated only through messaging layer
controls. To restrict general access to exchange rate information,
DelayedExchangeRate can reject subscription requests which do not specify
authentication information. Using the authentication information,
DelayedExchangeRate can authorize subscriptions based on business logic.
Sandbox implementations may offer additional levels of control based on
the capabilities of their underlying message layer.
The security of a deployment is dependent on many factors. The SAND security model defers to the sandbox implementation for specification of:
The sandbox implementation may in turn defer to the deployment for
additional security specifications. Remember that security is only as good
as the weakest link in the deployed system as a whole. It is highly
recommended that all deployments undergo a full security audit by trained
professionals both before release, and on a regular basis afterwards.