Webservices on GridSite
From GridSiteWiki
Protocols based on Web Services provide important benefits for Grids, particularly in avoiding the tendency that proprietary binary protocols frequently become closely tied to particular implementations or languages. The language neutrality of Web Services has received less emphasis so far, since most development of Web Services for Grids has been done in the Java languge. However, due to Apache's support for dynamic content created by a wide variety of languages, GridSite/Apache is able to support secure web services written in C, C++, Perl, Python and other scripting languages.
Apache supports two main classes of content: static web pages and files, and dynamic content obtained by running a CGI program and returning its output to the client. Each request is processed by a chain of modules which modify the input or output stream of data in some way.
The GridSite extensions have been implemented as an Apache module. Other architectures were considered, such as filters (in which an external program is called to transform the output stream) or providing library functions which CGI programs can call to parse grid security credentials. However, these either suffer from performance penalties or complicate the CGI interface, or both.
The GridSite module makes preliminary access control decisions as with static web pages, but also exports the parsed grid security credentials and the permissions granted according to the governing GACL or XACML policy. This information is exported as environment variables, using the same mechanism as used by the CGI API itself: the request and response are communicated via the stdin and stdout of the CGI process, and out of band information, such as authentication or remote network addresses, are communicated via environment variables.
This means that all the languages suitable for writing CGI executables and scripts are immediately able to access GridSite's evaluation of X.509, GSI, VOMS, GACL and XACML credentials and applicable policies.
Example: webservice delegation protocol
The Delegation protocol implementation included in GridSite illustrates how web services can be built using C and the gSOAP toolkit.
This protocol was agreed within the EGEE project, and both C (GridSite) and Java implementations are available as part of EGEE's gLite framework.
To perform a delegation, the client sends a Get Proxy Request message to the server, which causes the server to generate a public and private key and return an X.509 certificate signing request containing the public key. The client then signs this request using its own private key and certificate, and sends a Put Proxy message back to the server, containing the signed certificate. Together the private key which the server generated (and which has not crossed the network) and the new certificate form an RFC3820 / GSI proxy.
gSOAP provides tools for generating the WSDL description of such a Web Service from the C header files of the functions which implement it; or vice versa. With a consistent WSDL description and populated callback functions which implement the actual X.509 key and signing functions, an executable can be built which will operate as a CGI program.
This means that SOAP requests received by Apache will be fed into the stdin of the CGI program and the SOAP response will be taken from the stdout. Since all the required authentication information is made available as environment variables by GridSite, the CGI Web Service program can obtain these directly without needing to be linked to the GridSite library.
However, in the case of the delegation service, there are two levels of credential processing taking place: authentication and authorization of the client attempting the delegation, and then generation of the new credentials themselves. For this reason, in the special case of the GridSite delegation service, the executable is linked to the GridSite library, to obtain access to its private key and certificate handling functions.
The delegation service operates as a service with a single portType. However, since the bulk of the code necessary for delegation is part of the GridSite library, it is straightforward to add a delegation portType to other services which require delegation to function. If the standalone delegation service is used, then a mechanism is needed to share the credentials with other services. For CGI-based services running as native code or scripts, it is natural that the delegated credentials are stored in the local filesystem - where they are identified by a Delegation Session ID specified during the delegation process.
