14.6 Guards

We can get a good handle on the guard issues by following information flow from the browser to the CustomerGateway fortress to the OrderManagement fortress to the Inventory fortress, as shown in Figure 14.9. All of the guards in this system will be variants of guards that we will encounter within this sequence.

The single hardest guard issue we run into is, coincidentally, the first: validation of the HTTP request. You might ask why we're worried about validating the HTTP request. After all, this request is coming from emissary code ”that is, code that was written by the same team that wrote the CustomerGateway fortress. But that is part of the problem. HTTP requests can come from anywhere .

The guard should check all input fields for two things: buffer overflows and illegal characters. Both of these are topics I discussed in Chapter 7 (Guards and Walls), so I won't repeat that discussion here. Note that problems with both buffer length and illegal characters can be handled by emissary code, so in a sense what I'm really worrying about is hackers skirting my emissaries. Because it is trivial for hackers to do so, I must take this possibility seriously.

Once I am convinced that I'm receiving a valid HTTP request from one of my emissaries, I can start to deal with the next problem: Is this request coming from somebody who is authorized to use my system? This is a more difficult problem to attack in the presentation fortress, namely because we run into conflicting security demands.

On the one hand I want the presentation fortress to validate the user. To do this, I may need to store passwords and sensitive user information in the presentation fortress's data strongbox. I could then design my guard to check the password input field and the user name , and validate these against information in the data strongbox.

On the other hand, storing passwords and sensitive user information in the presentation fortress's data strongbox is, in itself, a security problem because anyone who succeeds in hijacking a presentation fortress process will have access to all of this information. After all, the whole reason we have a presentation fortress is to keep our proprietary business logic "offline" relative to our Internet connections.

Good guard design requires balancing these two concerns, recognizing in advance that there is no perfect solution. For example, I could store encrypted user passwords on the presentation fortress. However, I would also have to store a private key on the presentation fortress, which in itself would be a tempting hacker target.

I could pass through the user ID and password to the back-end OrderManagement fortress. However, at least temporarily I would have to store unencrypted user IDs and passwords in presentation fortress memory that is potentially available to a hijacked presentation fortress process.

I could set up my emissary to do public/private “key encryption of the user ID and password at the emissary. I could then pass this encrypted information to the OrderManagement fortress and let it do the decryption and authentication. However, this approach limits my users to those for whom I have a trusted public key. Not many of my standard users will have bothered to register with public/private “key systems, although such an approach might be workable on the Web service fortress side.

In any case, the guard authentication algorithms will be standard authentication algorithms that are a specialized topic in their own right. This is one of the reasons I emphasize consolidating security responsibility into a single point of contact.

Having discussed the CustomerGateway guard, I can turn my attention to the OrderManagement guard, the one defending the PlaceOrder drawbridge. This guard wants to ensure that it is receiving requests only from the CustomerGateway fortress. Depending on what authentication choices we made in CustomerGateway, we may need to include some authentication logic in the PlaceOrder guard as well.

As I have said, I prefer to use a single technology base for both presentation fortresses (e.g., CustomerGateway) and the connected business application fortresses (e.g., OrderManagement) where possible. If I am using a synchronous gateway (which is what I have shown in the SAD for the ProcessOrder treaty), then I will be making that gateway homogeneous. Homogeneous synchronous gateways are invariably based on native component technology, such as .NET Remote Binary Protocol in the Microsoft system, or RMI/IIOP in a Java system. One nice thing about homogeneous synchronous gateway technologies is that they include some useful built-in guard mechanisms. One of these is the ability to make sure that the PlaceOrder guard accepts requests only from specific processes, such as the one containing the outgoing guard in the CustomerGateway fortress.

The final guard I'll look at is the one in the Inventory fortress guarding the UpdateInventory drawbridge. The UpdateInventory drawbridge is a heterogeneous asynchronous drawbridge, as shown in Figure 14.9. As such, it is most likely based on a message queue technology, such as IBM's MQSeries or Microsoft's MSMQ. Either of these technologies includes the ability to set permissions on the underlying message queue, which can theoretically make it impossible for nonauthorized processes even to send messages to the GetInventoryByVendor guard.

This analysis covers only three of the various guards, but the rest are just variants. The GetInventoryByVendor guard of the Inventory fortress, for example, is a variant of the UpdateInventory guard of the same fortress. The CheckVendorInventory guard of the VendorGateway fortress is a variant of the HTTP guard of the CustomerGateway fortress.