| | 1 | = Simple Authentication = |
|---|
| | 2 | |
|---|
| | 3 | == Overview == |
|---|
| | 4 | |
|---|
| | 5 | Although ProtoGENI access control should normally be performed with the |
|---|
| | 6 | [wiki:Credentials credential] mechanism, which allows identification and |
|---|
| | 7 | authentication in both directions as well as validating privileges which |
|---|
| | 8 | a principal wishes to invoke, under certain circumstances a simpler |
|---|
| | 9 | authentication mechanism can be useful. |
|---|
| | 10 | |
|---|
| | 11 | The simple scheme described here relies on [wiki:Certificates certificate] |
|---|
| | 12 | verification only. It does not perform strong authentication, and does |
|---|
| | 13 | not verify credentials or privelegs. The only reliable result of this |
|---|
| | 14 | procedure is to determine whether a peer is a valid ProtoGENI principal. |
|---|
| | 15 | |
|---|
| | 16 | The major benefit of the simple approach is that no custom code is |
|---|
| | 17 | necessary to perform authentication; simple configuration of off-the-shelf |
|---|
| | 18 | tools is sufficient for basic certificate verification. |
|---|
| | 19 | |
|---|
| | 20 | == Mechanism == |
|---|
| | 21 | |
|---|
| | 22 | The ProtoGENI federation relies on X.509 public key infrastructure |
|---|
| | 23 | co-ordinated by the [wiki:ClearingHouseDesc clearing house]. In general, |
|---|
| | 24 | each site in the federation behaves as a CA, and publishes a |
|---|
| | 25 | (self-signed) root certificate. These certificates are distributed |
|---|
| | 26 | throughout the federation by the clearing house, and so are assumed |
|---|
| | 27 | to be well-known. |
|---|
| | 28 | |
|---|
| | 29 | Each site (i.e. CA) can then sign certificates for any ProtoGENI |
|---|
| | 30 | principals it wishes to certify. These certificates can be processed |
|---|
| | 31 | and handled with normal X.509 tools. Although there are certain |
|---|
| | 32 | [wiki:Certificates conventions] which are important for normal |
|---|
| | 33 | ProtoGENI access control, they are not relevant to this simple |
|---|
| | 34 | authentication scheme. |
|---|
| | 35 | |
|---|
| | 36 | The key concept to understanding simple authentication is to |
|---|
| | 37 | realise that if a principal authenticates with a private key |
|---|
| | 38 | certified by one of the well-known CAs, then that is adequate |
|---|
| | 39 | proof that the principal is a valid member of the federation |
|---|
| | 40 | (up to key compromise or CA collusion). |
|---|
| | 41 | |
|---|
| | 42 | It is very important to note that this simple procedure has |
|---|
| | 43 | not addressed strong identification or privilege establishment. |
|---|
| | 44 | The verifying party should NOT yet trust information attached |
|---|
| | 45 | to the certificate any more than it trusts the issuing CA; full |
|---|
| | 46 | verification must additionally verify the ProtoGENI certificate |
|---|
| | 47 | conventions referenced above. |
|---|
| | 48 | |
|---|
| | 49 | == Details == |
|---|
| | 50 | |
|---|
| | 51 | The set of well-known root certificates (and the corresponding |
|---|
| | 52 | certificate revocation lists) for the federation are available |
|---|
| | 53 | from the clearing house at the following URLs: |
|---|
| | 54 | |
|---|
| | 55 | {{{ |
|---|
| | 56 | https://www.emulab.net/genica.bundle |
|---|
| | 57 | https://www.emulab.net/genicrl.bundle |
|---|
| | 58 | }}} |
|---|
| | 59 | |
|---|
| | 60 | Both files are simply concatenations of the PEM forms (base-64 |
|---|
| | 61 | encoded DER) of the certificates or revocation lists from each CA. |
|---|
| | 62 | |
|---|
| | 63 | (It is also possible to obtain the files without SSL if |
|---|
| | 64 | necessary, by replacing {{{https}}} with {{{http}}} in the |
|---|
| | 65 | above URLs.) |
|---|
| | 66 | |
|---|
| | 67 | All verifiers should obtain these certificate lists and |
|---|
| | 68 | endeavour to keep them reasonably up-to-date. They are |
|---|
| | 69 | typically updated daily, so there is little point attempting |
|---|
| | 70 | to retrieve them more frequently. |
|---|
| | 71 | |
|---|
| | 72 | |
|---|
| | 73 | Once the root certificates are obtained, it should be possible |
|---|
| | 74 | to use a variety of software to verify additional certificates. |
|---|
| | 75 | For instance, the OpenSSL command `openssl verify -CAfile /example/genicrl.bundle` |
|---|
| | 76 | will verify a certificate against the bundle of root CAs (although |
|---|
| | 77 | not against revocation lists). |
|---|
| | 78 | |
|---|
| | 79 | == Example Apache configuration == |
|---|
| | 80 | |
|---|
| | 81 | The Apache HTTP server can also be configured to verify certificates, |
|---|
| | 82 | which is a very easy way to restrict access to ProtoGENI principals |
|---|
| | 83 | only. The following `httpd.conf` excerpt demonstrates how to apply |
|---|
| | 84 | such a restriction to a particular directory: |
|---|
| | 85 | |
|---|
| | 86 | {{{ |
|---|
| | 87 | SSLCACertificateFile /example/genica.bundle |
|---|
| | 88 | SSLCARevocationFile /example/genicrl.bundle |
|---|
| | 89 | |
|---|
| | 90 | <Directory "/example/protected/directory"> |
|---|
| | 91 | SSLRequireSSL |
|---|
| | 92 | SSLVerifyClient require |
|---|
| | 93 | </Directory> |
|---|
| | 94 | }}} |