Come limitare la registrazione degli utenti su un server Matrix self-hosted

Su un server Matrix self-hosted, "limitare la registrazione" può significare qualsiasi cosa, dal bloccare tutte le registrazioni pubbliche al consentire l'accesso solo a chi possiede un codice di invito. Per Synapse, la scelta più semplice è disabilitare la registrazione pubblica. Se si desidera comunque che nuovi utenti si iscrivano, è necessario richiedere token di registrazione e assegnare a ciascuno un token limitato e con scadenza. Questi controlli influiscono sulla creazione di nuovi account locali; non rimuovono gli utenti esistenti né disabilitano la federazione Matrix.

Scegli il controllo più adatto al tuo server

Gli esempi seguenti si riferiscono a Synapse. Dendrite, Conduit e altre implementazioni di homeserver utilizzano interfacce di configurazione e amministrazione diverse. Consulta la documentazione del tuo server prima di applicare le impostazioni di Synapse.

Opzione 1: Disattivare la registrazione pubblica

Per un server domestico privato, una piccola organizzazione o un server in cui un amministratore gestisce ciascun account, disabilitare la registrazione dei client nella configurazione Synapse attiva:

enable_registration: false

Synapse documenta questa impostazione come disabilitata per impostazione predefinita. Modifica il file di configurazione effettivamente caricato dal tuo servizio o container, convalida il file YAML, quindi riavvia Synapse utilizzando la normale procedura di gestione dei servizi. Un'implementazione Docker potrebbe montare la configurazione da un percorso host, quindi la modifica di un file con un nome simile all'interno del container potrebbe non modificare il file utilizzato all'avvio.

Con la registrazione disattivata, gli utenti non possono creare nuovi account tramite il normale flusso di registrazione del client. Gli amministratori possono comunque creare account tramite i metodi amministrativi supportati. Synapse avverte specificamente che l'impostazione registration_shared_secretconsente la creazione di account utilizzando quel segreto anche se enable_registrationè falsa. Trattatelo come una credenziale ad alto impatto: tenetelo fuori dai repository, dalle chat e dai dump dell'ambiente pubblico; limitate l'accesso; e conservatelo solo se il flusso di lavoro amministrativo lo richiede. Chiunque sia in possesso del segreto può creare account, inclusi gli account amministratore.

Se utilizzi OIDC, CAS o un'altra integrazione SSO, verifica anche l'impostazione di registrazione automatica di tale provider. Synapse documenta le impostazioni di registrazione a livello di provider perché altrimenti un utente potrebbe essere creato automaticamente al primo accesso SSO riuscito. Per OIDC, controlla oidc_providers[].enable_registrationanche l'impostazione di registrazione generale.

Opzione 2: Consentire la registrazione solo con token

Utilizzare i token di registrazione quando i membri devono essere in grado di creare i propri account, ma le registrazioni devono essere approvate o distribuite da un amministratore. Nella configurazione di Synapse, impostare entrambi i valori:

enable_registration: true
registration_requires_token: true

Sono necessari entrambi: l'impostazione del token richiede un token durante la registrazione, mentre la registrazione stessa deve essere abilitata. Applica la modifica e riavvia Synapse. Gli account esistenti e i token creati in precedenza non vengono rimossi modificando questa impostazione.

Crea un token a uso limitato

Synapse fornisce un'API di amministrazione per i token di registrazione. Le richieste richiedono un token di accesso amministrativo. Ad esempio, questa richiesta crea un token che può completare una registrazione:

curl -sS -X POST "$SYNAPSE_URL/_synapse/admin/v1/registration_tokens/new" \
  -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"uses_allowed": 1}'

Sostituisci le variabili d'ambiente con l'URL di base del tuo homeserver e un token di accesso amministratore. Mantieni riservato il token amministratore ed evita di incollare comandi contenenti credenziali reali nei log condivisi o nei post di supporto. L'API può anche accettare un tempo di scadenza in millisecondi dall'epoca Unix. Utilizza un token monouso per ogni invito e imposta una data di scadenza quando il tuo flusso di lavoro può calcolarla e gestirla in modo affidabile. Un token con limiti omessi potrebbe avere utilizzi illimitati e nessuna scadenza, quindi controlla i campi restituiti prima di distribuirlo.

Per ispezionare i token, un amministratore può chiamare GET /_synapse/admin/v1/registration_tokens. La risposta include gli usi consentiti, le registrazioni in sospeso, le registrazioni completate e la data di scadenza. Se un token viene divulgato, aggiorna gli usi consentiti a zero o eliminalo tramite l'API di amministrazione documentata. Un token è una credenziale di registrazione, non un invito a una stanza Matrix; non unisce automaticamente il nuovo account a una stanza.

