Version 1.0, November 4, 2004
(updated 7/05)
Identity and Authentication
In the past, understanding these two elements has been relatively simple. Traditionally your identity is your username and authentication entails providing your password on demand. This method has several problems, not least of which is dealing with automated agents (how many passwords embedded in scripts were floating around ?). In the grid world, an identity is defined by an X509 certificate issued by some certificate authority (CA). In practice, this is often shortened to just the distinguished name (DN) component. You prove authentication using valid proxy credentials: a shortlived x509 certificate and the corresponding private key. Obtaining these credentials is something the user does by whatever means a CA allows.
Fermilab distinguishes between identity and authentication. However, the current Grid software does not, and so one hears talk about lists of "trusted CAs" as being CAs whose identity statements are accepted as authentication. Fermilab accepts the identities generated by all collaborating CAs. Authentication credentials are divided into two types. Type A credentials are those for which the authentication secret is not stored on network-attached disk or transmitted across the network. Type B credentials utilize authentication secrets which may be stored or transmitted in encrypted form. Credentials obtained by authentication secrets transmitted in the clear are treated as anonymous credentials.
Authorization
After the identity of a client is authenticated, a service implicitly or explicitly performs an authorization step. This step determines whether the client is allowed to have the requested access to the service. So long as the restrictions in the next section are observed, authorization decisions are under the control or the service manager.
Fermilab expects to establish relationships with a limited set of large VOs where, in exchange for taking on responsibilities for incident response, VO authorization attributes supplement the authentication information provided. The list of VO Attribute Authorities with which Fermilab has such arrangments is below.
User Certificate Authorities
Different User Certificate Authorities allow for different methods of user authentication. These methods are vulnerable to different types of attacks and have different weaknesses. All Fermilab users are registered with the Fermilab KCA and may use standard kx509 clients to obtain certificates. Users may obtain and use credentials from any authority they choose, subject to the following restrictions:
- Credentials from Type A User Certificate Authorities are acceptable for any access to systems at FNAL, except login or shell access to a critical system.
- Credentials from Type B User Certificate Authorities are acceptable at Fermilab for read access to any data, file transfers (read or write), or invocation of jobs in a restricted environment.
- Credentials from Type B User Certificate Authorities with authorization attributes from authorities listed in Table 3 are acceptable for any access to Grid services at FNAL.
The following are sufficiently restricted to accept Type B credentials.
- Services that will only run scripts or binaries approved by and under the control of the service manager.
- Services that do not allow outside network connections, or allow only mutually authenticated communications. (Outside means outside the service environment itself.)
Fermilab makes no restriction on Grid credentials used to contact resources not on Fermilab's network.
Host and Service Certificate Authorities
Host and Service credentials from any Type A or B Certificate Authority may be used by machines at Fermilab to offer services. It is expected the majority will use DOE Grids created credentials.
Host and Service credentials from any Type A or B Certificate Authorities may be accepted to initiate file transfers, read any allowed data, or initiate other service requests which don't provide executable code.
Host and Service credentials from a Type A Certificate Authority may be accepted for remote procedure invocations where the executable code is supplied the requestor.
User Registration with Fermilab
All authenticated users of Fermilab resources must be registered with Fermilab. As we participate in larger grids, it is expected that this information will be collected by VO agents acting on Fermilab's behalf. Methods for achieving this are currently under investigation as part of the USCMS VO Project (reference ?) To register, certain minimal information must be provided and verified by an appropriate authority.
One can achieve this via the Account Request procedure described at http://computing.fnal.gov/forms/requirements.html. Alternately, one can register through a collaborating VO with which Fermilab has an established agreement.
Resource managers may require authentication for accesses to their resources beyond the Fermilab minimum requirements. For cases which do not fall under a FNAL policy authentication requirement (for example, reading web pages), the authenticated user does not have to be registered with Fermilab.
Type A Certificate Authorities
Table 1
| CA |
Certificate |
CRL |
CPS |
FNAL Kerberized Certificate Authority (KCA)
short-lived certs. only |
e1fce4e9.0 |
PEM Binary |
X |
Type B Certificate Authorities
Fermilab accepts as a Type B Certificate Authority, any CA accredited by the following Policy Management Authorities (PMAs).
Additionally Fermilab accepts the following CAs as type B CAs.
Table 2
VO Attribute Authorities
Fermilab accepts the following VO Attribute Authorities as authoritative for membership in VOs with which FNAL has Incident Response agreements.
Table 3
| VO |
AA Certificate |
AA CRL |
CP/CPS |
| None at this time |
|
