Auth Overview

Authentication vs Authorization

There are two kinds of "auth" words involved in computer related security:

  • Authentication -- who are you?
  • Authorization -- what are you allowed to do?

These are generally implemented by some sort of security "token", which represents you on a computer system; tokens are:

  • created by some authentication process
  • used for authorization
  • not modifiable by you.

Examples are your Linux user-id you get by logging in, or a web session cookie you get by logging into a website.

The tokens we will be discussing in this document can all be thought of as midievil letters of introduction with a seal; you get one from a trusted authority, who writes a letter saying "The bearer of this letter is so-and-so, a member of whatever, with all the rights and priveledges thereof" with a signet ring seal on it.

These "seals" or "signatures" are implemented in several different ways. In the ones following the X.509 standard, public/private key pairs are used to encrypt a hash of the letter contents; and the public keys are distributed far and wide to let it work; in the Kerberos based ones, you carry a letter encrypted with keys that only the keyserver and the intended recipient have; the fact that the recipient can decrypt it means it came from the keyserver.

Kinds of Tokens

In our experiment computing environment at Fermilab we have several types of security tokens used by various systems. Because they are all security tokens, they often have similar names or implementations, which can be confusing at first; let us give a quick overview

Token Storage Issuer Basis
kerberos Ticket Credential Cache Kerberos keyserver password, keytab
AFS Token OS memory cache kerberos keyserver kerberos ticket
User Certificate X509 .pem/.p12 file KCA kerberos ticket
OSG Cert. Auth. Site confirmation
Service Certificate X509 .pem/.p12 file OSG cert auth Site confirmation
Grid Proxy X509 .pem/.p12 file VOMS servers User Certificate

Kerberos tickets

You get Kerberos tickets from the Kerberos keyservers on site. You get a "ticket-granting-ticket" when you

  • login
  • run kinit
  • run kcron (which runs kinit -k) after having run kcroninit to establish a cron keytab.

That ticket granting ticket is usually good for 12 hours, and can be made 'renewable' up to a week (or 3 days for a kcron ketyab based ticket), and is then used to get tickets specifically for various services (systems you ssh to, etc.) so you can be authenticated (because the ticket for each service has to be encrypted in that service's key..). Usually all your kerberos tickets are in a ticket cache (often a file) and you can look at them with the "klist" command.
Technically there are tickets for older versions of kerberos, we only use Kerberos-5 tickets at Fermilab, while many utilities (i.e. klist) will also show Kerberos-4 tickets, etc.

AFS Tokens

These are actually also kerberos tickets, which let you access AFS, but are stored in the O.S. for AFS to use. At Fermilab you use a special "aklog" program to get them, which is often done automatically when you log in. There is a Kerberos 4 mechanism for getting them, too (klog) which we don't use anymore.

User Certificates

User Certificates are based on the ISO X.509 standard, which means there are lots of file formats and lots of flags/options to them. They are usually chained -- a note saying something with a signature chained onto another note saying the signature is good signed by someone else, with another one saying the third one is good... Around here there are several ways one commonly gets one:

  • OSG Certificate Service -- You fill out a request on a web page, the request gets routed to someone at your site for confirmation, they hopefully approve it somtime in the next day or so, and you get a notice to come pick up your cert at their website. It's good for a year, and then you have to request it again. Currently this uses a certificate authority run by a company called DigiCert,
    but there are still some floating around that were issued by the now defunct DOE Grid Certifiate authority.
  • Kerberized Certificate Authority (KCA) -- You use a client program (x509, or the script) to use your Kerberos tickets to request a certificate. The KCA (an automated service) signs a certificate good for the (renewable) life of your Kerberos ticket.
  • Other GRID site authorities -- CERN and various other sites out there have services very much like our OSG Certificate Service that can be used.

The whole X.509 file format issue crops up here: the kx509 utility gives you a .PEM format file, the OSG gives you a PKCS7 format file, and the browsers want to import them in PKCS12 format. So various incantations of the "openssl" command are used to convert formats; the "" script takes care of this for you for KCA certificates.

Once you have a certificate from either of these sources, you can use it:

  • in web-browsers to authenticate to (some) https: websites,
  • to request GRID Proxy certificates from VOMS
  • to log into some OSG systems (i.e. the "oasis" cvmfs upload servers) via gsissh.

Grid Proxies

The GRID Proxy is yet another X.509 certificate; it is your regular User Certificate with still more bits stitched onto it which indicate that you are affiliated with some Grid Virtual Organization -- in our case usually some experiment and role at Fermilab. You usually get one with the voms-proxy-init command, or a wrapper script like kproxy.

Here, X.509 option flags can be a problem -- there are some flags that must be set so you can use a Grid Proxy script to authenticate to a webserver; some combinations of flags cause some versions of grid tools to hang up on you rudely. So you often see specific versions of voms-proxy-init invoked with assorted alphabet-soup flags to get the right option flags set so that your Grid Proxy works pretty much everywhere.


If you look back at our earlier table, you see that there is a path from Kerberos tickets through most of the other credentials discussed here. This leads us to the way we recommend that users get the full set of credentials they might need to perform various tasks:

  • get a kerberos credential (by logging in, or via kinit with a keytab from kcroninit)
  • get AFS tokens from the above with aklog (if needed)
  • get a user cert from the above with (or kx509 directly)
  • get a grid proxy or proxies with kproxy (or voms-proxy-init directly, but watch the options that control flags)

This can be automated in your login scripts or cron jobs (the newer kproxy script does this whole chain for you); and then you have a full arsenal of credentials at hand whenever you need them.