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

Transcription

1 gset: Trust Management and Secure Accounting for Business in the Grid Thomas Weishäupl, Christoph Witzany, Erich Schikuta Research Lab for Computational Technologies & Applications, University of Vienna Rathausstraße 19/9, 1010 Vienna, Austria Abstract We developed gset as solution for the unsolved problems in the field of dynamic trust management and secure accounting in commercial virtual organizations. gset establishes trust and privacy between entities in a Grid environment 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 dynamic 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 disclosing his credentials to the service provider. This minimizes the service provider s administrative effort needed for user account management. gset consists of Grid Services implemented with WSRF/GT4. gset is an enabling step to make Grids a platform for commercial workflows. 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 organizational boundaries, virtual organizations need a trustable and secure infrastructure to utilize autonomic resources and services. Security describes a field 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 service, if it is guaranteed that its private data (e.g. payment 1 The work described in this paper was supported by project number 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 accounting data. These requirements need to be fulfilled in order to establish advanced trust for both participants, which are the service requesters and the service provider. Trust is related to confidence. Trust is a human attitude and results from experience and moral certainty [7]. Morality describes the attitude of a person. The confidence 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 information. A business partner should not know all private information from a partner, as credit rating or payment details (credit card numbers), but he needs to trust in them for accepting a business. Secure Electronic Transaction (SET) [14, 15, 16] was developed for this concern. The dual signature is the key mechanism inside SET. gset [22] adapts the concept of SET and the dual signature for virtual organizations (Grids). Trust management in a commercial, business environment e.g. for ASPs needs to manage confident service requester information, as accounting data and resource usage data. Existing trust management solutions, like the ones discussed in the related work section below, do not fulfill 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 accounting and underline the differences to gset. Section 3 explains the concept of SET with the dual signature mechanism. We specify in detail the gset architecture and workflow 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 discusses the performance and functional impacts.

2 2 Related work There are already different approaches for the management 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 certificates and the education of the users. Certification authorities (CAs) need to verify the identity of all participants (users and resources, services). Many bureaucratic and technical challenges are related to issuing a certificate (photo ID of users, etc.). The organizational effort is high. By PKI a strong authentication mechanism is provided. Nevertheless, the authorization of users, the insight of who performs which actions to specific services is not solved by the user s authentication alone. Dynamic, ad-hoc authorizations are not possible. A first approach to manage authorization assertions was done by GSI with gridmap files. It utilizes directly the user certificate identifiers and maps them to local user accounts. The scalability of the gridmap file approach is limited. The account administration (trust management) to authorize 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 Membership Service (VOMS) [21] also gives the capability to provide 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 anonymous trustable data and do not offer dynamic account management. The three different services have no dependencies among each other. At GGF13, OGSA-WG [13, p.18] underlined 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 issuing, renewing, and validating security tokens, and ways to establish, assess the presence of, and broker trust relationships. WS-Trust does not enable confident trustable messages, passing by the service provider in a hidden form, as gset does. SAML [17] and XACML [18] are XML-based approaches for authorization queries and authorization policy statements. These specifications do not concern hidden private data, which has to be verified for granting access. Shibooleth [11] implements SAML, but it does not provide accounting 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, explained 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 deficiencies 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 transactions on the Internet. It allows the secure transfer and verification of credit card information between two business 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 information (e.g. credit card limit) through a payment gateway trusted by both sides. Vice versa, the payment gateway (including the issuer and brand) can not read the confident order information. Nevertheless, the integrity of the whole message can be verified by both parties. The mechanism providing this functionality in SET is called dual signature. The dual signature separates the payment from the order information 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 acceptance 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 (Bürgerkarte [4], etc.) provide high quality certificates (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),

3 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, trustworthiness or other user properties, verified by a third party account management service and are not disclosed to the service 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 confidentiality, 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 advanced authorization mechanism, with integrated accounting and privacy, based on the basic security services, which are confidentiality, data integrity, and authentication. In Grids public key infrastructures (PKIs) are used to provide the basic security services (e.g. TeraGrid, DataGrid, Gridbus and others). The adoption of gset is obvious and simple, because of the existing PKIs in Grids. The certificate 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 certificate 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 workflow to authorize requesters dynamically. 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 services. The actors in the gset architecture are respectively clients, account providers, service providers, and trust managers. 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 service 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 relations. 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 client s behavior without harming the privacy of clients. Trust managers are the link between the service providers and the account providers. They manage the payment 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 client s account provider to establish a successful authorization. One trust manager can handle the gateway requests to different account providers. The authentication of all parties is done through valid and trusted certificates. Grid s PKI provides this inherently with a network of CAs and certificates for users, hosts and services. 4.2 Workflow Figure 2 describes the standard gset workflow, which is used by services to authorize unknown clients. The upper figure shows the preconditions for a gset transaction, also called initial state. The lower figure describes the interactions of one specific authorization (transaction). The initial state is as follows. The client has a valid account from an account provider. The service provider has an established relation with at least one trust manager. The service 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 client s account provider. Further, an interconnect exists between trust managers and account providers, by which a specific service provider and a specific client are related logically. The trust manager relays the authorization information

4 request information depending on the service type, like order information. It is encrypted using the service provider s public key provided by the certificate sent to the client before. The second part is the authorization request part, which is addressed to the trust manager and contains the payment information. These are account information of a specific 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 message is then encrypted using the trust manager s 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 Figure 2. gset Workflow 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 finds a proper service is not addressed by gset, because already different solutions exist, as Grid Information 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 described below and marked in Figure 2 (lower image): 1. The client wants to access an already negotiated resource. It contacts the service provider to initiate the transaction sending the identifier of its account provider. 2. After receiving the necessary certificates the client software constructs the two part message and the dual signature, which is used to authorize the client for the service. The first part is the service request part, which is addressed to the service provider and contains the 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 message 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 authorization request part of the message. This dual hash is compared to the hash included in the message. Finally the dual signature is validated. 4. If all validations are finished correctly, the service provider contacts the trust manager, relaying the authorization 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 from the 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 verified. 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 client s profile and liquidity. If the client has sufficient credits the account provider confirms the client s trustworthiness.

5 7. The trust manager sends the confirmation 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 service 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 container. 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 services. gset uses only internally the PKI certificate management 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 Conversation). 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 implementation of the trust manager, the service provider, and the account manager. 5.1 Trust Manager gset includes a skeleton implementation of a trust manager. 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 received certificate is sent to the client at the initiation of a transaction. This operation does not take any input parameters and TLS is used to ensure integrity. As the certificate 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 parameters, and uses TLS to ensure integrity but does not require privacy. On Step 4 of the gset workflow, the operation createmanagedtrust is 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 currency fitting to the corresponding values in the client s message. The complementary message is signed and encrypted by a hybrid method. If all checks on integrity and the request for authorization 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 embedded 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 authorization requests and a WSDL file. The WSRF resource must contain the following properties: gsetauthorization of the type boolean indicates if the authorization was successful. gsetaccountprovider of the type URI holds the identifier of the client s account provider. gsettransactionid contains the transaction id generated by the service. gsettoken stores the token received from the trust manager. Additional resource properties are possible and depend on the specific service type. gset contains the abstract class GSETResource that offers 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

