Validating G-UCON – possibilities and limitations

Automated reasoning, i.e. automatic model checking deals with automated methods to establish the satisfiability or validity (as well as unsatisfiability or invalidity) of sets of formulas. In order to perform a model checking (see subsection 2.3.1), we need a suitable transition system that can capture the properties of the modeled systems (like Kripke structure for closed systems), a suitable logic (like LTL for Kripke structure and linear temporal processes), and a suitable model checker for both (like SPIN [290]).

Alternating-Time Temporal Logic is the used logic

Alternating-Time Temporal Logic (ATL) is the common specification language for open systems. A closed system “is a system whose behavior is completely determined by the state of the system” whereas an open system “is a system that interacts with its environment and whose behavior depends on the state of the system as well as the behavior of the environment” [184]. ATL offers the possibility to handle the notion of alternating, i.e. to deal with the question whether the system can resolve its internal choices in a way that guarantees the satisfaction of a property, regardless of how the environment resolves the external choices. This is the main advantage of this logic. ATL allows the writing of formal specification of requirements that refer to collaborative relationships between entities [184].

Concurrent game structure is the used transition system

The formulas of ATL are to be interpreted using a concurrent game structure as a transition system. In ordinary transition systems, each transition corresponds to a possible step of the system. In a concurrent game structure, each transition corresponds to a possible move in the game between the participating players [184].

No available suitable model checker

The MOCHA tool is the automatic model checker for reactive modules and ATL over reactive modules [291]. Reactive modules allow formal specification of heterogeneous systems with synchronous, asynchronous, and real-time components. Reactive Modules support modular and hierarchical structuring and reasoning principles [292]. Anyhow, they are not identical with concurrent game

structures [292]. No experiences or papers seem to be available that discuss similarities, differences, or possibilities to translate concurrent game structures into reactive modules.

ATL seems to capture all needed aspects to write the specification of a suitable grid authorization model, which is G-UCON in our case. Anyhow, recently and only via personal communication with the senior introducer of this logic – professor Alur from the university of Pennsylvania –, it became clear that the developers of this logic “did not consider the possibility for creation/deletion of agents” in their model checking tool – MOCHA [293]. Alur continued “I am not sure if anyone has studied this topic” [293]. This is not mentioned explicitly in any published literature, which was available during this research. Creation/deletion of agents is a very important aspect for grid computing because we have to consider grid delegation.

This is an example of how a new technology demands development in other disciplines in order to be adapted. When grid computing was introduced in the mid 1990s, the lead motivation was the increasing need for vast storage capacity. Soon after, the focus changed to supercomputing. Now, we are facing an increasing necessity to understand how this relatively new technology behaves, can be used or misused. The target goal is to be able to anticipate a future possible behavior of an entity in a grid computing environment in order to arrange accurate suitable reactions. Especially when authorization is concerned, a precision in anticipating behaviors as well as defining reactions is of a capital importance. This work captures these demands by the performed analysis and by the introduced outline for a possible solution, i.e. G-UCON.

The practice of presenting real world example for first evaluation

In nearly all access/usage control models including DAC, RBAC and UCON, a primarily validation was carried out by means of showing how the model fits to real world examples; especially examples from the different situations that motivated the design of the model. Implementations (as software) appeared years later after the development of the model and allowed a practical validation. For instance, the RBAC model was published in 1992, a first implementation within an operating system appeared in 2000 in Solaris 8 [90], next after implementation were in Windows Server 2003 [82] and Red Hat Enterprise Linux version 5 in 2007 [89].

Currently, it is difficult to build a functional authorization system for a real world grid environment using G-UCON. The validity of the G-UCON model cannot be performed likewise. A validation using available automatic model checking tools is currently not possible because these tools do not allow us to consider a grid delegation process. Therefore, we restrict ourselves in this work to informal validation by providing multiple examples (see subsection 5.2), which show how G-UCON can capture the design objectives; primarily, modeling authorization for grid computing.

The contribution of this work in light of these limitations

G-UCON delivers a concept of minimal requirements for a suitable authorization model for medical applications deployed in a grid computing environment. This concept is formulated in a quasi-mathematical way, which can currently only provide an understanding of how an authorization model for a grid computing environment should look like and how such a model should be implemented. This work derives a model on the basis of an analysis of the authorization problems in grid computing environments. Although the proposed model is described using temporal logic, in the absence of a suitable validation tool, the used mathematical formulas remain a quasi-mathematical description. Anyhow, in this context we still can describe future steps to move ahead in order to validate this model. These are included in the subsection 5.3.