Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Simpleauthentication

Simpleauthentication

Simple Authentication

Simple Authentication

Overview

Although ProtoGENI access control should normally be performed with the credential mechanism, which allows identification and authentication in both directions as well as validating privileges which a principal wishes to invoke, under certain circumstances a simpler authentication mechanism can be useful.

The simple scheme described here relies on certificate verification only. It does not perform strong authentication, and does not verify credentials or privelegs. The only reliable result of this procedure is to determine whether a peer is a valid ProtoGENI principal.

The major benefit of the simple approach is that no custom code is necessary to perform authentication; simple configuration of off-the-shelf tools is sufficient for basic certificate verification.

Mechanism

The ProtoGENI federation relies on X.509 public key infrastructure co-ordinated by the clearing house. In general, each site in the federation behaves as a CA, and publishes a (self-signed) root certificate. These certificates are distributed throughout the federation by the clearing house, and so are assumed to be well-known.

Each site (i.e. CA) can then sign certificates for any ProtoGENI principals it wishes to certify. These certificates can be processed and handled with normal X.509 tools. Although there are certain conventions which are important for normal ProtoGENI access control, they are not relevant to this simple authentication scheme.

The key concept to understanding simple authentication is to realise that if a principal authenticates with a private key certified by one of the well-known CAs, then that is adequate proof that the principal is a valid member of the federation (up to key compromise or CA collusion).

It is very important to note that this simple procedure has not addressed strong identification or privilege establishment. The verifying party should NOT yet trust information attached to the certificate any more than it trusts the issuing CA; full verification must additionally verify the ProtoGENI certificate conventions referenced above.

Details

The set of well-known root certificates (and the corresponding certificate revocation lists) for the federation are available from the clearing house at the following URLs:

https://www.emulab.net/genica.bundle
https://www.emulab.net/genicrl.bundle

Both files are simply concatenations of the PEM forms (base-64 encoded DER) of the certificates or revocation lists from each CA.

(It is also possible to obtain the files without SSL if necessary, by replacing https with http in the above URLs.)

All verifiers should obtain these certificate lists and endeavour to keep them reasonably up-to-date. They are typically updated daily, so there is little point attempting to retrieve them more frequently.

Once the root certificates are obtained, it should be possible to use a variety of software to verify additional certificates. For instance, the OpenSSL command openssl verify -CAfile /example/genicrl.bundle will verify a certificate against the bundle of root CAs (although not against revocation lists).

Example Apache configuration

The Apache HTTP server can also be configured to verify certificates, which is a very easy way to restrict access to ProtoGENI principals only. The following httpd.conf excerpt demonstrates how to apply such a restriction to a particular directory:

SSLCACertificateFile /example/genica.bundle
SSLCARevocationFile /example/genicrl.bundle

<Directory "/example/protected/directory">
    SSLRequireSSL
    SSLVerifyClient require
</Directory>