Anatomy of a Request

Having looked at the major components of the LongJump architecture, it is now time to see how these parts interact with one another. Figure 4 is a UML Collaboration Diagram, which shows the flow of a user's request through a LongJump application. This diagram complements the static view of Figure 3. Both diagrams use a corresponding color scheme, with security components in red, system state components in yellow, and business logic in green. Items shaded in blue are outside the application itself, but interact with it.

The objects in Figure 4 do not necessarily represent instances of actual classes in a particular LongJump implementation. Those classes, however, will have interfaces that function as depicted in the diagram. In some cases, Figure 4 shows the same object more than once, in order to make the illustration of the message flow clearer.

As reflected in the diagram, a request invokes several security-related objects as it travels through the system. It may, however, invoke only one business logic object out of many that are available. The specific business logic objects called are a function of the nature of the request, while the same security objects act on every request. This is the reason why so many security objects are shown in the diagram, even though business logic objects are likely to be the most numerous.

The example request in Figure 4 originates from the client — this is the so-called pull request. In the case shown, access to a third party server is required to generate the reply. In order to illustrate all major parts of the architecture in operation, the request is also assumed to be well formed and valid. Otherwise, it would be rejected early by the security subsystem.

The pull request is triggered by a user's input via the user interface of the client. In this example, the more complex case of a custom client program is illustrated. In the simpler web-based system, most of the client's business logic and security components will actually reside on the server — once again, the similarity of web clients to dumb terminals is clear.

The user interface talks to the business logic, which issues the request. The networking subsystem asks the security module to prepare the request for transmission (the latter will add user authentication information, for example). The request is then issued; it travels over the Internet to the LongJump servers.

The server's networking subsystem receives the request from the Internet. At this point, nothing is known about the message, so the first check invokes the security filter. Any malformed requests sent by an attacker that managed to reach the server will be dropped now, protecting the rest of the system and reducing the amount of resources spent on processing bad data. A security violation can optionally be logged as well.

The above represents good security design. A poor design would allow the broken message to penetrate into the business logic, wasting valuable resources and likely wreaking havoc on the delicate, complex code inside. By comparison, a validity filter is much simpler and more efficient, thus forming a robust shield for the other components.

Now that the message is known to be well-formed, it is time to authenticate the user. This might be a complex step initially, but with subsequent requests in a long series being able to use simpler authentication logic (i.e. the user is considered "logged in" after the first request). Upon successful authentication, the networking subsystem knows that it has a well-formed message from an actual user, so it forwards the request to the business logic components.

While both the message and the user may be valid, the user may not have the permission to carry out the operation requested. Business logic components therefore use the security subsystem to verify if a particular operation should be allowed to proceed. The Operation Selector is a good candidate for the place where such checks may be consistently performed. In this example, the operation is permitted.

As part of carrying out the operation, the business logic calls into the System State Engine, which stores and manages the result of every action. While only one such call is shown in the diagram, a complex request may generate multiple calls to update the system state at various stages of processing.

In order to fulfill the request illustrated in Figure 4, a third party server must be accessed for some of the work. The business logic instructs the networking subsystem to initiate the required communication via the Internet. The security subsystem is therefore involved once again, both to prepare the message for transmission, and to check the reply coming back.

After completing all processing on the request, the business logic instructs the networking subsystem to deliver the results back to the client. The security subsystem is used to apply the required outbound operations, and then the networking subsystem sends the the message via the Internet.

Once the client's networking subsystem receives the message, it is checked by the security module before being forwarded on to the business logic, which finally asks the user interface to display the data to the user.

In summary, the method of handling requests described here provides well-defined points throughout the entire program where security and system state integrity are maintained. It is a method which is widely adaptable to many common protocols, including the ubiquitous HTTP, UDP datagrams, and continuous TCP connections. The method also allows a LongJump application's business logic to change with the needs of the users — without compromising security and state integrity in the process.