We imagine controlling visibility of wiki pages on a site or farm similar to operating a server on a private LAN but using distinguished logins rather than network access.
We will describe a simple configuration that might meet the needs of a school or company that manages email addresses within a specific domain name. We'll then consider variations on this base use case.
# School
All students and staff to be authorized to read will have authenticated with an email address at the school's unique domain already managed by the school.
Any so authenticated user can claim a not yet claimed site which will authorize write for that user alone.
An unauthenticated reader will be invited to authenticate with a suitable email address and little more.
The suffix that distinguish a schools unique email domain will be specified by a server configuration parameter.
# Variations
A district with multiple schools might serve multiple domains from the same farm at distinct domains and with distinct email suffix conventions.
Multiple email domains might be configured with read access to a given wiki subdomain.
What if some classes at the school wanted private discussion for the class only?
A student or staff might be restricted to claiming subdomains consistent with their email address. See Registration Workflows
Retrieval of sitemaps should be similarly restricted to logged in users.
Server-side plugins would only be restricted if the plugin logic recognized the need for read authorization. For Rss plugin maybe yes, Json plugin maybe not.
.
Diving into some technical details...
GPG can encrypt pages to be decrypted by any one of multiple recipients:
# gpg: enable many people to decrypt a message gpg --encrypt \ --recipient alice@example.com \ --recipient bob@example.com \ clear-message.txt
> GPG encrypts the file once with a symmetric key, then places a header identifying the target keypair and an encrypted version of the symmetric key.
>
> [...] When encrypted to multiple recipients, this header is placed multiple times providing a uniquely encrypted version of the same symmetric key for each recipient.
>
> stackoverflow 
- [ ] Compare GPG multiple recipients with envelope encryption described in Better Kubernetes Secrets
- [ ] See how both of these would interact with Sessionless
- [ ] explore browser options for dat & static wiki variants
CloudFlare built OpenCA using WebCrypto and PKI.js
article
webcrypto
pki.js
caniuse#cryptography
TLS becomes important when transmitting passwords over the internet. Here is an example configuration for Caddy to include HTTP basic auth in addition to terminating TLS connections for the domain.
https://{$AUTH_DOMAIN}, http://{$AUTH_DOMAIN} { gzip basicauth / {$AUTH_NAME} {$AUTH_PASS} proxy / {$ORIGIN} { transparent } }
This configuration uses a single shared password, so not best practice. Nevertheless useful for exposing some work: basic auth breaks the wiki sharing. The client javascript needs to learn to include auth headers when requesting `wiki.example.com/slug.json` from other wikis in the protected federation.
While I was getting the above to work I also learned of a few more recent caddy plugins which might work better than basic auth. https://caddyserver.com/docs/http.jwt https://caddyserver.com/docs/http.login https://caddyserver.com/docs/http.authz
.
Paul adds, Not sure about gpg - it won't cope with people joining/leaving the group. Or maybe it would - but you would need to re-encrypt whenever membership of the group changed, changing the document key as well.