This chapter discussed several application case studies using Secure WebCom. We have described how the security architecture of WebCom can be used to support specific applications, such as micropayments, administrative workflows and Grid administration. We have examined the extensi- bility of WebCom and in particular the naming and security architectures.
As WebCom is designed as a modular system, it can be extended to support different application requirements. This has the advantage that specific requirements can be quickly implemented using the security system. For example, the micropayment security manager can be used by any applica- tion to provide a payment system where every execution must be paid for. This could be used as an auditing tool, where we do not attempt to recover payment, but instead analyse where and how many nodes have executed in any given domain.
Recall in Chapter 5, we argued that the WebCom architecture is inherently loosely coupled, that is, functional and security requirements are implemented separately. However, experience gained developing these case studies has shown that this is not entirely true. While in theory, information can be abstractly represented in the name of a node, in practice, it is often easier to embed this infor- mation within the implementation of the security manager. Therefore, the case studies demonstrate
8.5 Discussion and Evaluation 175
that custom security manager implementations are required for specific applications.
The case studies presented in this dissertation serve to evaluate the effectiveness of WebCom’s security model and the software architecture. Several conclusions can be drawn from experience gained through the development and implementation of these applications. For example, represent- ing hash-based micropayments requires implementing a specific micropayment security manager for WebCom. This security manager handles the contracts and provides the logic to ensure that the hash coins are valid. However, an extension of the KeyNote trust management systems to support a hashing function has been proposed [59]. This would remove the need for the hashing logic in the security manager. Regardless, a separate contract mechanism would have to be retained.
Interacting with Grid resources is also not as straightforward as initially believed. As Grid security is based upon the identity of the users submitting jobs. These identities allow Grid resources to determine whether, and indeed when, to execute user jobs. As WebCom identifies users in terms of public keys, user jobs can at best be identified to the granularity of the WVM submitting the Grid job. While the naming architecture is technically capable of embedding user certificates as part of a node’s name, implementing such a system would again require a specific “grid job” security manager. The provision of a federated identity system [6] would help greatly towards addressing this particular problem.
This experience has resulted in the belief that any non-trivial security application would require the creation of a specific security manager for WebCom. However, WebCom supports the use of several implementations of any module. For example, the micropayment security manager could be used in conjunction with the standard trust management based security manager so that the micropayments were processed, while a standard trust management policy could also be enforced.
Discussion and Conclusions
Chapter 9
Conclusions
In this dissertation, we have introduced the WebCom distributed computation environment, and the condensed graph computation model that it utilises. The WebCom architecture is a distributed computation environment provides the basis for secure, fault tolerant, load balanced distributed applications. The pluggable nature of the WebCom architecture allows the development of modular components. The reference implementations of the core modules can be replaced, allowing different implementations of those modules to be used.
Applications in WebCom are specified as condensed graphs, where the nodes in the graphs rep- resent atomic actions. WebCom’s modules control the scheduling of these nodes. This provides a clear separation of function and control code. This separation of concerns is not security specific; every module in WebCom enjoys the same advantage. This allows policies to be written indepen- dently of the functional code.
From a security standpoint, the architecture of WebCom prompts some interesting challenges. The security requirements of WebCom are managed by the Security Manager Module. Different implementations of the security manager can be used to enforce different types of access control. As WebCom is a distributed environment, enforcement of the security policy must also be distributed. WebCom can exist outside of the control of a single administrator. Instances of WebCom running on different resources can have different administrators. The security system must support this type of architecture.
Developing a security architecture for WebCom necessitated the investigation of the nature of condensed graph applications. In this dissertation, we have argued that in order to properly specify security policies for nodes in a condensed graph, we first need to properly name these nodes.
Naming condensed graph nodes requires capturing the contextual details that describe these nodes. This context includes details such as the function of the node, the domain where it is ex- ecuting, and the history of the node. Using this context, naming policies can be constructed that can be used by enforcement mechanisms to help direct the scheduling and execution of these nodes.
Chapter 6 explored naming issues and developed a model for naming in WebCom.
The WebCom naming model can also be used to support the other WebCom modules. For example, using WebCom names in the fault tolerance module to refer to WVMs would allow more contextual information about these WVMs to be provided. As WVMs were referenced by their IP address in the original implementation of WebCom, only one instance of WebCom on a single resource was permitted. The greater contextual information available within WebCom names allows multiple instances of WVMs on a single resource.
Reduction rules are used to take complex names and remove unnecessary information. We use reduction rules to help create specific policies, such as history-based policies. For example, we can use history-based policies to store the names of the domains that the nodes have executed during the computation.
We investigated WebCom’s security architecture in Chapter 7. Secure WebCom provides the ability to specify access control policies in terms of WebCom names. These security policies are enforced by WebCom’s security manager. We argue that if sufficient context is provided within the names, then a wide variety of authorisation requirements can be captured as access control policies. Finally, we explored some extensions to WebCom in Chapter 8. These case studies demon- strate the extensibility of the Secure WebCom architecture and provide some practical examples of applications that can be developed using WebCom.
9.1
Results and Contributions
There are four main contributions contained within this dissertation. We have defined a naming architecture for condensed graphs, that specifies the contextual detail required to properly name a distributed component. Using this naming architecture, we have developed an access control-based security architecture for WebCom that allows application developers to specify security constraints regarding their applications. This architecture has been implemented in terms of a software archi- tecture that support names in practice. Finally, we have developed a number of case studies that examine the capabilities of WebCom and explore some of the advantages of WebCom’s security architecture.