This is the road map for Qvarn software development.
To be finished by end of 2016
Make provisioning of a Qvarn+Gluu stack fully automated and share the necessary files with the world.
- It is currently quite a lot of manual work to set up a fresh Qvarn and Gluu pair. This takes time and effort, which could be spent on more useful things.
- Currently few people understand how to deploy Qvarn. That's detrimental to getting more users.
- Success criteria:
- A Heat stack for the virtual machines, networking, etc is created. Input: stack name.
- Software is installed fully automatically on the virtual machines such that Qvarn API tests can be run. This includes creating an OpenID Connect client for test-api. No manual steps are required beyond running Ansible.
- The Heat and Ansible files we use are published on github, without any secrets (password, ssh keys, etc) we need. The repo includes a README so that others can use the git repo for setting up their own instances.
- Everyone at QL uses the new repo and automation to set up their own stack for development.
Make resource types be configurable via the Qvarn API.
- Currently any changes to the supported resource types requires changing Qvarn source code and making a new Qvarn release. This is untenable with many users.
- Currently Qvarn developers are on the critical path for most Qvarn-using projects, and are often needed for consultation for any resource changes. This takes up too much time from them and is too much of a blocker for others.
- Success criteria:
- A freshly installed Qvarn has a minimal set of resource types.
- New resource types can be added, and existing ones can be changed and deleted via the Qvarn API.
- Changes to resource types happen immediately: it's not OK to have to restart Qvarn, and it must not be necessary to reconfigure haproxy to implement them.
- All existing resource types must be implementable with the new way, excluding validation code.
- Validation code will no longer be supported.
To be finished by end of Q2 2017
- An automated performance test suite, run regularly by CI, with measurements to identify critical bottlenecks.
- Make all users in Gluu also have a 1-1 corresponding person
resource. And vice versa.
- This will be needed for "my pages" applications
- Given a user in gluu, need a link to person resource, and vice versa
- Support virtual cards.
- Tie an "electronic card" (app on a smartphone, Yubikey, or similar) to a physical ID card.
- Support consent management, UMA: subjects need to give explicit consent to every type of use of their data.
Things for which deadlines have not been set yet
- Add to Qvarn API all necessary calls to manage users, clients, etc
- e.g., set authentication methods and credentials for users
- qvarn api clients shouldn't have to understand gluu apis
- Add API call to get complete and corresponding source code.
- Make security improvements based on audit. These mainly apply to system configuration, not Qvarn itself.
- Add an audit log: remote, chain of hashes, digitally signed, encrypted.
- Support resource version history via the Qvarn API.
- Rewrite Qvarn ORM to be less painful to maintain.
- Support automatic database indexing, vacuuming.
- Change all Qvarn stack nodes to disable unwanted outgoing network access.
- Add fine-grained ACL for Qvarn API access.
- Qvarn API: Wildcard listeners for resources.
- Support contract management, digital signing, transaction verification (possibly via block chains).
- Expose authentication method used by Gluu in the authentication
token given to Qvarn.
- This is meant to allow authorisation based on the strength of the authentication: username/password might be OK, for some things, but not for mass deletion.
- This may need to involve some kind of "strength level" definition, e.g., due to eIDAS.
- Record how a person has been identified during enrolment.
- To allow better evaluation of trust for a transaction.
- Change user authentication to Gluu to be able to specify user by any field (configured by sysadmin) in a person resource in Qvarn, instead of a username in Gluu ldap
- Make Qvarn logs be privacy-enabled. Also haproxy, uwsgi, Postgres,
- update: Qvarn 0.73 no longer logs all HTTP request and response bodies.
- Add API call for a dump of all the data about one person.
- Use CA-signed TLS-certificates for https on all hosts. Possibly using Let's encrypt. This applies to the provisioning recipes QvarnLabs itself uses.
- Support water stamping, digital signing of data Qvarn returns.
- Specify, document, publish development workflow, release policy, support structure.
- Support API versioning.
- Support monitoring, statistics.
- Add backup/restore support to Qvarn.
- Add sensible blob storage to Qvarn.
- Encryption of the database (store database on an encrypted disk).
- Encrypted resource fields.
- Fix the SPOF of the write-only node in Qvarn.