Authentication configuration system with master password

[dakcarto]

Master password-protected storage/retrieval system of authentication configurations, to be used by extensible providers to authenticate access to resources, e.g. PKI client certificate presented to SSL server during HTTPS connection.

Companion PR to associated QEP. Work sponsored by Boundless.

Adds required build/package dependency upon GPL2-licensed Qt Cryptographic Architecture (QCA) 2.0.3+, and a run-time dependency upon QCA's OpenSSL plugin (qca-ossl). Latest QCA is 2.1.0, which builds on all major platforms using CMake and includes all available plugins in the build process.

QCA source repo browser at KDE.

Mac Homebrew qca formula.

[dakcarto]

QCA 2.1.0 is compatible with Qt5. QCA 2.0.3 will still support the functions in this PR.

On Ubuntu, you can get QCA 2.0.3 binaries via apt packages:

libqca2-dev
libqca2-plugin-ossl
qca2-utils  <-- optional command line tool `qcatool2`, useful for debugging install
libqt4-sql-sqlite  <-- for accessing ~/.qgis2/qgis-auth.db (and used by QGIS Bookmarks)

libqca2-dev, libqca2-plugin-ossl, qca2-utils, libqt4-sql-sqlite. QCA 2.0.2 under Lucid has not been tested. If it works, the CMake find script will need updated (limits version to >= 2.0.3).

Required CMake options for building QCA 2.1.0, with regards to QGIS and this PR, are:

-DQT4_BUILD:BOOL="1"
-DWITH_ossl_PLUGIN:STRING="ON"

On Windows, you can build QCA 2.1.0 against OSGeo4W and install into it:

• Install openssl-devel package from OSGeo4W, to get OpenSSL's headers
• Run a batch script similar to this one for Win 7 32-bit. If you use that example batch script, you will need to edit the paths to your installed components. That script is for tools stored on a separate virtual disk inside of a virtual machine, but the basic build tools are the same installs as outlined in QGIS's INSTALL doc, under Building on Windows / Building with Microsoft Visual Studio.
• There is a small issue with the qt4.bat environment script in OSGeo4W that causes QCA apps to crash on exit (qcatool included). Simple text edit fixes issue.

EDIT: libqt4-sql-sqlite dependency info

[dakcarto]

To test PKI connections, you can download and launch this Apache Tomcat with installed GeoServer (~170 MB), which is pre-configured for PKI connections for OWS (WMS, WCS and WFS) services.

GeoServer was configured according to these docs. The sample certificate files available there have been processed into different formats using OpenSSL and are located in the <qgis src>/tests/testdata/auth_system/pki/ directory of this PR.

When testing with these sample certificate files, ensure to add the ca.pem for all configurations and check the Self-signed option, since the CA is self-signed and will probably not be available in your root certs.

[m-kuhn]

This is a great initiative!

Many systems have their internal keystore (I know of gnome-keyring and kwallet but I'm sure the ones from redmond and cupertino have one as well).
Is this compatible with such an approach? (i.e. no password prompt directly from QGIS to unlock the keystore)

[dakcarto]

Hi @m-kuhn.

I modeled the system after Firefox's master password setup (for site passwords), in the sense that it does not use the user's system keystore/ring. I looked into possibly storing the auth configs in some type of system utility, but ultimately it was just easier to roll a custom one on top of a single, portable SQLite file.

However, your idea would be a great addition.

I would say that the system can definitely benefit from a lightweight OS keystore/ring integration at the master password input stage, i.e. keep the auth system implementation as is and use the user's keystore/ring to manage only whether the master password needs to be input. If the user has the master password stored in their private keystore/ring, and the user has unlocked the utility, then use it automatically without any Qt dialog prompt. That would be a great improvement and be much simpler to integrate across platforms, since only one simple password check/retrieval would be needed. We could do this fairly quickly using QCA's GPG plugin (at least for Linux, I think, haven't played with it).

There is also support for accessing the local cert/password store in QCA, but it doesn't seem to work quite right (so I avoided it at the auth config and provider levels, where everything is currently either saved text or paths to files). I tried using it to auto-access PKI client cert/keys on Win and Mac, but it just doesn't function right anymore. QCA is an open project and can certainly benefit from some more help. I would rather see any cert store or keystore/ring OS-specific code go into that project, with its simple Qt-like API for QGIS, than incorporate such code into QGIS. One of the reasons I finally settled on QCA for the supporting libs.

[m-kuhn]

That sounds good.

So we can just ship our internal password dialog for platform X as long as the QCA backend isn't working properly on X.

[dakcarto]

Hmm. I think I follow you. After integrating with platform services for checking the master password is available...

• User is not prompted if the local store/ring check succeeded and the master password verified against its saved sha256 hash in qgis-auth.db.
• User is prompted for master password if local store/ring check failed, or check succeeded, but the master password failed to verify against its saved sha256 hash in qgis-auth.db.
• User is prompted for master password if local store/ring check is not supported for the platform.

Then, the verified password enables the auth system, and is used to decrypt auth configs (since configs are encrypted using the master password).

[m-kuhn]

That sounds like a good solution to me.

And then I guess that it should be left to the user if he wants to make
use of a system's store/ring (checkbox below the master password on
supported platforms).