TOC

• introduction
• Trusted and Untrusted communication
• Streaming input and output
• Deployment security

Introduction:

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 for details.

TOC

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 the DataManager:

Figure 1:

In this case communication is trusted: the Admin has direct access to the DataManager.

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:

1. The server needs to expose a public access point. For purposes of discussion, assume this is done through a single Gateway node (refer to the sandbox docs for information on making the corresponding message topic public). Note that an actual deployment may run several instances of different kinds of gateway nodes depending on load and security requirements.
   
   
2. The sender needs to be identified in the incoming message. To accomplish this, the FrontController calls the wrapMessage utility with the UserUpdate message to create an AuthWrapper (a message containing the encrypted username/password information and the payload message).
   
   
3. The AuthWrapper is sent to the Gateway, which unwraps the AuthWrapper, verifies the legitimacy of the sender, and checks if they are authorized for the enclosed action. If all is in order, the Gateway (being a trusted node) sends the UserUpdate on to the Admin, which eventually returns a UserUpdate. The Gateway AuthWrappers the UserUpdate using the same user credentials it received, and returns the AuthWrapper to the sender.

Figure 2:

TOC

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 model.

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 access.

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.

TOC

Deployment security:

The security of a deployment is dependent on many factors. The SAND security model defers to the sandbox implementation for specification of:

• the encryption used in the AuthWrapper
• trusted and untrusted communication processing and setup
• setup and processing of other deployment protocols in use

TOC