What proxy certificates are and how to create and use them and the purpose of different types of proxy certificates.
To interact directly with a remote service a certificate can be used to prove identity. However, in the Grid world it is often necessary for a remote service to act on a user's behalf, e.g. a job running on a remote site needs to be able to talk to other servers to transfer files, and it therefore needs to prove that it is entitled to use the user's identity (this is known as delegation). On the other hand, since the private key is so vital it should not be sent to remote machines which might be insecure.
The solution is the use of a proxy. Strictly speaking, a proxy is also a certificate, but usually the unqualified term "certificate" is reserved for something issued by a CA. To make a proxy, a new public/private key pair is created and a new certificate is built containing the public key using a name with the form of the following example:
/C=UK/O=eScience/OU=CLRC/L=RAL/CN=john smith/CN=proxy
It is signed with the certificate's long-term private key. Proxies normally have a rather short lifetime, typically 12 hours. Note that proxy creation is a purely local process, there is no contact with any remote service.
When a job is submitted, the proxy certificate, the private key for the proxy and the normal certificate (but not the long-term private key) are sent with it. When the job wants to prove its delegated identity to another service, it sends it the proxy certificate and the standard certificate, but usually not the proxy private key. It can then use the chain of certificates to prove that it is entitled to use the delegated SN. In some circumstances, a job may even create a new proxy itself, so the chain can potentially be longer.
In security terms, a proxy is a compromise. Since the private key is sent with it, anyone who steals it can impersonate the owner, so proxies need to be treated carefully. There is no mechanism for revoking proxies, so in general, even if someone knows that one has been stolen, there is little they can do to stop it being used. On the other hand, proxies usually have a lifetime of only a few hours, so the potential damage is fairly limited.
A proxy, which includes its own private key, can be stored anywhere, but is typically under /tmp (note that this is usually a local area, so when using systems like lxplus with many front-end machines, sessions in different windows may not all see the same /tmp). The file name is usually x509up_u1234 where 1234 is the user's Unix ID number (UID). Like the certificate key, a proxy must only be readable by the owner. However, there is no passphrase protection.
A system called VO Management Service (VOMS) is used in WLCG/EGEE to manage information about the roles and privileges of users within a VO. This information is presented to services via an extension to the proxy. At the time the proxy is created, one or more VOMS servers are contacted, and they return an Attribute Certificate (AC) which is signed by the VO and contains information about group membership and any associated roles within the VO.
Using a single certificate with more than one VO requires the recognition of VOMS proxies, which is not yet the case for all WLCG/EGEE middleware and services, hence it is currently necessary to have a separate certificate for each VO.
To create a VOMS proxy, the ACs are embedded in a standard proxy, and the whole thing is signed with the private key of the parent certificate. Services can then decode the VOMS information and use it as required, e.g. a user may only be allowed to do something if he has a particular role from a specific VO. One consequence of this method is that VOMS attributes can only be used with a proxy, they cannot be attached to a CA-issued certificate.
One other thing to be aware of is that each AC has its own lifetime. This is typically 12 hours as for the proxy, but it is possible for ACs to expire at different times to each other and to the proxy as a whole.
The Virtual Organisation Membership Service (VOMS) (not to be confused with the VO Management Service) is a system which allows a proxy to have extensions containing information about the VO, the groups the user belongs to in the VO, and any roles the user is entitled to have.
In VOMS terminology, a group is a subset of the VO containing members who share some responsibilites or privileges in the project. Groups are organised hierarchically like a directory tree, starting from a VO-wide root group. A user can be a member of any number of groups, and a VOMS proxy contains the list of all groups the user belongs to, but when the VOMS proxy is created the user can choose one of these groups as the ``primary'' group.
A role is an attribute which typically allows a user to acquire special privileges to perform specific tasks. In principle, groups are associated to privileges that the user always has, while roles are associated to privileges that a user needs to have only from time to time. Note that roles are attached to groups, i.e. roles in different groups with the same role name are distinct.
The groups and roles are defined by each VO; they may be assigned to a user at the initial registration, or added subsequently.
Groups and roles are mapped to specific privileges through the use of a combination system called Fully Qualified Attribute Name (FQAN). The format is:
FQAN = <group name>[/Role=<role name>]
for example, /cms/HeavyIons/Role=production.
The user can generate a proxy using the command grid-proxy-init, which prompts for the user passphrase, as in Example 1.
With the introduction of VOMS, the grid-proxy-init command can be replaced by voms-proxy-init,because the latter is an updated extension of the former.
To create a proxy, issue the command:
$ voms-proxy-init
If the command is successful, the output will be similar to:
Your identity: /O=Grid/O=CERN/OU=cern.ch/CN=John Doe Enter GRID pass phrase for this identity: Creating proxy ............................................... Done Your proxy is valid until: Tue Jun 24 23:48:44 2003
The proxy will be written in a path following the template /tmp/x509up_u<uid> where <uid> is the Unix UID of the user, unless the environment variable X509_USER_PROXY is defined, in which case its value is taken as the proxy file path.
If the user gives a wrong pass phrase, the output will be:
ERROR: Couldn't read user key. This is likely caused by either giving the wrong pass phrase or bad file permissions key file location: /home/doe/.globus/userkey.pem Use -debug for further information.
If the proxy file cannot be created, the output will be:
ERROR: The proxy credential could not be written to the output file. Use -debug for further information.
If the user certificate files are missing, or the permissions of
userkey.pem are not correct, the output is:
ERROR: Couldn't find valid credentials to generate a proxy. Use -debug for further information.
By default, the proxy has a lifetime of 12 hours. To specify a different lifetime, the -valid H:M option can be used (the proxy is valid for H hours and M minutes -default is 12:00). When a proxy has expired, it becomes useless and a new one has to be created with grid-proxy-init. However, longer lifetimes imply bigger security risks and the Grid Acceptable Use Policy generally limits proxy lifetimes to 24 hours -- some services may reject proxies with lifetimes which are too long.
Use the option -help for a full listing of options.
It is also possible to print information about an existing proxy, or to destroy it before its expiration, as in the following examples.
To display information about a proxy, for example the Subject Name (SN) or the time left before expiration, the following command is given:
$ grid-proxy-info
The output, if a valid proxy exists, will be similar to:
subject : /O=Grid/O=CERN/OU=cern.ch/CN=John Doe/CN=proxy issuer : /O=Grid/O=CERN/OU=cern.ch/CN=John Doe type : full strength : 512 bits path : /tmp/x509up_u7026 timeleft : 11:59:56
If a proxy does not exist, the output is:
ERROR: Couldn't find a valid proxy. Use -debug for further information.
To destroy an existing proxy before its expiration, it is enough to do:
$ grid-proxy-destroy
If no proxy exists, the result will be:
ERROR: Proxy file doesn't exist or has bad permissions Use -debug for further information.
The voms-proxy-init command generates a Grid proxy, contacts
one or more VOMS servers, retrieves the user attributes and includes
them in the
proxy. If used without arguments, it works exactly as
grid-proxy-init.
To create a basic VOMS proxy, without requiring any special role or primary group, the following format is used:
$ voms-proxy-init -voms <vo>
where <vo> is the VO name. The output is similar to:
Your identity: /C=CH/O=CERN/OU=GRID/CN=John Doe Enter GRID pass phrase: Creating temporary proxy .............................................. Done Contacting lcg-voms.cern.ch:15002 [/C=CH/O=CERN/OU=GRID/CN=host/lcg-voms.cern.ch] "cms" Done Creating proxy ................................................................ Done Your proxy is valid until Thu Mar 30 06:17:27 2006
There are two steps: a standard Grid proxy is created first and used to authenticate to the VOMS server, and the full VOMS proxy is then created using information returned by it. If a valid proxy already exists the -noregen option can be used to avoid the first step, including typing the passphrase.
One clear advantage of VOMS proxies over standard proxies is that the middleware can find out to which VO the user belongs to from the proxy, whilst when using a normal proxy, the VO has to be explicitly specified.
To create a proxy with a given role (e.g. production) and
primary group (e.g. /cms/HeavyIons), the syntax is:
$ voms-proxy-init -voms <alias>:<group name>[Role=<role name>]
where <alias> specifies the server to be contacted
(see below), and usually is the name of the VO. For example:
$ voms-proxy-init -voms cms:/cms/HeavyIons/Role=production
voms-proxy-init requires a user-level configuration file, whose path can be specified in several ways; if the path is a directory, the files inside it are concatenated and taken as the actual configuration file.
The configuration file must contain lines with the following syntax:
alias host port subject vo
where the items are, respectively, an alias (usually the name of the VO), the host name of the VOMS server, the port number to contact for a given VO, the Distinguished Name (DN) of the server host certificate, and the name of the VO.
The configuration file, which must be owned by the user, is looked for in these locations:
-userconf option, when added to the end of the voms-proxy-init command; $HOME/.glite/vomses. If it is not found, a system-wide configuration file, which must be owned by root, is looked for in these locations:
-confile option, when added to the end of the voms-proxy-init command; $GLITE_LOCATION/etc/vomses; /opt/glite/etc/vomses.The configuration file might look like the following:
"dteam" "lcg-voms.cern.ch" "15004" "/C=CH/O=CERN/OU=GRID/CN=host/lcg-voms.cern.ch" "dteam"
The voms-proxy-info command is used to print information about an existing VOMS proxy. Two useful options are -all, which prints everything, and -fqan, which prints the groups and roles in FQAN format. For example:
$ voms-proxy-info -all
which prints out something similar to the following:
subject : /C=CH/O=CERN/OU=GRID/CN=John Doe/CN=proxy issuer : /C=CH/O=CERN/OU=GRID/CN=John Doe identity : /C=CH/O=CERN/OU=GRID/CN=John Doe type : proxy strength : 512 bits path : /tmp/x509up_u10585 timeleft : 11:59:58 === VO cms extension information === VO : cms subject : /C=CH/O=CERN/OU=GRID/CN=John Doe issuer : /C=CH/O=CERN/OU=GRID/CN=host/lcg-voms.cern.ch attribute : /cms/Role=NULL/Capability=NULL timeleft : 11:59:58
There are separate times to expiry for the proxy as a whole and the VOMS extension, which may be different.
Proxies created as described in the previous section pose a problem: if a job does not finish before the expiration time of the proxy, it is aborted. This can easily happen, for example, if the job takes a very long time to execute, or if it stays in a queue for a long time. The easiest solution to the problem would be to use very long-lived proxies, but at the expense of an increased security risk. Moreover, the duration of a VOMS proxy is limited by the VOMS server and cannot be made arbitrarily long.
To overcome this limitation, a proxy credential repository system is used, which allows the user to create and store a long-term proxy in a dedicated server (a MyProxy server). The Workload Management System (WMS) will then be able to use this long-term proxy to periodically renew the proxy for a submitted job before it expires and until the job ends (or the long-term proxy expires).
To see if a site has a MyProxy server, the Grid Operations Centre (GOC) database may be consulted; MyProxy servers have a node type of PROX. A UI may have a default server defined in the MYPROXY_SERVER environment
variable.
Because the renewal process starts 30 minutes before the old proxy expires, it is necessary to generate an initial proxy long enough, or the renewal may not complete in time. In this case, the job will fail with the following error:
Status Reason: Got a job held event, reason: Globus error 131: the user proxy expired (job is still running)
The minimum recommended time for the initial proxy is 30 minutes, and in most circumstances it should be substantially longer. Job submission is forbidden for proxies with a remaining lifetime less than 20 minutes: an error message like the following will be produced:
**** Error: UI_PROXY_DURATION **** Proxy certificate will expire within less then 00:20 hours.
Management of the proxy renewal functionality is available via the myproxy commands. The user must either specify the host name of a MyProxy server, or define it as the value of the MYPROXY_SERVER environment variable.
For the WMS to know which MyProxy server to use in the proxy renewal process, the name of the server must be included in an attribute of the job's JDL file. If the user does not add it manually, the name of the default MyProxy server is added automatically when the job is submitted. This default is defined in a VO-specific configuration file.
The machine on which the WMS is running must be trusted by the MyProxy server for renewal to be allowed.
To create and store a long-term proxy, the user must follow the format:
$ myproxy-init -s <myproxy_server> -d -n
where -s <myproxy_server> specifies the hostname of the
machine where a MyProxy Server runs, the -d option instructs
the server to associate the user DN to the proxy, and the -n
option avoids the use of a passphrase to access the long-term
proxy, so that the WMS can perform the renewal automatically.
The output will be similar to:
Your identity: /O=Grid/O=CERN/OU=cern.ch/CN=John Doe Enter GRID pass phrase for this identity: Creating proxy ............................................. Done Your proxy is valid until: Thu Jul 17 18:57:04 2003 A proxy valid for 168 hours (7.0 days) for user /O=Grid/O=CERN/OU=cern.ch/CN=John Doe now exists on myproxy.cern.ch.
By default, the long-term proxy lasts for one week and the proxies created from it last 12 hours. These lifetimes can be changed using either the -c and the -t option, but cannot
be longer than the lifetime of the user certificate.
If the -s <myproxy_server> option is missing, the command will try to use the MYPROXY_SERVER environment variable to determine the MyProxy Server.
If the hostname of the MyProxy Server is wrong, or the service is unavailable, the output will be similar to:
Your identity: /O=Grid/O=CERN/OU=cern.ch/CN=John Doe Enter GRID pass phrase for this identity: Creating proxy ...................................... Done Your proxy is valid until: Wed Sep 17 12:10:22 2003 Unable to connect to adc0014.cern.ch:7512
where only the last line reveals that an error occurred.
To get information about a long-term proxy stored in a Proxy Server, the following command format is used:
$ myproxy-info -s <myproxy_server> -d
where the <myproxy_server>, -s and -d options have the same meaning as in the previous example. The output is similar to:
username: /O=Grid/O=CERN/OU=cern.ch/CN=John Doe owner: /O=Grid/O=CERN/OU=cern.ch/CN=John Doe timeleft: 167:59:48 (7.0 days)
There must be a valid proxy on the UI, created with grid-proxy-init or voms-proxy-init, to successfully interact with the long-term proxy on the MyProxy server.
Deleting a stored long-term proxy is achieved by doing:
$ myproxy-destroy -s <myproxy_server> -d
<myproxy_server>, -s and -d options have the same meaning as in the previous example. The output is:
Default MyProxy credential for user /O=Grid/O=CERN/OU=cern.ch/CN=John Doe was successfully removed.
Again, a valid proxy must exist on the UI for this to work.