Ho appena configurato un’istanza di Discourse e vi ho aggiunto discourse-openid-connect, collegando Keycloak come provider OIDC.
Dopo aver seguito le 3 condizioni indicate qui con un aggiornamento recente, ottengo il comportamento di autenticazione tramite Keycloak; oppure, se già accesso, cliccando sul pulsante “Accedi” mi viene chiesto di “Creare un nuovo account” con i campi precompilati con le informazioni sull’utente provenienti da Keycloak.
Esiste un modo per saltare questa fase che richiede un’ulteriore azione da parte dell’utente? Questi campi sono già naturalmente popolati da Keycloak, quindi non dovrebbe esserci la necessità che l’utente li modifichi specificamente per Discourse.
La creazione dell’account dovrebbe essere gestita implicitamente, in modo simile a come fa Grafana? Il mio obiettivo è che ogni servizio fornito dalla community supporti questa esperienza fluida, in modo che l’account community originale con cui ci si è registrati sia l’unico con cui l’utente debba interagire.
Questo potrebbe non avere senso se si pensa a autenticazioni esterne come Google / Facebook / Github / ecc. Un utente può registrare il proprio account community tramite Keycloak utilizzando uno di questi, ma è Keycloak stesso, utilizzato solo internamente, a dover funzionare con tutti i singoli servizi; pertanto, il consenso e la registrazione impliciti/automatici sono desiderabili.
Nuovo su Discourse, ho configurato e fatto funzionare il mio provider SSO OAUTH2. I nuovi utenti vedono la schermata di prompt al primo accesso e autenticazione su Discourse. Come posso semplificare questo processo e far sì che l’utente venga creato automaticamente? I valori visualizzati in quella schermata sono corretti e si tratta di un evento una tantum. Cosa posso fare per eliminare quella schermata e semplificare il processo di creazione dell’account per gli utenti della mia community?
Attualmente non è possibile. Quando gli utenti creano per la prima volta un account, dovranno fare clic sul pulsante “Crea nuovo account” nel modulo di registrazione.
Il comportamento che stai cercando è simile a quello dell’implementazione di SSO di Discourse. In quel caso, gli account vengono creati in background senza che l’utente compili il modulo di registrazione. Sembra che dovrebbe essere possibile implementare una funzionalità simile per gli accessi OAuth2, ma potrebbero esserci casi in cui non vengono fornite dal provider OAuth2 informazioni sufficienti per creare un account.
Non ho dedicato molto tempo a questo da quando ho pubblicato qui, ma alla fine ho optato per la funzionalità SSO di Discourse, utilizzando un servizio di ponte che ho trovato per OpenID-Connect. Si trattava di un servizio Python con un container Docker, che ha reso più semplice il deployment con la mia configurazione docker-compose.
Quindi, Keycloak forniva l’account già registrato e connesso; visitando Discourse, l’utente veniva registrato con i dettagli forniti dal ponte, se ricordo correttamente. È passato un po’ di tempo da quando ho lavorato a questo, ma il processo era leggermente migliore rispetto al supporto OAuth/OpenID-Connect di Discourse, per quanto ne so (almeno all’epoca; non ho verificato se siano stati apportati miglioramenti da allora).
In ogni caso, non si ottiene la sincronizzazione dei dettagli dell’account come previsto. L’utente deve disconnettersi da Discourse e riaccedere perché avvenga qualsiasi sincronizzazione, e anche in quel caso, credo che ci fossero alcuni elementi che non potevano essere sincronizzati dal provider SSO a Discourse (gruppi/ruoli, qualcosa del genere, se ricordo bene, presentava alcune insidie).
Penso che sia necessario rilevare gli aggiornamenti dei dettagli dell’utente da parte del provider per attivare l’aggiornamento di Discourse tramite le sue API, al fine di ottenere una configurazione di sincronizzazione corretta. Altrimenti, si possono avere dettagli duplicati non sincronizzati o una sincronizzazione confusa per gli utenti.
Quindi, ehm, se l’integrazione OAuth2 SSO che hai attualmente non è la funzionalità SSO di Discourse che in genere richiede un ponte SSO, per quanto ne so, ma piuttosto l’alternativa tramite plugin, passare alla versione non plugin con un ponte SSO dovrebbe ottenere l’esperienza desiderata, se ricordo bene.
Sono anche interessato a evitare questa finestra ‘Crea nuovo account’ quando si utilizza OAuth2.
Forse si potrebbe aggiungere un’opzione da qualche parte per saltarla se tutti i campi sono disponibili?
Ho appena aggiunto alcune nuove impostazioni del sito che aiuteranno in questo senso. Per saltare la schermata ‘crea nuovo account’, abilita sso_overrides_username, sso_overrides_email e sso_overrides_name.
Quindi, per saltare completamente il popup, abilita external_auth_skip_create_confirm.
Se non vedi quell’opzione, assicurati di essere sull’ultima versione di tests-passed.
È già stato creato un account test__EMAIL__ nel nostro Discourse
Se accedo con OpenID e username: test, email: test__EMAIL__
Appare una finestra “Nuovo account” che mi chiede un nuovo username test1 e l’email test__EMAIL__
Non esiste un modo per collegare il vecchio account a OpenID
Il tuo provider OpenID Connect verifica gli indirizzi email degli utenti? Possiamo ‘fidarci’ dell’email da OIDC solo se è stata verificata e il booleano verified è impostato correttamente.
Nessun provider OID - Keycloak con federazione utenti LDAP
Abbiamo trovato la soluzione: l’utente esistente può connettersi tramite OpenID nell’interfaccia delle impostazioni utente.
@david abbiamo la versione 2.5.2 stable - questa opzione è assente… Questa opzione può essere migrata al ramo stable? Ne abbiamo bisogno, ma in produzione non usiamo nulla tranne il ramo stable…
Mi dispiace, ma non eseguiamo il backport di nuove funzionalità sul ramo stabile. Tieni d’occhio #releases per informazioni su quando verrà rilasciata la prossima versione stabile.
