MWS Idea – Certificates for Roles

A MWS has a user-password Autentication and Authorization system in place so is able to control which users can edit specific parts of a shared wiki (bags).

Recently I discovered the world of ACME and I think It would nicely integrate with MWS roles and bags approach.

I think that would be very cool to have a certificate management console within the roles section of MWS so we can see wich user can acces or edit wich bag and for how long (also we could track login requests).

Furthermore with a certificate system and mTLS in place we could give edit permissions to specific bags for a pre-set amount of time and could discriminate by IPs and so on.

Adding certificate authentication for users might be a neat feature, but I don’t see why it would be limited to the MWS. This could live alongside the existing HTTP Basic authentication and Header authentication methods (https://tiddlywiki.com/#WebServer%20Authentication).

Typically, the service would trust a particular CA root for authenticating clients and any valid certificate that is rooted in a chain from that trusted CA would be allowed. Then, the service can perform authorization (ie: what the user is allowed to access) based on the principal identified in the valid certificate. There are two separate concepts, although they are often bundled together into a single logical step.

ACME is an automated method for issuing certificates typically used by servers, not for end-user applications like web browsers. So integrating ACME into TiddlyWiki could allow it to automatically request and renew certificates (versus using the tls-cert and tls-key parameters to the web server). However, there would still need to be a way to get user certificates into the web browser.

Although user authentication is certainly within the scope of mTLS, the “clients” in most mTLS discussions are usually other servers. If I’m setting up a “server” that’s actually multiple Node.js processes, a database, a Redis instance, etc., then adding mTLS means that each of these components are using TLS when they talk to each other.

Running TiddlyWiki as a single-wiki Node.js server or as the MWS is only a single Node.js instance, so there aren’t any other components for which we would need an encrypted communication channel. In MWS, the database is embedded, so even that doesn’t required a network connection. The place I could see mTLS being relevant is to protect communication between a reverse proxy like caddy or nginx to a TiddlyWiki instance. ACME support isn’t necessary for that, although it could certainly make automating the certificate management more simple.

I see two separate but related ideas here:

  1. User authentication via client certificates.
  2. Server certificate automated request and renewal via ACME

#1 would be an interesting new feature. It could especially be useful in corporate or government environments, where it’s slightly more likely that end-users will have some form of PKI loaded into their web browser. For general public use, I’m not aware of any simple, user-friendly way of getting certificates for the masses.

For #2, there are already some ways this could be implemented without needing to actually make changes to TiddlyWiki. ACME command line tools like certbot or amce.sh could be used to request and renew certs programmatically, while TiddlyWiki is configured to point to the certificates those tools output.