http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 --- Comment #1 from Robin Sheat <robin@catalyst.net.nz> 2011-06-14 07:36:53 UTC --- Created attachment 4452 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4452 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 SSLVerifyDepth 2 SSLCACertificateFile /etc/apache2/ssl/test/ca.crt SSLOptions +StdEnvVars The last line ensures that the required details are passed to Koha. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 --- Comment #2 from Robin Sheat <robin@catalyst.net.nz> 2011-06-14 07:43:31 UTC --- Some caveats: * When this is first set up, it pays to clear all session cookies relating to the koha host, especially on the OPAC, or it may look like it's not working. * When using the email address verification, it is still required that users have a username defined, as the login process expects it. Don't know what'll happen if they don't, most likely it'll explode. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Needs Signoff |Signed Off --- Comment #4 from Chris Cormack <chris@bigballofwax.co.nz> 2011-07-28 22:46:00 UTC --- Working in fine in production, signing off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Ian Walls <ian.walls@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian.walls@bywatersolutions. | |com Patch Status|Signed Off |Does not apply --- Comment #6 from Ian Walls <ian.walls@bywatersolutions.com> 2011-10-18 15:54:52 UTC --- Patch no longer applies after followup to 5995 (return values of checkpw have been altered). Also, system preferences have been condensed from their many language files. Some additional comments: Uses "common name" instead of 'userid' in the system preferences editor; would be much clearer to the library if userid was somehow noted or referenced, so they know how the login works. The sample Apache configs should be added to etc/koha-httpd.conf, as comments. I'm not clear why the return values of checkauth are no longer being captured in many of touched scripts. Could you explain why this is a desirable global change (as it happens in this patch regardless of AllowPKIAuth's settings. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 --- Comment #8 from Robin Sheat <robin@catalyst.net.nz> 2011-10-19 02:23:16 UTC --- Created attachment 5971 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5971 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 SSLVerifyDepth 2 SSLCACertificateFile /etc/apache2/ssl/test/ca.crt SSLOptions +StdEnvVars The last line ensures that the required details are passed to Koha. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Does not apply |Signed Off --- Comment #9 from Robin Sheat <robin@catalyst.net.nz> 2011-10-19 02:26:57 UTC --- New version that applies against master and has the suggested changes applied. I accidentally dropped the sign-off from Chris though, hope that doesn't matter. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Rel_3_8 |master --- Comment #11 from Paul Poulain <paul.poulain@biblibre.com> 2011-10-25 15:05:52 UTC --- Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #5971|0 |1 is obsolete| | --- Comment #13 from Robin Sheat <robin@catalyst.net.nz> 2011-11-24 02:39:23 UTC --- Created attachment 6386 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6386 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 SSLVerifyDepth 2 SSLCACertificateFile /etc/apache2/ssl/test/ca.crt SSLOptions +StdEnvVars The last line ensures that the required details are passed to Koha. Conflicts: installer/data/mysql/sysprefs.sql installer/data/mysql/updatedatabase.pl -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl Patch Status|Signed Off |Needs Signoff --- Comment #15 from M. de Rooy <m.de.rooy@rijksmuseum.nl> 2011-12-19 08:57:54 UTC --- QA Comment: Code looks good to me (just going through it), but I am inclined to think that this patch needs a new signoff, preferably from someone outside the company.. Changing status to reflect that. Please respond if I am mistaken.. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA CC| |jcamins@cpbibliography.com --- Comment #17 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- Well, an obscene number of hours worth of testing later, I have determined that this patch doesn't work. I suspect copy-and-paste errors. The AllowPKIAuth syspref is never checked, and even if it were checked where I believe it should be in C4::Auth::checkauth, it doesn't look like the code would ever be reached. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #8143|0 |1 is obsolete| | --- Comment #19 from Robin Sheat <robin@catalyst.net.nz> --- Created attachment 8248 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8248&action=edit 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 SSLVerifyDepth 2 SSLCACertificateFile /etc/apache2/ssl/test/ca.crt SSLOptions +StdEnvVars The last line ensures that the required details are passed to Koha. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #8248|0 |1 is obsolete| | --- Comment #21 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- Created attachment 8249 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8249&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 --- Comment #22 from Ian Walls <koha.sekjal@gmail.com> --- Created attachment 8252 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8252&action=edit [PASSED QA] 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Ian Walls <koha.sekjal@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #8249|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master Version|master |rel_3_8 --- Comment #24 from Paul Poulain <paul.poulain@biblibre.com> --- QA comment : it's very hard to see the difference between reindenting & really new code. For the next reindenting time, please provide 2 patches, that will be much more clear. I've tested that it changes nothing when SSL not enabled, not tested SSL work well. Patch pushed -- You are receiving this mail because: You are watching all bug changes.