session_security

Simple authorization

It's possible to use a simple authentication token to authorize a JSOn API call. This is done by adding a Tizra-Authentication-Token header to a request. This method can only be used over a secure connection, and provides some level of meaningful security (up to MITM attacks).

The API token can be set in the Advanced Site properties tab of a site.

Session security

Tizra detects whether a secure connection is in place on all requests, and redirects any requests that require administrative privileges to a secure endpoint before processing them.

The update interface uses unpassworded client certificates as both an encryption and authentication mechanism. This makes for simple interface, as all authentication handshaking is implemented during the session setup. It's easy to require client certificate authentication on an Apache server as part of the SSL configuration.

The Apache FAQ has some information on this: Apache SSL HowTo The example below used the per-directory features of mod_ssl

If you have an ssl Certificate Authority (CA) stored in ca.cert, you can configure appache to require client certificates signed by that authority by adding something like this to httpd.conf

SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt

<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>

The VerifyDepth sets the maximum length of the certificate chain.

We will use a depth of two, and will use an intermediate to authenticate client accesses. Highwire (or Tizra) will create a self-signed root CA (ROOT). That will be used to create and sign a subsidiary CA (INTERMEDIATE) that will be used to sign any client authentication certificates (CLIENTs). Incase of a key compromise, an new INTERMEDIATE can be created used without the need to invalidate the whole chain. Tizra and Highwire can share the INTERMEDIATE (and thus create client certificates for each other's servers).

The private key for the ROOT will be preserved on media that is not network-accessible, and will reside with one partner (probably Highwire). In case of stolen client certificates, or a compromise of the private key for the INTERMEDIATE, we can use the root to create a new CA for client certificates. Revocation lists would make more sense if we were dealing with thousands of client certificates, but are overkill, as we will be using much smaller numbers of certificates (perhaps as few as 2) in this application.

We may want to consider allowing Digest authentication on top of this as a way to enable lightweight administrative user identities. I think this may be useful for logging, and to insure against inadvertent cross-site actions from authorized servers, and digest authentication does not require a round trip on a successful access.