6 initiatetransaction requestauthorization The client requests by the getoffer operation an offer for a specific 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 decide 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 specific gset enabled service an evaluation method, which is also used later during the gset transaction for verifying the agreement 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 certificates of trust manager and service provider. This operation uses the GT4 TLS to ensure the integrity of the message. 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 servicerequest element is first hashed and then encrypted by the Apache XML security library using a generated symmetric key. The key is encrypted with the service provider s 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 identifier of the client s 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 provider s. The two generated hashes are then concatenated and form the dual hash, which is also attached to the message and signed, using the client s private key. When the service receives the message it checks the integrity 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 result is compared to the dual hash sent by the client. If they are equal, the integrity of the dual hash is verified using the client s public key. 5.3 Account Provider The account provider manages the private client information. The interface of the gset account provider has the following operations: checkauthorization transfercredits The operation checkauthorization is called on Step 5 of the gset workflow by the trust manager. If the authorization can be granted according to the client s liquidity it returns true, otherwise false. Furthermore, the authorized amount is stored in the account for the real payment transfer. The operation uses TLS to ensure integrity and privacy of the message content. The operation transfercredits is used by the service provider to invoke the payment transfer process. Before performing the transfer, the requested amount is compared 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 administrational effort for loosely coupled virtual organizations and provides accounting and privacy for the service requester. 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 certificates for ad-hoc authorizations. Furthermore, it is a must to guarantee the privacy of the participants. A storage provider can offer a storage service to unknown clients, because the service requester earns the needed trust by the trust manager. The trust manager relates the client s 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 storage 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 requester 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 customer. 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 simple. The provider sells to anybody who does not have any

