MWS Idea – Certificates for Roles

Developers
#1

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.

#2

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 (EDIT: and using certificates on both the “client” and “server” side of the connection) 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.

#3

I am just learning about certs so forgive the ambiguity on previous post.

This is interesting, let’s see if is afeature that interests more people and see how beneficial would it be compared to TW current user-password approach.

#4

I learn lots of things here. Up until this moment I thought ACME was where wil-e coyote bought his supplies from to catch the roadrunner!

1 Like
#5

Thanks @jrbntt your analysis is very helpful. I also appreciate your broad perspective here. I’d like MWS to be pluggable and flexible in the hands of people who are experienced with operational deployments, and to try to meet their expectations.

#6

Everyone starts somewhere, and this is something that I’ve got some small experience with and am glad to see you excited about it.

#7

There’s a gap in my analysis that I just realized when I returned to this thread. So a third use case to add to the two identified above:

  1. mTLS between TiddlyWiki and other services (eg: caddy, nginx, etc)

The issue that mTLS introduces (which I overlooked above) is that there might be some certificate presented to TiddlyWiki that is not an end-user certificate, but validates that the connection comes from a trusted source. For example, when configuring proxy settings on caddy, it might look like this:

example.com {
    reverse_proxy /wiki/* https://localhost:8443 {
        transport http {
           tls
           tls_client_auth /etc/PKI/example.com/client.crt /etc/PKI/example.com/client.key
        }
    }
}

Just an (unvalidated) example based on reading the documentation, so please don’t try to just copy+paste this for your own deployments without testing! But it shows the point, that the proxy server itself could be sending its own certificate to the upstream server (ie: TiddlyWiki), not the certificate for the end-user. This proxy certificate lets TiddlyWiki know that the connection is coming from a trusted proxy, but doesn’t actually tell it anything about the end-user who is accessing the wiki.

In such a configuration, I expect TiddlyWiki might use the existing WebServer Header Authentication, or HTTP Basic Auth, or the authentication service built in to MWS. For a single sign-on environment, I’d expect the proxy to validate the user certificate and then pass the valid username to the back-end service, which can do authorization based on that. This is really something separate from client certificates in TiddlyWiki itself, since I could already do this with a TLS-terminating proxy that authenticates the user and then proxies to the current Node.js TiddlyWiki on the back-end.

For the moment, the only other component I’ve used in deploying a Node.js install of TiddlyWiki is a reverse proxy, but I wouldn’t be surprised that other people incorporate TiddlyWiki into larger systems. Perhaps scripts or programs integrating with TiddlyWiki via the HTTP API. And what about Tiddlers that fetch content from other services? Putting a client certificate onto that request sounds like an interesting challenge.

1 Like