webcom.core.conman.SecureConnectionManager

The secure connection manager ensures that communication between one WVM and another is secure. It uses an implementation of a security protocol, for example SSL [92], to provide authentic and crytographically secure communication links. The default SecureConnectionManager class extends the standard CommunicationManagerModule class to use SSL sockets. However, in most cases, the inherited methods from the standard IPv4-based WebCom connection manager are used. The methods that are overridden provide the implementation of SSL using Sun Microsystems’ Java Secure Sockets Extension (JSSE).

public boolean connectTo(InetAddress address)

public boolean connectTo(InetAddress address, int port) public void setPort(int cpPort)

7.5 Discussion and Conclusions 141

The scmm.connectTo(addr)and scmm.connectTo(addr,p)connect to a SSL se- cured socket at the provided address (using the port number, when provided). These methods set up a secure connection between the local and remote WVMs. Thescmm.setPort(p)method specifies the port number that the SSL server socket on the local WVM should be listening on. This port is normally specified in the module properties file and is loaded by the super class. This method allows the port number to be changed at runtime. Finally, thescmm.processMessage(msg)

method adds some additional supported message types to the types supported by the superclass. These message types include the ability to query the public key provided by connecting WVMs for use by the SecurityManagerModule.

Providing secure communication also entails using a public key infrastructure to manage the keys used by WVMs. A public key infrastructure is necessary to properly determine validity of cer- tificates, provide for certificate revocation, to provide a means to issue new and renewal certificates and to act as a repository for user certificates. There currently is no specific PKI implementation available for WebCom. Instead each WVM must have all the necessary certificates locally in order to support secure communication. The provision of a proper PKI implementation is the topic of future work. As work on WebCom is currently aimed towards using it as a Grid middleware [124], support of federated identity management [6, 117] is also an important topic of future work.

7.5

Discussion and Conclusions

In this chapter, we have introduced the access control model for WebCom. WebCom’s access control model is designed to address specific threats to a distributed computing environment including illicit data and computation modification and unauthorised access to data or computations by principals. These threats are addressed by WebCom through the provision of an authorisation mechanism to ensure that computation execution and data access is only performed by authorised principals.

WebCom provides a distributed model to support access control decisions. This model uses the naming architecture described in Chapter 6 in determining the authorisation of security criti- cal actions to be performed by WVMs. These actions consist of the scheduling and execution of condensed graph nodes.

WebCom is a closed system, in that a WVM has access to the name of every node in an applica- tion executed by that WVM. Therefore, a WVM can potentially act as a central repository of policy decisions. For example, we can use the parent WVM to ensure that an access permission granted to a particular child does not cause a conflict in a separation of duties, or Chinese wall-style policy.

Although the entire access control system can be implemented using the Haskell primitives de- scribed in this chapter, for both simplicity and efficiency reasons, the reference implementation is implemented using the Java programming language and existing access control logics, JKeyNote [90] and JSDSI [5].

In this chapter we have discussed a particular form of access control, using trust management to make security decisions: the design of WebCom supports the replacement of this system with a dif- ferent enforcement mechanism. However, any implementation of the security architecture will fol- low the model proposed in Section 7.1 as any implementation of the security manager module must support themayExecuteandmaySchedulechecks, implemented using theisAuthorised

function. For example, the security model could be implemented using access control lists (ACLs). In this case WebCom names would allow contextual information to be stored in the ACLs.

The naming approach to specifying security policies allows a separation of security checks from functional code. This provides a loosely-coupled architecture, where maintaining security policies does not require changing functional code. Other work has looked at codifying protection mecha- nisms as condensed graphs [62]. This work proposes implementing fragile, tenacious and emergent protection mechanisms using triple manager primitives that determine whether nodes should be executed in particular domains.

In the current implementation of WebCom entities are identified by their public key. A critical requirement in a distributed computing environment is the management and verification of these identities. This entails ensuring that there is a systematic way to determine the identity of both the users of the system and the resources used in the computation. Identity verification and management can be provided through the use of authorisation mechanisms.

In order to fully support identity in WebCom, some form of federated identity system is re- quired, such as Liberty Alliance [6] or Microsoft’s Passport [117]. Federation of identity allows each resource in the system to have an assembled identity that the entire distributed system can use to refer to that resource. For example, a user can be a manager in one domain and a clerk in an- other. Each domain refers to the user in the context they support. With a federated identity, the two domains share a context when they are referring to the user. The provision of a federated identity system is a topic of future work.

Another important topic of future research is the provision of a public key infrastructure (PKI) for WebCom. In its current form, WebCom uses an ad-hoc method to distribute both identity and authorisation certificates. It is envisioned that a PKI architecture should be constructed to provide a distribution mechanism for such certificates. PKIs also support concepts such as certificate revoca- tion, which is also not currently addressed.

