gSET: Trust Management and Secure Accounting for Business in the Grid

Thomas Weishupl, Christoph Witzany, Erich Schikuta

Research Lab for Computational Technologies & Applications, University of Vienna
Rathausstrae 19/9, 1010 Vienna, Austria
Email: thomas.weishaeupl@univie.ac.at
Abstract
We developed gSET as solution for the unsolved prob-
lems in the eld of dynamic trust management and secure
accounting in commercial virtual organizations. gSET es-
tablishes trust and privacy between entities in a Grid en-
vironment by adapting the concept of Secure Electronic
Transactions (SET) used for electronic credit card transfers
in eBusiness. Trust is necessary for Grid participants in a
business environment. It is also necessary to support the dy-
namic manner of real markets. As distinguished function, in
opposite to existing mechanisms as GSI/CAS/VOMS, gSET
allows the user to obtain access to a service without disclos-
ing his credentials to the service provider. This minimizes
the service providers administrative effort needed for user
account management. gSET consists of Grid Services im-
plemented with WSRF/GT4. gSET is an enabling step to
make Grids a platform for commercial workows.
1 Introduction
Trust and security are often claimed in Grid computing
as one of the functional differences to earlier developments
in the Web and distributed computing [6]. Beyond organiza-
tional boundaries, virtual organizations need a trustable and
secure infrastructure to utilize autonomic resources and ser-
vices. Security describes a eld of activities to guarantee the
privacy, integrity and availability of resources [5, chap.7].
For a commercial promotion and provision of services
it is necessary to provide secure accounting mechanisms,
which guarantee the credit-worthiness of the requester and
the privacy of the requester. The authorization to a service
would only be granted to a requester by a provider, if the
provider trusts in the service requester credit-worthiness.
Furthermore, the service requester would only access a ser-
vice, if it is guaranteed that its private data (e.g. payment
1
The work described in this paper was supported by project number
10547 of the OeNB Anniversary Fund.
data, accounting data, credit card number, etc.) can not be
abused by the service provider.
The two key requirements are dynamic authorization
(trust management) and privacy for the requesters account-
ing data.
These requirements need to be fullled in order to es-
tablish advanced trust for both participants, which are the
service requesters and the service provider.
Trust is related to condence. Trust is a human attitude
and results from experience and moral certainty [7]. Moral-
ity describes the attitude of a person. The condence can be
established also by the experience of a trusted third party.
The trust and credential management in a commercial
context has to handle hidden (covered), but trustable infor-
mation. A business partner should not know all private in-
formation from a partner, as credit rating or payment details
(credit card numbers), but he needs to trust in them for ac-
cepting a business. Secure Electronic Transaction (SET)
[14, 15, 16] was developed for this concern. The dual sig-
nature is the key mechanism inside SET.
gSET [22] adapts the concept of SET and the dual sig-
nature for virtual organizations (Grids). Trust management
in a commercial, business environment e.g. for ASPs needs
to manage condent service requester information, as ac-
counting data and resource usage data.
Existing trust management solutions, like the ones dis-
cussed in the related work section below, do not fulll the
two key requirements for trust and requester privacy. There
are no already existing solutions yet, and even combining
available methods provides no satisfying remedy for this
concern.
The paper is structured in the following sections. First,
we describe the related work for trust management and ac-
counting and underline the differences to gSET. Section 3
explains the concept of SET with the dual signature mecha-
nism. We specify in detail the gSET architecture and work-
ow in Section 4. Section 5 focuses on the implementation
of gSET with WSRF/GT4. Finally, Section 6 presents a
gSET enabled storage service as gSET use case and dis-
cusses the performance and functional impacts.
2006 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for
advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or
to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
2 Related work
There are already different approaches for the manage-
ment of trust, policy, and authorization in Grids. A good
overview is given by [10, V.]. The privacy for accounting
and payment is commonly an open issue.
As already mentioned, basic security services in Grids
are provided by PKI. The quality of PKIs highly depend
on the management of the certicates and the education of
the users. Certication authorities (CAs) need to verify the
identity of all participants (users and resources, services).
Many bureaucratic and technical challenges are related to
issuing a certicate (photo ID of users, etc.). The organiza-
tional effort is high. By PKI a strong authentication mecha-
nism is provided.
Nevertheless, the authorization of users, the insight of
who performs which actions to specic services is not
solved by the users authentication alone. Dynamic, ad-hoc
authorizations are not possible.
A rst approach to manage authorization assertions was
done by GSI with gridmap les. It utilizes directly the
user certicate identiers and maps them to local user ac-
counts. The scalability of the gridmap le approach is lim-
ited. The account administration (trust management) to au-
thorize users is a hard task to the involved participants. The
trust management by gSET provides account management
without organizational overhead for the service provider.
Community Authorization Service (CAS) [8] allows to
express policies regarding resources distributed across a
number of sites. Similar, the Virtual Organization Member-
ship Service (VOMS) [21] also gives the capability to pro-
vide authorization information by a secure server that the
local site has chosen to trust. In opposite to gSET, CAS and
VOMS do not give the capability for interchanging anony-
mous trustable data and do not offer dynamic account man-
agement. The three different services have no dependencies
among each other. At GGF13, OGSA-WG [13, p.18] un-
derlined that no real solution for VO management exists.
OASIS WS-Security provides encryption and signing
mechanism, which are partially used by gSET.
WS-Trust and WS-Federation provide methods for issu-
ing, renewing, and validating security tokens, and ways to
establish, assess the presence of, and broker trust relation-
ships. WS-Trust does not enable condent trustable mes-
sages, passing by the service provider in a hidden form, as
gSET does.
SAML [17] and XACML [18] are XML-based ap-
proaches for authorization queries and authorization policy
statements. These specications do not concern hidden pri-
vate data, which has to be veried for granting access. Shi-
booleth [11] implements SAML, but it does not provide ac-
counting and payment facilities.
GridBank [3] provides services for accounting. Our
gSET approach can integrate this capability and supports
also other accounting modules, by the account provider, ex-
plained in detail below. No wrapper was built until now
for GridBank, because gSET is already implemented with
WSRF.
SwdGrid Grid Accounting System (SGAS) [20] can also
be integrated and gSET provides an accounting enabled
third party authorization service.
All stated deciencies of the mentioned approaches give
a case for gSET resolving these weaknesses.
3 Secure Electronic Transaction (SET)
SET [14, 15, 16] enables highly secure credit card trans-
actions on the Internet. It allows the secure transfer and
verication of credit card information between two busi-
ness partners. SET was developed by MasterCard, Visa, and
others intended to enhance privacy and security for online
transactions.
In a SET transaction, the payment information is hidden
from the merchant, but the merchant can verify the infor-
mation (e.g. credit card limit) through a payment gateway
trusted by both sides. Vice versa, the payment gateway (in-
cluding the issuer and brand) can not read the condent or-
der information. Nevertheless, the integrity of the whole
message can be veried by both parties. The mechanism
providing this functionality in SET is called dual signature.
The dual signature separates the payment from the order in-
formation in a way that allows verifying the integrity of the
data without disclosing all information and thus ensuring
privacy.
To achieve this, both message parts are hashed, the
hashes are concatenated and signed. Each receiver then gets
his message part and the hash of the other part. By hashing
his part of the message and concatenating this hash with the
received hash of the other message part he can then verify
the integrity of the message.
SET was not commercially successful. SET could not
prevail due to the lacking public key infrastructure on the
web, complicated usability for the customers, low accep-
tance rate, and low dissemination. The SET infrastructure
was discontinued by the credit card companies four years
ago. With gSET the main reason for the failed SET does not
exist, because Grids already have public key infrastructures
and now public applications as e-government (Brgerkarte
[4], etc.) provide high quality certicates (including photo
IDs) which can be reused in gSET.
4 gSET
By gSET it is possible for a service requester (client,
user, consumer, card holder) to access a service (resource),
Figure 1. gSET Architecture
receiving credentials by automated software interactions
dynamically without having any credentials for it before.
The criteria are user credit rating, reliability, trustworthi-
ness or other user properties, veried by a third party ac-
count management service and are not disclosed to the ser-
vice provider.
gSET allows a service to verify and decide, if it will trust
and grant access to a user. In the other direction it is also
possible for a user to ensure the delivery of the service with
the agreed quality, because the real payment is delayed like
with real credit cards, and can be revoked by the service
requester at the account provider. gSET provides not only
condentiality, but allows also to handle the economic and
commercial attributes of a resource, and handles trust and
authorization.
gSET is a higher security service [9, p.285]. It is an ad-
vanced authorization mechanism, with integrated account-
ing and privacy, based on the basic security services, which
are condentiality, data integrity, and authentication. In
Grids public key infrastructures (PKIs) are used to provide
the basic security services (e.g. TeraGrid, DataGrid, Grid-
bus and others).
The adoption of gSET is obvious and simple, because
of the existing PKIs in Grids. The certicate management,
the establishment of a reliable PKI, and its usability was
one of the reasons, that SET had no commercial success in
eBusiness. A prerequisite is a strong certicate policy with
e.g. photo IDs to ensure the quality of all signature and
encryption mechanisms used in gSET.
4.1 Architecture
With gSET we provide an approach to construct services,
which use the SET workowto authorize requesters dynam-
ically. gSET provides a secure accounting mechanism.
Figure 1 shows the overall gSET architecture. Like SET
itself, gSET conceptually relies on a four tier architecture.
This enables a maximum distribution and redundancy for
the dynamic management of trust and authorizations to ser-
vices. The actors in the gSET architecture are respectively
clients, account providers, service providers, and trust man-
agers.
Clients are service requesters. In the SET concept this
is originally the consumer (card holder). It is required to
have an account issued by an account provider. The ser-
vice requester is unknown to the service provider before the
beginning of the initial request of a service.
Account providers are like credit card companies (brand,
issuer) in the original SET concept. They issue accounts
(credit cards) and have a trust relation to their customers.
How this trust was earned depends on the business context.
It can be a bank account with a certain amount or other rela-
tions. Account providers trust in the behavior of clients by
certain assurances (e.g. monetary entities or organizational
relations).
Service providers make services available. For example
they provide storage space etc. In the original SET concept
they were the online sellers (merchant). They need at least
a relation to one trust manager as a gateway to an account
provider. By this the service provider gets guarantees about
the clients behavior without harming the privacy of clients.
Trust managers are the link between the service
providers and the account providers. They manage the pay-
ment and verify the accounts of the clients at the account
provider. In the original SET concept this was the payment
gateway. The trust manager must have a contract with the
clients account provider to establish a successful authoriza-
tion. One trust manager can handle the gateway requests to
different account providers.
The authentication of all parties is done through valid
and trusted certicates. Grids PKI provides this inherently
with a network of CAs and certicates for users, hosts and
services.
4.2 Workow
Figure 2 describes the standard gSET workow, which
is used by services to authorize unknown clients. The upper
gure shows the preconditions for a gSET transaction, also
called initial state. The lower gure describes the interac-
tions of one specic authorization (transaction).
The initial state is as follows. The client has a valid ac-
count froman account provider. The service provider has an
established relation with at least one trust manager. The ser-
vice provider needs to know the endpoint address to pass on
the authorization request. Later it needs to verify if the trust
manager has a contract with the clients account provider.
Further, an interconnect exists between trust managers and
account providers, by which a specic service provider and
a specic client are related logically.
The trust manager relays the authorization information
Figure 2. gSET Workow
to the account provider. It also provides a list of account
providers it has contracted. The trust manager can be tied
closely to one or more account providers. The account
provider guarantees for the expected client behavior and
eventual payments which are involved in the transaction.
How a client nds a proper service is not addressed by
gSET, because already different solutions exist, as Grid In-
formation Services GT4 MDS, UDDI, or LDAP etc. After
the agreement between client and service on certain quality
and quantity characteristics (e.g. cpu time, max costs, etc.)
of a client request the gSET authorization to this resource
can start. The gSET transaction includes several steps de-
scribed below and marked in Figure 2 (lower image):
1. The client wants to access an already negotiated re-
source. It contacts the service provider to initiate
the transaction sending the identier of its account
provider.
2. After receiving the necessary certicates the client
software constructs the two part message and the dual
signature, which is used to authorize the client for the
service.
The rst part is the service request part, which is
addressed to the service provider and contains the
request information depending on the service type,
like order information. It is encrypted using the
service providers public key provided by the cer-
ticate sent to the client before.
The second part is the authorization request part,
which is addressed to the trust manager and con-
tains the payment information. These are account
information of a specic account provider together
with the amount and the currency of the service
provider costs, on which the client and service
agreed before the transaction. This part of the mes-
sage is then encrypted using the trust managers
public key to be tunneled to the trust manager via
the service provider.
The hashes of both parts are calculated and attached
to the message. Finally the client calculates the dual
signature by concatenating and signing the two hashes
and sends the request
3. In this step the client sends the two part message to the
service provider. On receiving the two part message
from the client the service provider checks the mes-
sage integrity. It decrypts the service request part of the
message and calculates the hash. Then the computed
hash is concatenated with the included hash of the au-
thorization request part of the message. This dual hash
is compared to the hash included in the message. Fi-
nally the dual signature is validated.
4. If all validations are nished correctly, the service
provider contacts the trust manager, relaying the au-
thorization request part as well as the dual signature
and a hash of the service request part of the message.
It also includes amount and currency which are to be
authorized.
On receiving the authorization request fromthe service
provider, the trust manager checks the integrity of the
message. It decrypts the authorization request message
and calculates its hash. This hash and the hash of the
service request part of the message received from the
service provider are concatenated and compared to the
also relayed dual hash. Finally, the dual signature is
veried. If the message integrity is asserted the amount
and currency sent to the trust manager by client and
service provider are compared.
5. All this being successful, the trust manager contacts
the account provider asking for authorization.
6. The account provider checks the clients prole and
liquidity. If the client has sufcient credits the account
provider conrms the clients trustworthiness.
7. The trust manager sends the conrmation back to the
service provider along with a token representing an
eventual fee for the service usage.
8. The result of the authorization request is also passed
through to the client. The service provider grants now
access to the requested resources. If the result was
negative, the resource request is ignored by the service
provider.
Later, after the resource was consumed by the client, the
service provider can use the token it received from the trust
manager to collect the fee for its services. When the ser-
vice provider sends back the token to collect the fee, the
trust manager contacts the account manager to arrange the
transaction.
5 Implementation
The gSET proof-of-concept implementation is based on
the Globus Toolkit 4 (GT4) with its Java web service con-
tainer. To gSET enable any OGSA WSRF service it is
only necessary that the service provider derives his service
and resource from the gSET components. Thus any WSRF
Globus can be gSET enabled. The service provider and trust
manager of gSET are modeled as stateful WSRF web ser-
vices.
gSET uses only internally the PKI certicate manage-
ment of GT4, the client therefore needs a valid Globus key
pair. The authentication and integrity of the conversation
between the client and the service is established by the
transport level security (TLS) of Globus. We applied TLS
because of performance reasons, but gSET works also by
message level security (Secure Message and Secure Con-
versation).
The authorization to services is only managed by gSET
and does not require any Globus authorization services.
The dual signature functionality of gSET is built on top
of the encryption, decryption, and signing mechanisms of
the Apache XML security [2], the WSS4J [1] and JCE [12],
all provided by GT4 and J2SE.
This section describes in three subsection the WSRF im-
plementation of the trust manager, the service provider, and
the account manager.
5.1 Trust Manager
gSET includes a skeleton implementation of a trust man-
ager. The trust manager service provides the following four
operations:
getCertificate
getAccountProviderList
createManagedTrust
collectPayment
The relation between trust manager and service provider
is initialized by the getCertificate operation. The re-
ceived certicate is sent to the client at the initiation of a
transaction. This operation does not take any input parame-
ters and TLS is used to ensure integrity. As the certicate is
public, privacy is not necessary.
The operation getAccountProviderList returns
a list of URIs of account providers contracted by the trust
manager. This operation also does not take input parame-
ters, and uses TLS to ensure integrity but does not require
privacy.
On Step 4 of the gSET workow, the operation
createManagedTrustis called by the service provider.
As input parameters this operation requires three parts.
These are the encrypted authorization request sent by the
client, the complementary message by the service provider,
and the hash of the service request. The complementary
message must contain the transaction id, amount and cur-
rency tting to the corresponding values in the clients mes-
sage.
The complementary message is signed and encrypted by
a hybrid method.
If all checks on integrity and the request for authoriza-
tion by the account manager succeed, a resource is created
holding amount and currency. Further a token is generated
and sent back to the service provider after being signed and
encrypted. This operation does not use any of the GT4 em-
bedded security mechanisms. Everything is encrypted and
signed directly by the services.
The generated token is cashed by the operation
collectPayment. This method uses TLS to guarantee
integrity and privacy of the contents.
5.2 Service Provider
gSET includes the abstract class GSETServiceProvider
implementing the logic of a service provider to handle au-
thorization requests and a WSDL le.
The WSRF resource must contain the following prop-
erties: gSETauthorization of the type boolean indicates if
the authorization was successful. gSETaccountProvider of
the type URI holds the identier of the clients account
provider. gSETtransactionID contains the transaction id
generated by the service. gSETtoken stores the token re-
ceived from the trust manager. Additional resource proper-
ties are possible and depend on the specic service type.
gSET contains the abstract class GSETResource that of-
fers to service providers an implementation of the resource
properties.
To allow SET enabled authorization, the service must
implement at least the following two operations:
getOffer
initiateTransaction
requestAuthorization
The client requests by the getOffer operation an offer
for a specic service request (e.g. data volume size, etc.).
It is an agreement over the QoS and payment, which will
be authorized by both parties by gSET. The client can de-
cide now if he accepts the offer and requests the service
together with an authorization of the offer by the following
steps. The getOffer operation calls in any specic gSET
enabled service an evaluation method, which is also used
later during the gSET transaction for verifying the agree-
ment against the service request.
The client states with the initiateTransaction
operation that it wants to access the service and provides
in this step the URI representing its account provider. The
service provider creates a WSRF resource and initiates the
gSET properties mentioned above. The client receives as
response a transaction id, an endpoint reference, and the
certicates of trust manager and service provider. This op-
eration uses the GT4 TLS to ensure the integrity of the mes-
sage. There is no need to hide anything at this stage.
The request for authorization is done by calling
serviceRequest which takes the two part message as
parameter. These are the two parts described in Step 2 of
the previous section, respectively the service request part
and the authorization request part.
The service request part can consist of anything that can
be put into a SOAP message part. The content of the ser-
viceRequest element is rst hashed and then encrypted by
the Apache XML security library using a generated sym-
metric key. The key is encrypted with the service providers
public key and attached to the message along with the hash
of the service request.
The authorization request part consists of the transaction
id generated by the service provider, the identier of the
clients account provider, and the amount and currency to
be authorized.
The content of the authorizationRequestType element is
treated in the same way as the service request, only that the
public key used is the one of the trust manager rather than
the service providers.
The two generated hashes are then concatenated and
form the dual hash, which is also attached to the message
and signed, using the clients private key.
When the service receives the message it checks the in-
tegrity as described in the previous section. It decrypts the
service request part of the message and calculates the hash.
This hash is concatenated with the hash of the authorization
request part which is also contained in the message. The re-
sult is compared to the dual hash sent by the client. If they
are equal, the integrity of the dual hash is veried using the
clients public key.
5.3 Account Provider
The account provider manages the private client infor-
mation. The interface of the gSET account provider has the
following operations:
checkAuthorization
transferCredits
The operation checkAuthorization is called on
Step 5 of the gSET workowby the trust manager. If the au-
thorization can be granted according to the clients liquidity
it returns true, otherwise false. Furthermore, the authorized
amount is stored in the account for the real payment trans-
fer. The operation uses TLS to ensure integrity and privacy
of the message content.
The operation transferCredits is used by the ser-
vice provider to invoke the payment transfer process. Be-
fore performing the transfer, the requested amount is com-
pared to the previously authorized amount. TLS is used to
ensure privacy and integrity.
6 gSET Use Case and Evaluation
The dynamic gSET authorization minimizes the admin-
istrational effort for loosely coupled virtual organizations
and provides accounting and privacy for the service re-
quester.
Grids enable the distribution of workload and are highly
dynamic. For business concerns and building a real market,
it is not adequate to participants to manage certicates for
ad-hoc authorizations. Furthermore, it is a must to guaran-
tee the privacy of the participants.
A storage provider can offer a storage service to un-
known clients, because the service requester earns the
needed trust by the trust manager. The trust manager relates
the clients request to its account provider.
A service requester (customer) needs to store its data in
a storage service. Furthermore, he wants to ensure that his
privacy is not violated. To ensure the privacy he can use
strong encryption mechanism for his data, so that the stor-
age provider can not access the information in the data. The
transaction data are secured by gSET. For the requester the
payment transaction takes place after the consumption of
the service, like with real credit card payments. If the re-
quester has not got the service in the agreed QoS, he can
make a reclamation at the account provider.
On the other hand, the storage provider is not interested
in details about the data and respects the privacy of its cus-
tomer. Nevertheless the provider needs to ensure that the
requester is trustable and pays for the used storage.
In a market of service providers the policy is quite sim-
ple. The provider sells to anybody who does not have any
legal or rating problem. By gSET it is possible to trans-
fer the permission to check this information for one specic
transaction, but without disclosing the private information.
Any GT4 service can be gSET enabled easily by the
implementation described in the previous section. We im-
plemented an exemplary WSRF storage service. Java was
used as development language. The WSRF storage ser-
vice contains three basic storage operations storeData,
getData, and destroyData. The resource class holds
the storage location and the allocated size for the data. The
storeData operation creates a resource for storing the
transferred data.
There are only slight changes to an existing storage
provider to enable it for gSET authorization, described as
follows:
1. The service provider class is derived from the abstract
class GSETServiceProvider.
2. The service providers WSRF resource class needs to
be derived from the abstract class GSETResource.
3. To extract the service request, the method ser-
viceRequest in the service provider class has to be
overridden. After calling the super method the detailed
service request information can be processed.
4. The storeData method has to be adapted. If the WSRF
resource does not exist, the data must not be accepted,
because there was no successful authorization before.
5. The Service Provider module also needs a way to
determine the price for a given request. If the ser-
vices class is derived from GSETServiceProvider,
this can be achieved conveniently by overriding
the protected method evaluateRequest. Other-
wise the module looks for the global JNDI property
gSETRequestEvaluator. This property should
point to a class implementing the interface GSETEval-
uator. If such a property is found, the class is loaded
and the method evaluate is called on it.
The real data transfer is out of the scope of gSET. The
storeData operation of our use case implementation does
include the data directly in the message. Nevertheless, redi-
rects to other data transfer services, as GridFTP/RFT are
possible.
The use case implementation is freely available for
download on the project webpage [22]. We applied the stor-
age service in the N2Grid [19] project for managing arti-
cial neural network data. The screen shot of the example
client for the gSET enabled storage service is available on
the project webpage.
The screen shot shows that the getOffer method of gSET
is called to agree on a certain QoS/price by the Get Of-
fer button. The authorization and service request takes
0%
20%
40%
60%
80%
100%
120%
140%
160%
180%
200%
0,1 1 10 100 1000 10000
WorkIoad [kB]
g
S
E
T
/
g
r
i
d
m
a
p

