Information Technology Reference
In-Depth Information
Auditing
•The signature over the microcontract (shipped
together with the GSI host certificate that was used
for signing) is compared with the Host ACL, to
see if the HPL information is trusted and if access
is allowed from this host.
The above mechanisms suffice to establish the
required combination of Host ACL and User ACL
based authorization, together with obtaining a mi-
crocontract signed by the connecting host before
the data is shipped. If all provided information
matches the data owner's requirements, the data is
shipped to the requesting job or middleware, and
the microcontract is logged in the auditor process.
Auditing is important to allow for tracing all opera-
tions on a particular data item. For convenience
and scalability, we use a trusted auditor process
per TSRB, managed by the TSRB. Copies of the
co-signed microcontracts of all transactions are
sent to and strored by the auditor. This allows the
data owners to trace all transactions that involve
a particular data item in a way that ensures non-
repudiability.
PUTTING IT ALL TOGETHER
USABILITY
Authorization of a data access requires that the
connecting job's owner is on the User ACL, that
the host on which the connecting job runs is on
the Host ACL, and that the properties in the RHPL
match the properties in the connecting host's
HPL. Authorization of a data request consists of
the following steps, assuming GSI host/Proxy
certificate based authentication.
•At connection time, the connecting process
(either a job or middleware, in case of data pre-
fetching) authenticates with the TSRB using the
job's Proxy certificate, resulting in an authenti-
cated and encrypted SSL/TLS channel.
•The information from the Proxy certificate is
matched against the User ACL to see if access is
allowed. If not, an error is returned that does not
indicate whether the data exists or not.
•The TSRB and the connecting process engage
in a protocol for matching RHPL and HPL proper-
ties. If the connecting process is the middleware
(e.g., during data pre-fetch), it can directly sign
the microcontract. If the connecting process is a
job, it has to request its local middleware (using
a runtime interface) to match the RHPL of the
TSRB with the host's HPL, and to have it sign
a microcontract on its behalf if these properties
match. The microcontract includes the (hash over
the public key of the) Proxy certificate of the job
to which it was issued.
Determining an appropriate Host ACL and HPL
specification may be difficult for non-technical
data owners. However, system administrators who
support users may define template (R)HPLs with
basic properties that hosts must adhere to when
running jobs that access sensitive information.
Such templates may be provided with the client-
side software used for data uploading, and may
be adapted by data owners and/or local system
administrators at the time of use. Similarly, lo-
cal (VO) administrators may help by composing
default lists of trusted domains for particular data
types or groups of users. Such measures allow
secure usage of the system by researchers without
burdening them with too many details. Dynamic
adaptation of RHPLs for long-term storage of
data is an open issue that needs to be addressed.
CURRENT STATUS AND
FUTURE WORK
We have implemented a proof-of-concept imple-
mentation of the TSRB framework based on a
gridFTP server from the Globus toolkit. We ex-
tended the gsi-FTP server with an authenticated
key-exchange protocol to authenticate the client
Search WWH ::
Custom Search