This site requires JavaScript to be enabled
Knowledge Home|Create Incident|Print
FAQ > Fermilab PKI-mediated Access Control Policy
Fermilab PKI-mediated Access Control Policy
Article: KB0010828 Published: 2013-01-31 Last modified: 2016-07-20

Fermilab PKI-mediated Access Control Policy

Version 1.0, November 4, 2004 (updated 7/05)

Version 2.0, January 29, 2013


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 by using valid proxy credentials: a short-lived 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.


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 of 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 described 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 Fermilab, 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 Fermilab.

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 OSG PKI 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 by 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. 

One can achieve this via the Account Request procedure described at 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 Fermilab policy authentication requirement (for example, reading webpages), the authenticated user does not have to be registered with Fermilab.

Type A Certificate Authorities

Table 1

FNAL Kerberized Certificate Authority (KCA)
short-lived certs. only
e1fce4e9.0 PEM Binary CP/CPS

Type B Certificate Authorities

Fermilab can accepts as a Type B Certificate Authority, any CA accredited by the International Grid Trust Federation (IGTF) bundle of Authority Root Certificates. IGTF includes the following Policy Management Authorities (PMAs).

Additionally Fermilab accepts the following CAs as type B CAs.

Table 2

OSG DigiCert Grid CA-1 c7a717ce.0 DER format  CP CPS Grid CPS Addendum

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

None at this time

:      Views: 31
Was this helpful?
Rate this article