[
%
]
Overhead
Figure 3. Overhead of gSET versus gridmap
place by Start Transfer. On the Retrieve panel all refer-
ences of the successful data transfers are stored, which can
be retrieved by the getData operation and deleted by the
destroyData operation.
6.1 Evaluation
We evaluated gSET by comparing the gSET enabled
storage service with same storage service based only on
GT4, respectively these services are called in the following
gSETstore and gt4store. The gt4store service had addition-
ally a separate getOffer method, because it does not inherit
the method from gSET.
The gt4store service uses gridmap le authorization and
does not provide the following functions without violating
the requesters privacy:
Secure accounting
Verication of requester credit rating
Dynamic authorization
The services were deployed in a GT4.0.1 Java core con-
tainer (with TLS) running on Debian sarge Linux (kernel
2.6.12.3), on a Dell PowerEdge 2850 with two Intel Xeon
CPU 3.60GHz processors, 4GB of RAM with 1,400 GB
storage. The Java clients run on a Windows XP worksta-
tion. The interconnection between server and client was a
switched 100MBit Ethernet.
We measured the execution time of the getOffer and
the storeData operation on client side for different work-
loads (data transfer size). The total execution time consists
of the execution time of getOffer and storeData, whereas
both execution times consist of the service execution time
(authorization time, request processing) , the transfer time
(network latency and throughput, TLS), and the client time
(construction of the request). Every time was measured 50
times and the median was used for the statistical analysis.
The differences in the total execution time between the
1
10
100
1000
10000
0,5 1 5 10 50 100 500 1024 5120
WorkIoad [kB]
T
o
t
a
I