Nota importante sulla compatibilità: l'API di amministrazione del token di registrazione di Synapse è disabilitata quando è abilitata l'integrazione con Matrix Authentication Service (MAS). In tale configurazione, utilizzare invece l'API di amministrazione MAS o la CLI MAS documentate per la propria implementazione. Non dare per scontato che un comando per il token di Synapse funzioni senza modifiche con MAS.

Opzione 3: Aggiungere controlli alla registrazione pubblica

Se il tuo obiettivo è consentire a chiunque di richiedere un account, richiedere token potrebbe essere troppo restrittivo. La configurazione di Synapse documenta anche i requisiti CAPTCHA e di identificazione di terze parti come possibili verifiche. Il CAPTCHA dipende da un provider configurato correttamente e potrebbe comportare costi aggiuntivi in ​​termini di accessibilità e privacy. Richiedere un indirizzo email o un numero di telefono può aggiungere dipendenze di configurazione e verifica; non è la stessa cosa di approvare ogni singolo account. Verifica quali servizi di verifica sono effettivamente supportati dalla tua versione e dal flusso client prima di rendere un requisito di identificazione di terze parti un ostacolo.

La limitazione della frequenza delle richieste è utile in aggiunta a questi controlli perché riduce le richieste ripetute, ma non decide chi è autorizzato a registrarsi. Monitora i tentativi di registrazione e i log del server e configura i limiti in base al traffico e alla configurazione dell'ambiente. Evita di copiare vecchi frammenti di configurazione senza verificare la versione di Synapse installata: le opzioni di registrazione e del servizio di identità sono cambiate nel tempo.

Cosa cambia (e cosa non cambia) la chiusura delle iscrizioni.

• Controlla i nuovi account locali. Disabilitare la registrazione blocca il normale flusso di creazione degli account sul tuo server domestico.
• Non elimina gli account. Gli utenti esistenti mantengono i propri account a meno che non vengano sospesi o disattivati ​​separatamente.
• Questa operazione non disattiva la federazione. Gli utenti su altri homeserver possono comunque comunicare con gli utenti e le stanze locali, in base all'appartenenza alla stanza e alle impostazioni di federazione.
• Ciò non rende la stanza accessibile solo su invito. Le regole di accesso alla stanza sono un'impostazione separata; i token di registrazione non sostituiscono gli inviti alla stanza.
• Ciò non blocca necessariamente ogni percorso di provisioning. Le API di amministrazione, una chiave segreta condivisa configurata, i servizi applicativi e le impostazioni di creazione dell'account SSO richiedono una revisione separata.

Una regola di reverse proxy che nasconde l'URL di registrazione può rappresentare un ulteriore controllo a livello di rete, ma è facile interrompere i flussi dei client e non sostituisce la configurazione del server domestico. Utilizzare l'impostazione a livello di applicazione come controllo principale e testare l'implementazione effettiva dopo qualsiasi modifica al proxy.

Verificare il risultato

1. Verificare che la sorgente di configurazione effettiva, inclusi eventuali bind mount del container o configurazioni generate, corrisponda ai valori di registrazione previsti.
2. Riavvia Synapse e controlla i log di avvio per individuare eventuali errori YAML o impostazioni non supportate.
3. Da un client Matrix disconnesso, prova ad avviare una nuova registrazione. Con la registrazione disabilitata, il flusso non dovrebbe offrire una procedura di registrazione pubblica utilizzabile. Con la registrazione tramite token abilitata, una richiesta senza un token valido non dovrebbe essere completata.
4. Per la registrazione del token, esegui un test con un token temporaneo monouso e verifica che completi la creazione di un solo account. Esamina la risposta dell'API di amministrazione per informazioni su completed, pending, e scadenza.
5. Verifica un percorso SSO configurato separatamente e gli eventuali script di provisioning degli account. Assicurati che si comportino in conformità con i criteri di accesso definiti.

Non utilizzare un token di invito reale per un account di prova a meno che tu non intenda utilizzarlo. Se l'impostazione sembra inefficace, verifica innanzitutto di aver modificato il file effettivamente caricato da Synapse e che il servizio sia stato riavviato. Quindi controlla la presenza di una chiave segreta di registrazione condivisa, la registrazione automatica SSO o un altro meccanismo di provisioning affidabile.

Riferimenti ufficiali

• Manuale di configurazione di Synapse 1.160: impostazioni di registrazione
• API di amministrazione del token di registrazione Synapse
• Guida all'installazione di Synapse: registrazione di un utente
• API di registrazione del segreto condiviso di Synapse
• Specifiche dell'API client-server di Matrix

La documentazione di Synapse relativa alla configurazione versionata e all'API di amministrazione rappresenta la fonte di riferimento per i nomi delle opzioni e i campi delle richieste. Le istruzioni sopra riportate non presuppongono un sistema operativo, un'immagine container, un proxy inverso o un client Matrix specifici; si consiglia di verificare tali dettagli specifici dell'implementazione prima di applicare le modifiche.