The GridSite Proxy Delegation Service
Andrew McNab, Shiv Kaushal
Department of Physics and Astronomy, University of Manchester
Abstract
X.509 Proxy Certificates may now be delegated from a client to a service using the GridSite/gLite
Delegation Web Service. We have implemented both a client and an implementation of the service,
and we describe the delegation process in terms of the operations of the delegation portType. We
also explain how proxies delegated to a service can be used by other Web Services written as CGI
scripts or executables, and how other components of GridSite and Unix account permissions can be
combined to control which services can access a delegated proxy credential on a shared server.
This work has been done as part of the GridSite and EGEE projects, and the GridSite toolkit now
includes functions which third­party developers can use to add support for a delegation portType to
their own applications.
1. Introduction
X.509 Proxy Certificates1 were originally
introduced by the Globus Project2 and have
subsequently become central to the operation of
international production Grids, such as the LHC
Computing Grid3 and the EGEE4 project. A
proxy certificate allows jobs or agents to prove
that they are running on behalf of a particular
user, and they are granted to jobs by some form
of delegation procedure involving the creation
and signing of a short­lived X.509 certificate.
This paper describes an X.509 Proxy Certificate
delegation web service developed jointly as part
of the EGEE and GridSite5 projects.
2. The delegation protocol
issued by a Certification Authority, or an X.509
PC previously created by the user.
The delegation procedure involves the
following steps:
•
•
•
•
2.1 X.509 delegation
RFC 32801 describes how the certificate
requests and proxy certificates (PC) are
processed by the service and client. The
GridSite delegation service caters to the
scenario of a remote web service which requires
a PC, and a client which already possesses
either a full X.509 end entity certificate (EEC)
•
The service is contacted by the client, which
asks for an X.509 certificate request.
The service then generates an RSA public
and private key pair, stores the private key
and uses the public key as the basis of an
X.509 certificate request.
The service may choose to pre­populate the
request with values, such as the desired
expiration time and the uses to which the
proxy may be put.
The service returns the certificate request to
the client, which enforces any restrictions it
places on values such as expiration time,
and then signs the request using the client's
own private key.
The resulting X.509 PC is then sent to the
service, which now possesses the
corresponding private key, the PC itself and
all of the X.509 PC and EEC which prove
the chain of trust back to a trusted
Certification Authority.
Since an X.509 PC is very similar to a
conventional EEC, it can be used within most
client applications without modification. On the
server side, for applications which use
SSL/TLS6 such as HTTPS7, only the code which
checks the client's certificate chain requires
modification (to permit chains including PCs
in addition to Certification Authority
certificates and a final EEC.) For
Apache/mod_ssl, this modification is done
dynamically by GridSite by intercepting the
underlying OpenSSL8 callbacks during the
authentication phase. PC support was also
added to OpenSSL itself in version 0.9.7g.
2.2 Web Service operations
To allow clients and services to perform this
two stage delegation procedure, a delegation
web service specification has been developed
within the EGEE Middleware Security Group9
for use by the GridSite and gLite10 middleware
systems.
This paper describes version 1.1.0 of the
service (http://www.gridsite.org/delegation­
1.1.0.wsdl) which uses the namespace
http://www.gridsite.org/namespaces/delegation­1. The service consists of a single portType,
Delegation, which may either be implemented
as a standalone web service or as an additional
portType of services which require delegation.
In either mode, a Delegation ID string is used to
identify the delegation session, which is
necessary if the same client wishes to maintain
multiple simultaneous delegations to the same
server, with different expiration times or other
options. This scenario is likely to occur if a user
submits multiple jobs to a grid which are
unaware of each other but arrive at the same
site.
The delegation procedure is carried out
using two operations within the portType,
getNewProxyReq and putProxy.
To initiate a delegation, the client sends an
empty getNewProxyReq request, and receives a
Delegation ID generated by the service and an
X.509 certificate request in Base64 encoded
PEM format.
After populating and signing the request, the
client then completes the procedure using the
putProxy operation to send the signed X.509 PC
back to the service, and includes the Delegation
ID to allow the service to associate the PC with
the private key generated in the first phase.
The renewProxyReq operation is also
provided which can be used in place of
getNewProxyReq and allows the client to
specify an existing Delegation ID and extend
the lifetime of its delegation session. In return,
the service responds with an X.509 certificate
request and putProxy is used as before.
Clients can enquire about the status of a
delegation session with the getTerminationTime
operation, which returns the expiration time of
the proxy corresponding to the given
Delegation ID; and the destroy operation can be
used to remove a proxy including the private
key from the service's store. 3. The GridSite implementation As mentioned above, GridSite adds support to
Apache11 for the authentication of clients using
an X.509 PC with an HTTPS connection. Web
services can then be written as CGI scripts or
executables, and obtain the authentication
information, including the certificate chain
used, from the CGI environment variables. 3.1 GridSite Delegation Service
The GridSite Delegation Service uses this
environment and is written in C with the aid of
standard toolkits. The gSOAP12 web services
toolkit is used to convert between SOAP
messages and C structures, and OpenSSL is
used to examine X.509 certificates and generate
private keys and certificate requests. All the
additional utility functions which were required,
including the storage of proxies, were written as
part of the GridSite library, and where they can
be used by third­party authors to add a
delegation portType to their own web services.
3.2 htproxyput client
htproxyput is a command­line client which can
be used with the GridSite Delegation Service or
other implementations of the portType. The
command syntax is similar to the htcp family of
commands supplied with the main GridSite
distribution, and its default options look for the
user's X.509 EEC or X.509 PC in commonly
used locations, including the
X509_USER_PROXY environment variable,
and the “/tmp/x509up_uN” file created by
Globus grid­proxy­init or gLite voms­proxy­
init.
As with the Delegation Service, most of the
functionality is provided by calls to GridSite
toolkit functions, supplemented by gSOAP and
OpenSSL. 4. Use with CGI services
The implementation of the delegation service
has been designed to allow the sharing of
proxies with other web services hosted on the
same GridSite enabled server. GridSite allows
Web Services for Grids to be written as CGI
scripts or executables, with authentication and
access control decisions performed within
Apache by the mod_gridsite module, which also
makes the values of X.509 PC and EEC
available, plus any VOMS X.509 Attribute
Certificates. GridSite also provides a setuid
wrapper, based on Apache's suexec, which
allows Unix accounts and file permissions to
control what areas of the hosting server are
accessible to each instance of a service. 4.1 Proxy Storage
The delegation service must store the private
key when it is generated and the signed X.509
PC when it is returned by the client. Both
filesystem and SQL database stores have been
specified. GridSite implements file­based
storage, which interoperates with GridSite's use
of Unix file permissions to sandbox other
services and sessions owned by different users.
All of the proxy files are stored in
subdirectories of a proxycache directory, which
is a sibling of the DocumentRoot directory
specified in the Apache virtual server
configuration.
For example “/var/www/proxycache” if
“/var/www/html” is the DocumentRoot. This
allows multiple virtual servers, with different
DNS components in their URL, to be hosted on
the same physical server, without clashes
between Delegation IDs which are only unique
to each DNS domain name.
Within the proxycache directory, the cache
subdirectory contains private keys awaiting the
upload of the corresponding X.509 PC,
organised into directories named after the URL­
encoded Distinguished Name of the X.509
EEC, with one subdirectory for each Delegation
ID.
For example
“/var/www/proxycache/cache/%2FC%3DUK%
2FO%3DeScience%2FOU%3DManchester%
2FL%3DHEP%2FCN%3Dandrew%
20mcnab/acd5ab55a6c9473e/”
Once the signed X.509 PC is returned by the
client, the PEM encoded proxy chain including
the EEC and PC and private key is saved as
userproxy.pem within a subdirectory named
after the Delegation ID, which is itself a
subdirectory of the user's URL­encoded EEC
Distinguished Name. For example,
“/var/www/proxycache/%2FC%3DUK%2FO%
3DeScience%2FOU%3DManchester%2FL%
3DHEP%2FCN%3Dandrew%
20mcnab/acd5ab55a6c9473e/”
4.2 Interaction with gsexec
GridSite's gsexec wrapper allows CGI scripts or
executables to run as users other than the
apache user, which typically owns the listening
Apache processes and most of their files. The
server can be configured to assign a pool
account to each client X.509 EEC identity, or to
each directory containing one or more services,
or a mixture of both on a per­directory basis.
These modes allow the sandboxing of instances
of a service associated with different clients, or
of sets of services owned by different
application groups.
Since the delegation service stores delegated
proxy chain and private key in the Unix
filesystem, ownership and permissions can be
used to control access to the proxy in a
transparent way.
Let us assume that Apache runs as user
apache and group apache; that each pool user
has both a user and its own group; that the
apache user has secondary membership of each
pool user's private group; and that files are
created with owner and group have read/write
permission.
This arrangement lets Apache write to files,
if it receives an authorized PUT request, and
allows CGI scripts to run as a given pool user
and write files, but prevents them from writing
to files owned by other pool users.
If the GridSite Delegation Service is then
run as apache, it has the ability to create proxy
files which are only readable by the pool user
which corresponds to the correct EEC identity,
by virtue of its group readable permission and
the pool user's private group.
5 Summary
We have implemented both a client and a
service for the GridSite/gLite Web Service for
the delegation of X.509 Proxy Certificates. This
work has been done as part of the GridSite
project, and the GridSite toolkit now includes
functions which third­party developers can use
to add support for a delegation portType to their
own applications.
Acknowledgements
This work has been funded by the UK's Particle
Physics and Astronomy Research Council,
through its e­Science Studentship programme
and support for the GridPP collaboration.
The GridSite/gLite delegation web service
is the result of discussions within the EGEE
Middleware Security Group, and we would like
to thank Akos Frohner, Joni Hahkala, Olle
Mulmo and Ricardo Rocha for their work on
finalising the specification.
References
1. RFC 3820, “Internet X.509 Public Key
Infrastructure (PKI) Proxy Certificate
Profile”, S. Tuecke et al, June 2004.
2. The Globus Project, http://www.globus.org/
3. LHC Computing Grid,
http://www.cern.ch/lcg
4. Enabling Grids for E­Science,
http://www.eu­egee.org/
5. The GridSite Project,
http://www.gridsite.org/
6. RFC 2246, “The TLS Protocol”, T. Dierks
et al., January 1999.
7. RFC 2818, “HTTP over TLS”, E. Rescorla,
May 2000.
8. The OpenSSL Project,
http://www.openssl.org/
9. The EGEE Middleware Security Group,
http://egee­jra3.web.cern.ch/egee­jra3/
10. gLite, http://glite.web.cern.ch/glite/
11. The Apache Webserver,
http://httpd.apache.org/
12. gSOAP, http://gsoap2.sourceforge.net/