WebCom also includes a messaging architecture, where modules can send messages to other modules, both in the same or to other WVMs. The security model presented does not address this architecture. In practice, a security check is performed on all messages. Security policies can be written about messages, allowing users to control what messages are authorised to be acted upon. These policies could be specified in terms of the WVMs that a particular entity trusts. However, this only supports coarse-grained policies. More precise checks could specify the modules in a WVM that are trusted to send or receive specific messages. Such checks would require a naming system

7.5 Discussion and Conclusions 143

for messages. Extending the WebCom security model to represent the messaging architecture is a topic of future research.

While WebCom’s messaging architecture provides several advantages, the potential for illicit behaviour using messages causes concern. It can be argued that this messaging system should not be allowed, or at least only allow a predefined set of vetted messages. However, it is possible to implement a general messaging system in a manner that lies within the security model. Messages could be implemented as condensed graph applications, and the existing security architecture used to enforce specific policies.

Case Studies

We have seen, first in Chapter 5, and in more detail in Chapter 7, that WebCom is a modular and “pluggable” distributed execution system. WebCom’s flexible design allows the creation of specific applications, such as the ShareTrader application described in Chapter 7. In this chapter, we will examine the advantages of Secure WebCom in more detail and describe some specific case studies that use the architecture.

WebCom’s pluggable architecture allows the creation of different implementations of its core modules. Specifically, in this dissertation, we have examined the implementation of the security manager module. Changing security managers allows the enforcement of completely different se- curity policies, while still adhering to the security model described in Chapter 7. This allows the creation of new applications that use Secure WebCom as their base.

This chapter describes applications of Secure WebCom. These applications are developed using the security architecture to support specific security requirements. In Section 8.1, we examine an early Secure WebCom prototype [65, 66] and describe how security policies from this prototype can be enforced in the current system. Section 8.2 describes a security manager for WebCom that incorporates micropayments, using the naming and security architectures to enforce pay-per-execute policies. This system uses trust management to support a credential-based payment system.

We analyse a grid administration extension for WebCom, called GridAdmin, in Section 8.3. This system uses WebCom to provide a secure administration system for computational clusters. Admin- istration tools are provided using workflow applications that execute on demand on the machines being administrated. Applications for this system range from adding users to enforcing exclusive access to a cluster. The WebComDAC case study is described in Section 8.4. WebComDAC is a se-

cure workflow system to control security policies on heterogeneous systems. We use WebComDAC

to view, modify and enforce a unified security policy across multiple systems and domains. Sec- tion 8.2, Section 8.3 and Section 8.4 are the result of collaborations with other members of the Centre for Unified Computing in UCC.

8.2 Classic Secure WebCom 145

8.1

Classic Secure WebCom

WebCom was originally developed [65, 66] using a hybrid of the Java and C programming lan- guages. The distributed system was implemented in Java, while the execution engine was written in C. A consequence of this design was that, as the internals of the graphs were not available for exam- ination by the distribution system, node names were based purely on the function name of the node. The KeyNote trust management system was used to provide configurable access control. This ac- cess control mechanism was only able to make decisions based on the function of a node. However, with the development of the current WebCom architecture, this limitation no longer exists.

Security policies from the original WebCom prototype can be denoted in terms of reduction rules for the current WebCom system. This entails using tuple elimination rules to reduce a name to contain only the function tuple. This rule can be expressed in Haskell as follows:

retainFunc :: Name -> Name retainFunc (Snam d g f i o) = f

The retainFunc1 reduction rule extracts the function tuple from the provided name and discards the remaining entries. This allows traditional WebCom trust management policies to be enforced. A credential used with such a policy is shown in Figure 8.1.

KeyNote-Version: 2 Comment: Local-Constants: Alice = "rsa-base64:MIGfMA0GCSqGSb3DQEAQUA4GNADCBiQ\ Sr8xM9qBGuvbXG1eIZM6IcYTxQIDAQAB" Bob = "rsa-base64:MIGfMA0GCSqGI3DQEBAQ4GNACBiQKBg\ CKP9TXQE/zlC+poPrKHr/S7yHQIDAQAB" Authorizer: Alice Licensees: Bob

Conditions: App_Domain == "WebCom" && (Function == "checkprime.isPrimeOp")

&& operation == "execute");

Signature: "sig-rsa-sha1-base64:H0YZV5yvCVNpLiVbyWWvclE\ bmLbPdvYEzCY2nkVCX35feMasCPrOIVf+oluqjJGqY=" Figure 8.1: A function only KeyNote credential.

This credential defines that Alice delegates the execute right to nodes with the function name

checkprime.isPrimeto Bob. Providing such general credentials is, however, not necessarily advantageous. This credential allows Bob to executecheckprime.isPrimenodes in any pos- sible graph, regardless of input or output or execution domain. This was a significant disadvantage of the original WebCom prototype. With the current implementation, using different reduction rules allows finer granularity policies to be enforced within the same access control system.

1

We could alternatively use a combination of the tuple elimination rules described in Chapter 6. However, in this case it is simpler to use one reduction rule to retain a tuple, rather than applying four separate tuple elimination rules.