E
x
e
c
u
t
i
o
n

T
i
m
e

[
m
s
]
gSET
gridmap
Figure 4. Total Time of gSET and gridmap
gSETstore and the gt4store result only from the authoriza-
tion time differences. As expected, the getOffer execution
time of both services are equal for any workload, because
no authorization is required and done.
Figure 3 shows the relative overhead of gSET versus
gridmap authorization. The overhead is qualied because
of the functional advances of gSET. By increasing the work-
load the authorization overhead decreases relatively, there-
fore Figure 3 shows that the gSET overhead is nearly con-
stant for small workloads. Nevertheless, the curve decreases
because of the dominance of the request processing time for
high workloads and the negligible authorization time.
Figure 4 shows the absolute execution times of gSETser-
vice and gt4service calls for different workload. It shows
that the execution time for small workloads (storing 512
Byte up to 50kB) is constant. This shows that the request
processing time can be neglected for calculating the real
overhead of gSET for small workloads.
7 Conclusion
Summing up, gSET enables trust management in loosely
coupled commercial virtual organizations with inherent se-
cure accounting and privacy.
Transparent access to different service providers is
granted by a trust manager / account provider network. An
underlaying economic model manages the authorizations
for clients by the advanced gSET service providing trust for
both parties.
Every service consumption can be authorized separately
and no static policy is required. This goes beyond the
existing virtual organization authorization framework (e.g.
VOMS/CAS).
Customer privacy in commercial environment is an im-
portant issue. gSET maintains private information of clients
condential. Nevertheless, a service provider has guaran-
tees and can trust in clients characteristics.
Consuming Grid Services with a gSET account is com-
parable to pay by a personal credit card in many different
shops without disclosing the credit card number to them.
gSET is an enabling step to make Grids a platform for
commercial workows.
References
[1] Apache. WSS4J, 2004.
[2] Apache. XML Security, 2004.
[3] A. Barmouta and R. Buyya. GridBank: A Grid Accounting
Services Architecture (GASA) for Distributed Systems Shar-
ing and Integration. In 17th Annual International Parallel and
Distributed Processing Symposium (IPDPS 2003) Workshop
on Internet Computing and E-Commerce, page 245a, Nice,
France, April 22-26, 2003. IEEE Computer Society Press.
[4] Brgerkarte, 2005.
[5] G. Coulouris, J. Dollimore, and T. Kindberg. Distributed Sys-
tems. Addison-Wesley, 3rd edition, 2001.
[6] I. Foster. What is the Grid? A Three Point Checklist. Tech-
nical report, Argonne National Laboratory and University of
Chicago, July 2002.
[7] L. Giussani. The Religious Sense. McGill-Queens, October
1997.
[8] The Globus Security Team. Globus Toolkit Version 4 Grid
Security Infrastructure: A Standards Perspective, December
8, 2004. Version 2.
[9] H. R. Hansen and G. Neumann. Wirtschaftsinformatik 1,
Grundlagen und Anwendungen. Lucius & Lucius, Stuttgart,
9th edition, 2005.
[10] M. Humphrey, M. R. Thompson, and K. R. Jackson. Security
for Grids. Proceedings of the IEEE, 93(3):644652, March
2005.
[11] Internet2/MACE. Shibboleth Project, 2005.
[12] Java Cryptography Extension (JCE), 2005.
[13] H. Kishimoto. OGSA Status and Future, March 14, 2005.
GGF13 OGSA-WG.
[14] MasterCard, VISA. SET Secure Electronic Transaction
Specication, Book 1: Business Description, May 31, 1997.
Version 1.0.
[15] MasterCard, VISA. SET Secure Electronic Transaction
Specication, Book 2: Programmers Guide, May 31, 1997.
Version 1.0.
[16] MasterCard, VISA. SET Secure Electronic Transaction
Specication, Book 3: Formal Protocol Denition, May 31,
1997. Version 1.0.
[17] OASIS. Security Assertion Markup Language (SAML) 1.0
Specication Set, November 2002. OASIS Standard.
[18] OASIS. eXtensible Access Control Markup Language
(XACML) 1.0 Specication, February 2003.
[19] E. Schikuta, H. Wanek, and T. Weishupl. Neural Networks
in the Grid. University of Vienna, 2004.
[20] SweGrid. SweGrid Grid Accounting System (SGAS), 2005.
[21] Virtual Organization Membership Service (VOMS), 2003.
[22] T. Weishupl, C. Witzany, and E. Schikuta. gSET. University
of Vienna, 2005. http://www.pri.univie.ac.at/
shrink/gSET.