7 legal or rating problem. By gset it is possible to transfer the permission to check this information for one specific transaction, but without disclosing the private information. Any GT4 service can be gset enabled easily by the implementation described in the previous section. We implemented an exemplary WSRF storage service. Java was used as development language. The WSRF storage service 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 provider s WSRF resource class needs to be derived from the abstract class GSETResource. 3. To extract the service request, the method servicerequest 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 service s class is derived from GSETServiceProvider, this can be achieved conveniently by overriding the protected method evaluaterequest. Otherwise the module looks for the global JNDI property gsetrequestevaluator. This property should point to a class implementing the interface GSETEvaluator. 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, redirects 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 storage service in the N2Grid [19] project for managing artificial 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 Offer button. The authorization and service request takes Figure 3. Overhead of gset versus gridmap place by Start Transfer. On the Retrieve panel all references 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 additionally a separate getoffer method, because it does not inherit the method from gset. The gt4store service uses gridmap file authorization and does not provide the following functions without violating the requesters privacy: Secure accounting Verification of requester credit rating Dynamic authorization The services were deployed in a GT4.0.1 Java core container (with TLS) running on Debian sarge Linux (kernel ), 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 workstation. 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 workloads (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

8 Figure 4. Total Time of gset and gridmap gsetstore and the gt4store result only from the authorization 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 qualified because of the functional advances of gset. By increasing the workload the authorization overhead decreases relatively, therefore Figure 3 shows that the gset overhead is nearly constant 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 gsetservice 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 secure 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 important issue. gset maintains private information of clients confidential. Nevertheless, a service provider has guarantees and can trust in client s characteristics. Consuming Grid Services with a gset account is comparable 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 workflows. References [1] Apache. WSS4J, [2] Apache. XML Security, [3] A. Barmouta and R. Buyya. GridBank: A Grid Accounting Services Architecture (GASA) for Distributed Systems Sharing 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, IEEE Computer Society Press. [4] Bürgerkarte, [5] G. Coulouris, J. Dollimore, and T. Kindberg. Distributed Systems. Addison-Wesley, 3rd edition, [6] I. Foster. What is the Grid? A Three Point Checklist. Technical report, Argonne National Laboratory and University of Chicago, July [7] L. Giussani. The Religious Sense. McGill-Queens, October [8] The Globus Security Team. Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective, December 8, Version 2. [9] H. R. Hansen and G. Neumann. Wirtschaftsinformatik 1, Grundlagen und Anwendungen. Lucius & Lucius, Stuttgart, 9th edition, [10] M. Humphrey, M. R. Thompson, and K. R. Jackson. Security for Grids. Proceedings of the IEEE, 93(3): , March [11] Internet2/MACE. Shibboleth Project, [12] Java Cryptography Extension (JCE), [13] H. Kishimoto. OGSA Status and Future, March 14, GGF13 OGSA-WG. [14] MasterCard, VISA. SET Secure Electronic Transaction Specification, Book 1: Business Description, May 31, Version 1.0. [15] MasterCard, VISA. SET Secure Electronic Transaction Specification, Book 2: Programmer s Guide, May 31, Version 1.0. [16] MasterCard, VISA. SET Secure Electronic Transaction Specification, Book 3: Formal Protocol Definition, May 31, Version 1.0. [17] OASIS. Security Assertion Markup Language (SAML) 1.0 Specification Set, November OASIS Standard. [18] OASIS. extensible Access Control Markup Language (XACML) 1.0 Specification, February [19] E. Schikuta, H. Wanek, and T. Weishäupl. Neural Networks in the Grid. University of Vienna, [20] SweGrid. SweGrid Grid Accounting System (SGAS), [21] Virtual Organization Membership Service (VOMS), [22] T. Weishäupl, C. Witzany, and E. Schikuta. gset. University of Vienna, shrink/gset.