WIP: make it work

Signed-off-by: Louis Chmn <louis@chmn.me>

README.md

@@ -297,10 +297,12 @@ instances.
 
 ## Global scale
 
-You can start a lookup-server service when starting an instance:
+You can start a lookup-server service when starting an instance. Adding an
+authentik single sign-on service lets the master route accounts it has never
+seen before:
 
 ```bash
-haze start --name gs-master lookup
+haze start --name gs-master lookup oidc
 ```
 
 The Nextcloud instance started with this command is already properly configured
@@ -308,7 +310,7 @@ as master node.
 
 If you want to work on the lookup_server, you can set the `lookup_server_source` config in `haze.toml`. This will mount your local checkout of the lookup server into the container.
 
-You can then start slave instance with the following command:
+You can then start slave instances with the following command:
 
 ```bash
 haze start --name gs-slave1 slave
@@ -317,28 +319,48 @@ haze start --name gs-slave1 slave
 A slave attaches to the most recently started instance running a lookup server,
 and is pointed at both that lookup server and the master instance automatically.
 
-If you want to use the `ManualUserMapping` module, you'll have to set the
-following config on the master instance:
+### How accounts are routed
+
+The master is configured to use the `ManualUserMapping` discovery module, which
+resolves a node name coming from the identity provider to the address of a
+slave. Haze keeps that mapping in `gs-user-mapping.json` in the config folder of
+the master, and every slave adds itself to it when it starts, under its node
+name (`slave1`, `slave2`, ...), its instance name (`gs-slave1`) and its full
+cloud id (`haze-gs-slave1`). Entries of instances that are no longer running are
+dropped. The file is read on every login, so no restart is needed after starting
+a slave.
+
+The accounts shipped in the authentik blueprint carry the node name they belong
+to in the `nextcloud_gss_node` user attribute: alice is routed to `slave1`, bob
+to `slave2` and charlie to `slave3`. Logging in on the master with "Log in with
+Authentik OIDC" as alice redirects to the first slave, which creates the
+`oidc-alice` account on the fly.
+
+An account without a `nextcloud_gss_node` value is rejected with "Unknown
+Account". If you want a catch-all instead, switch the dictionary to regular
+expressions and use regex keys:
 
 ```bash
-haze gs-master occ config:system:set gss.user.discovery.module --value="\\OCA\\GlobalSiteSelector\\UserDiscoveryModules\\ManualUserMapping"
-haze gs-master occ config:system:set gss.discovery.manual.mapping.file --value="/shared/config/gs-user-mapping.json" # See the volume section below for how to mount this file into the container.
 haze gs-master occ config:system:set gss.discovery.manual.mapping.regex --type boolean --value=true
 ```
 
-```toml
-[[volume]] # Needed if you are using "ManualUserMapping" module.
-source = "/home/louis/.config/haze/config/gs-user-mapping.json"
-target = "/shared/config/gs-user-mapping.json"
-read_only = true
-```
+Accounts that are already registered in the lookup server are routed without the
+discovery module, so they also work with a password login. Each slave seeds one
+such account, named after the instance (`gs-slave1` on `haze-gs-slave1`) with
+the usual haze password, to make that path easy to try out. Because that password
+is usually too weak for the default policy, the length and common-password checks
+of `password_policy` are turned off on slaves.
+
+The mapping file can be inspected on the host, in the config folder of the master
+within the haze work directory, e.g.
+`/tmp/haze/haze-gs-master/config/gs-user-mapping.json`.
 
 You can test the connection between the instances and the lookup server by
-running the following command on the slave instance:
+running the following commands:
 
 ```bash
 haze gs-master occ globalsiteselector:discovery
-haze gs-slave1 occ globalsiteselector:discovery
+haze gs-slave1 occ globalsiteselector:discovery --current
 ```
 
 ## Proxy