Design and Architecture – Madhukar's Musings

A Gatekeeper is a design pattern in which access to storage is brokered so as to minimize the attack surface of privileged roles by limiting their interaction to communication over private internal channels and only to other web/worker roles. These roles are deployed on separate VMs. In the event of a successful attack on a web role, privileged key material is not compromised. The pattern can best be illustrated by the following example which uses two roles:

The GateKeeper –
this is a web role that services requests from the Internet. Since these requests are potentially malicious, the Gatekeeper is not trusted with any duties other than validating the input it receives. The GateKeeper is implemented in managed code and runs with Windows Azure Partial Trust. The service configuration settings for this role do not contain any Shared Key information for use with Windows Azure Storage.
The KeyMaster –
this is a privileged backend worker role that only takes inputs from the Gatekeeper and does so over a secured channel (an internal endpoint, or queue storage – either of which can be secured with HTTPS). The KeyMaster handles storage requests fed to it by the GateKeeper, and assumes that the requests have been sanitized to some degree. The KeyMaster, as the name implies, is configured with Windows Azure Storage account information from the service configuration to enableretrieval of data from Blob or Table storage. Data can then be relayed back to the requesting client. Nothing about this design requires Full Trust or Native Code, but it offers the flexibility of running the KeyMaster in a higher privilege level if necessary.

This solution is not ideal, since the KeyMaster is relying on GateKeeper to tell it what content to serve out. However, it does provide for separation of duty and it can poses additional challenges for an attacker. The amount of trust the KeyMaster places in the GateKeeper can be custom-tailored, but it is advisable to minimize the types of access requests allowed from the GateKeeper — allowing the KeyMaster to accept Storage Blob API read and list operations from GateKeeper, but not add or delete operations, for example.

This pattern can easily be adapted to work with more complex service architectures on Windows Azure. All that is needed is to put a partial trust “Gatekeeper” in front of more privileged (or native code) roles to do the parsing of potentially malicious data from the network. The concept is analogous to a firewall running as Network Service to interact with foreign TCP payloads before pushing them up the stack to more critical components.

The pattern is explained in the paper Security Best Practices For Developing Windows Azure Applications,which can be downloaded from from Microsoft Download.

Software design is blueprint of the system. We design systems based on requirements. It rarely happens that the requirements we get does not change.So, design also keeps changing with the requirements.

It becomes very difficult to keep the sanity of design with the changing requirement, if not handled carefully. After sometime it becomes very difficult to maintain the basic feature of good design like maintainability, extensibility, re-usability, minimal complexity etc. and the

Robert C. Martin defines this problem as design smells. He defined some basic characteristics of design smells, which we could find in the designs which become rotten.

Rigidity
Whenever a design becomes difficult to change, we should know that the design is going into or already in bad shape. A design is rigid if a single change causes a cascade of subsequent changes in dependent modules. The more modules that must be changed, the more rigid the design.

Fragility
Fragility is the tendency of a program to break in many places when a single change is made. It happens that the new problems occur in the area which has nothing to do with the code piece which was changed. Fixing those problems leads to even more problems. As the fragility of a module increases, the likelihood that a change will introduce unexpected problems approaches certainty. This seems absurd, but such modules are not at all uncommon.

Immobility
A design is immobile when it contains parts that could be useful in other systems, but the effort and risk involved with separating those parts from the original system are too great. This is an unfortunate but very common occurrence.

Viscosity
Whenever you are going to change a piece of software and you find more than one way to change, it means the design is exhibiting Viscosity. Some of the ways preserve the design; others do not. Viscosity comes in two forms: viscosity of the software and viscosity of the environment.

When the design-preserving methods are more difficult to use than the hacks, the viscosity of the design is high. It becomes easy to do the wrong thing but difficult to do the right thing.

Viscosity of environment comes about when the development environment is slow and inefficient. For example, if compile times are very long, developers will be tempted to make changes that don’t force large recompiles, even though those changes don’t preserve the design. If the source code control system requires hours to check in just a few files, developers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved. In both cases, a viscous project is one in which the design of the software is difficult to preserve. We want to create systems and project environments that make it easy to preserve and improve the design.

Needless Complexity
Many times in developers add features in the anticipation of future requirements. These changes they do just for the future requirements or unforeseen scenarios.

A design smells of needless complexity when it contains elements that aren’t currently useful. At first these things look good for the flexibility of the system, but these changes actually add needless complexities to the system

Needless Repetition
As the title suggests, it usually happens in the system, same piece of code lies in more than one place. This may be because of simple copy paste habit and reduce the maintainability and bugs found in these needless repetitions require fixing in every place. And most commonly the fixes vary in different places because the repeated code has been changed as per the requirements in all different places.

M	T	W	T	F	S	S
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Category: Design and Architecture

Gatekeeper Design Pattern

Design Smells