[auth][api] QgsAuthConfigurationStorage classes and tests

[elpaso]

Abstract authentication credentials storage

Implementation of qgis/QGIS-Enhancement-Proposals#248

Goal

Provide an abstract API to manage authentication configurations storage.
The new API supports any database supported by QSqlDatabase (https://doc.qt.io/qt-5/qsqldatabase.html) including SQLite.

Additional features:

• support non-DB sources through Python plugins or new C++ implementations
• support multiple sources through a new QgsAuthConfigurationStorageRegistry that holds the (ordered) list of authentication storages available to the system
• granular CRUD capabilities to allow storages to support only a subset of the auth assets that are currently supported by the QGIS auth system
• support for both encrypted and unencrypted storages (for external third party storages that handle encryption themselves)

[nyalldawson]

Suggested change

	class CORE_EXPORT QgsAuthConfigurationStorage: public QObject SIP_ABSTRACT
	class CORE_EXPORT QgsAbstractAuthConfigurationStorage: public QObject SIP_ABSTRACT

I'd argue that "storage" in this class name is needlessly restrictive. Perhaps QgsAbstractAuthBackend is a better choice?

[nyalldawson]

Are all these implementations 1:1 copies of the current code? Or are there modifications I should look over specifically?

[elpaso]

They are mostly 1:1 copies but I did not just cut & paste. I'd say that you can defer the review of the CRUD methods after finish writing the tests, I will probably intercept most issues while testing.

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 0b8eddc)

[nyalldawson]

More of a design question than a code question -- but I'm curious how this method will work in a multi-user setup? Eg a number of plugins I've come across (and some I maintain) use this method to securely store API tokens after a user authenticates with a service. So I'm wondering what would happen if there's a central auth db setup (say on postgres), and then a plugin attempts to store something inherently user-specific like a API token? Either the db will be locked down and prevent this, or they'll clobber their work colleagues' token. Both situations are bad, and would ultimately break the plugin. 😱 (Or is the intention here that a centrally managed auth db is siloed into completely separate user "buckets" via db-level handling? )

Unless this situation is gracefully handled I can see this being a blocker for real-world use cases.

[elpaso]

Let's make a step back: the original goal was to provide a way to store credentials in a real client-server DB to remove the filesystem sqlite DB which is causing a lot of issues with QGIS server deployments in the cloud.

For the desktop there is an enterprise use case which I think is interesting (and I spotted in the wild when working with big government orgs in the past): centrally managed shared credentials for company's services.

With the new API you can have read/only storages and you can have multiple storages, so you can imagine using a read/write local storage for user overrides.

Also, you can subclass QgsAuthConfigurationStorage (if not SIP_ABSTRACT) or QgsAuthConfigurationStorageDb and create your own accessors to the DB with filters for the user.

I thought about adding a 'user' field or something similar to the tables but I thought it was too much specific and it wouldn't ever cover all use cases.

Coming back to your use case (if I get this right): if a plugin uses the auth system for its own secure storage it would probably be capable of managing its own keys naming convention to avoid clashes with other users.