Bug 6296: allow users to be authenticated by SSL client certs
authorRobin Sheat <robin@catalyst.net.nz>
Thu, 9 Jun 2011 03:11:23 +0000 (15:11 +1200)
committerPaul Poulain <paul.poulain@biblibre.com>
Mon, 19 Mar 2012 16:02:44 +0000 (17:02 +0100)
commit4cbeeedbe8ee631777b814fabf8c999f48265c07
tree40708cb8f0b90ce73bd69bdda12fd69c5b6d931b
parent235a9dfb7d259b67f0c4167b56c7a0b04275046d
Bug 6296: allow users to be authenticated by SSL client certs

This adds a new syspref: AllowPKIAuth. It can have one of three states:
* None
* Common Name
* emailAddress

If a) this is set to something that's not "None", and b) the webserver
is passing SSL client cert details on to Koha, then the relevant field
in the user's certificate will be matched up against the field in the
database and they will be automatically logged in. This is used as a
secure form of single sign-on in some organisations.

The "Common Name" field is matched up against the userid, while
"emailAddress" is matched against the primary email.

This is an example of what might go in the Apache configuration for the
virtual host:

    #SSLVerifyClient require # only allow PKI authentication
    SSLVerifyClient optional
    SSLVerifyDepth 2
    SSLCACertificateFile /etc/apache2/ssl/test/ca.crt
    SSLOptions +StdEnvVars

The last line ensures that the required details are
passed to Koha.

To test the PKI authentication, use the following curl command:
    curl -k --cert client.crt --key client.key  https://URL/
(look through the output to find the "Welcome," line to indicate that a user
has been authenticated or the "Log in to Your Account" to indicate that a
user has not been authenticated)

To create the certificates needed for the above command, the following series
of commands will work:
    # Create the CA Key and Certificate for signing Client Certs
    openssl genrsa -des3 -out ca.key 4096
    openssl req -new -x509 -days 365 -key ca.key -out ca.crt
    # This is the ca.crt file that the Apache config needs to know about,
    # so put the file at /etc/apache2/ssl/test/ca.crt

    # Create the Server Key, CSR, and Certificate
    openssl genrsa -des3 -out server.key 1024
    openssl req -new -key server.key -out server.csr

    # We're self signing our own server cert here.  This is a no-no in
    # production.
    openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key \
        -set_serial 01 -out server.crt

    # Create the Client Key and CSR
    openssl genrsa -des3 -out client.key 1024
    openssl req -new -key client.key -out client.csr

    # Sign the client certificate with our CA cert. Unlike signing our own
    # server cert, this is what we want to do.
    openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key \
        -set_serial 02 -out client.crt
    openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12
    # In theory we can install this client.p12 file in Firefox or Chrome, but
    # the exact steps for doing so are unclear, and outside the scope of this
    # patch

Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Tested with Common Name and E-mail authentication, as well as with PKI
authentication disabled. Regular logins continue to work in all cases when
SSL authentication is set to optional on the server.

Signed-off-by: Ian Walls <koha.sekjal@gmail.com>
QA comment: synchronized updatedatabase.pl version of syspref with sysprefs.sql
version, to avoid divergent databases between new and upgrading users.
C4/Auth.pm
C4/Members.pm
acqui/finishreceive.pl
catalogue/updateitem.pl
installer/data/mysql/sysprefs.sql
installer/data/mysql/updatedatabase.pl
koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/admin.pref
members/setstatus.pl
reserve/placerequest.pl
serials/reorder_members.pl
serials/subscription-detail.pl