A Policy-Based Security Framework for Privacy-Enhancing Data Access and Usage Control in Grids - Cloud, Grid and High Performance Computing: Emerging Applications - page 130

• Additional identifiers for projects, Grid

jobs, and their components, such as code,
input data, and output data are required.
Similarly to user modeling, i.e., the defi-
nition of which information can be stored
and retrieved about users, it is impractical
to stick to a predetermined set of elements;
instead, the involved organizations must
agree on the granularity of the policies
and on a common vocabulary to be used in
these policies.

adaptations described in the previous section to
a privacy management framework which was
designed for use in real-world FIM scenarios (see
Hommel, 2005b; Boursas & Hommel, 2006). It is
based upon the eXtensible Access Control Markup
Language (XACML) (Moses, 2005) and uses a
URI-style namespace for SP and user attribute
specification. It has been implemented for the
Shibboleth FIM software and thus is also suitable
for use in Grid middleware projects such as Grid-
Shib (Welch, Barton, Keahey, & Siebenlist, 2005).
Like most modern policy languages, XACML
supports scenario-specific vocabulary, e.g., for the
specification of obligations, without the necessity
to extend the internal PDP workflows; thus, any
standard compliant XACML PDP can be used
also for our Grid job policies. We have extended
the previously used namespace in order to support

• New conditions and obligations are re-

quired, for example to state that a Grid
job's code may be modified by the SP for
optimization purposes. Also, obligations
such as data retention limits will typically
differ between personal data and Grid job
data: For example, a Grid job's input data
often shall be deleted after the job has fin-
ished, while the user's billing address can
only be deleted after the invoice has been
settled. Again, the complete definition of
the necessary vocabulary is a task that is
specific to each Grid environment, and
standardization is required to provide a
common subset of the vocabulary.

• the definition of and referring to arbitrary

groups of service providers as well as VO
identifiers (for VO management approach-
es, see Kirchler, Schiffers, & Kranzlmüller,
2009).

• the specification of Grid projects as groups

of Grid jobs, the Grid jobs themselves, and
their components; the granularity chosen
for the components is code , input , and out-
put . This granularity is a trade-off between
very fine grained control and the imple-
mentation effort required at each involved
SP.

On the service provider side, no extensions
to the privacy management architecture are re-
quired, with exception of support for any newly
defined obligations. However, in practice so far
only a limited number Grid SPs supports privacy
management at all; the challenge of integrating
the described privacy management components
into Grid-specific workflows is discussed below.

• new conditions, such as (allow/disallow)

optimization (of code) and (allow/disal-
low) backup (of code, input, or output) , as
well as new obligations, e.g., delete-after-
execution (of input or code) .

APPLICATION OF THE
SECURITY FRAMEWORK TO
A XACML-BASED PRIVACY
MANAGEMENT ARCHITECTURE

Figure 4 shows an example of a Grid job policy,
which allows all Grid service providers to modify
the code for the purpose of optimizations w.r.t.
the local computer architecture. Note that XML
namespaces have been omitted in the example
to improve the readability of the XML fragment.

In order to show the feasibility of the presented
approach, we have applied the extensions and