Sto cercando di comprendere meglio le opzioni per un progetto di ristrutturazione su cui sto lavorando. Ho cercato nei forum per ottenere ulteriori approfondimenti e, sebbene abbia trovato una domanda simile, lo scenario dell’OP è in qualche modo diverso dal nostro, quindi ho deciso di creare questo nuovo argomento.
Attualmente abbiamo un sito WordPress su domain.com configurato come client SSO per l’istanza di Discourse su community.domain.com, ma il sito WP sta venendo riorganizzato come rete multisito, ad esempio sub1.newdomain.com, sub2.newdomain.com, ecc., con un’istanza separata di Discourse per ogni sito, ad esempio forum.sub1.newdomain.com (o idealmente sub1.newdomain.com/forum, se riusciamo a risolvere la configurazione delle sottocartelle).
Vogliamo che i nostri utenti abbiano un’unica identità in tutte le community e sappiamo come sincronizzare gli utenti che si registrano su un sottosito WP in tutta la rete. Comprendo che un’istanza di Discourse può fungere da server SSO per un’altra, ma non sono riuscito a trovare conferma su come configurare ciò o se ciò funzioni per più client Discourse.
Passiamo quindi alle mie domande:
Nello scenario descritto, è possibile configurare un’istanza di Discourse su, ad esempio, auth.newdomain.com per fungere sia da server SSO per la rete WPMS che da tutte le istanze di Discourse collegate ai sottositi?
Se la risposta alla domanda precedente è sì, sarebbe fattibile configurare quell’istanza “server” in modo che fornisca solo funzionalità relative all’autenticazione? Cioè, non avrebbe altro scopo se non quello di essere la “fonte di verità” per l’autenticazione di tutta la rete, indipendentemente dal sito contro cui un utente desidera autenticarsi. O sarebbe più appropriato affidarsi in questo punto a una soluzione di autenticazione esterna?
Ehi, questo è apparso per me dato che hai collegato il mio argomento originale. Lascio a @simon di esprimere il suo parere, ma un’opzione che potrebbe funzionare per te (e sarebbe molto più semplice) è configurare un’unica istanza di Discourse e utilizzare i gruppi per separare i forum. Puoi inviare le informazioni sui gruppi nel payload SSO.
Tuttavia, avere più forum con uno solo che fornisce l’SSO dovrebbe essere abbastanza semplice (anche se non l’ho mai provato prima). Credo che i passaggi sarebbero:
Aggiungi il plugin WP Discourse e configuralo come client SSO (nelle opzioni di rete)
Configura il forum Discourse che desideri utilizzare come provider SSO (aggiungi le chiavi segrete a WP e Discourse, ecc.)
Da lì, quando aggiungerai i forum successivi, questi verranno configurati come client SSO (e dato che WP Discourse è configurato a livello di rete, non dovrai modificare alcuna configurazione quando aggiungi nuovi siti).
Grazie mille per aver condiviso i tuoi suggerimenti, @jakeols. So che i gruppi sono l’alternativa più comunemente proposta, ma non si adattano al nostro caso d’uso specifico.
Spero che @simon possa offrire qualche informazione su cosa è e cosa non è possibile fare in questo contesto.
È possibile utilizzare Discourse come provider SSO in una rete multisito. Questa funzionalità è abilitata solo se si configura un singolo sito Discourse come provider SSO per tutti i siti della rete. Il motivo è che in una rete multisito tutti gli utenti sono archiviati in un’unica tabella del database. Se più siti Discourse fossero autorizzati a funzionare come provider SSO per diversi siti della rete, non esisterebbe un modo semplice per garantire che gli ID utente di Discourse salvati su WordPress siano univoci.
Quando il plugin WP Discourse viene installato su una rete multisito, una scheda Discourse viene aggiunta al menu di Amministrazione della rete. Per configurare Discourse come provider SSO per tutti i siti della rete, vai alla pagina di Amministrazione della rete e seleziona Discourse dal menu. Seleziona l’opzione “Abilita configurazione multisito” e compila le Impostazioni di connessione. Quindi scorri verso il basso fino alla sezione Impostazioni SSO. Seleziona l’opzione “Abilita client SSO”. Inserisci la tua chiave segreta SSO e salva la pagina delle impostazioni.
È importante tenere presente che l’attivazione della funzionalità client SSO su una rete multisito potrebbe potenzialmente concedere a qualsiasi utente del tuo forum Discourse l’accesso a qualsiasi sito della tua rete.
In sostanza, se stai cercando di ottenere qualcosa di diverso dall’utilizzo di Discourse come provider SSO per una rete multisito WordPress, dovrai arrangiarti da solo. Sarebbe tecnicamente possibile consentire a più siti Discourse di funzionare come provider SSO per singoli siti di una rete WordPress, ma la configurazione necessaria sarebbe eccessivamente complessa. Non credo che questa funzionalità verrà mai aggiunta al plugin WordPress.
Grazie mille per la tua risposta. Il post che hai citato è proprio quello a cui mi riferivo nel mio messaggio originale. Non ho realmente problemi lato WordPress: sappiamo come connetterci a livello di rete e sincronizzare gli utenti su tutti i sottositi. Ciò che cerco di capire è come configurare un’istanza di Discourse affinché funga da server SSO per un’altra. Stavo cercando di chiarire se sia possibile farlo anche quando l’istanza di Discourse che gestisce l’autenticazione è contemporaneamente il server SSO per WordPress.
Non sono riuscito a trovare alcuna documentazione sulla configurazione Discourse-Discourse. Se potessi indicarmi dove reperire ulteriori informazioni o semplicemente elencare i passaggi necessari, te ne sarei immensamente grato.
Capisco il tuo punto di vista, ma Discourse non è pensato per essere utilizzato esclusivamente a fini di autenticazione. Ti suggerirei di dedicare del tempo a valutare un servizio di autenticazione dedicato, da collegare alle tue diverse istanze di Discourse e WordPress. Un piccolo investimento in ricerca ora può ripagarsi in futuro.
Il mio consiglio principale è che ciò che proponi è complesso e, indipendentemente dalla strada che sceglierai, devi configurare un ambiente di staging che rispecchi quello di produzione previsto, per sperimentare diverse configurazioni prima di metterlo in produzione. Questo tipo di configurazione può essere influenzato da molte variabili diverse ed è difficile dare consigli in astratto.
So che l’idea di configurare un ambiente di staging completamente separato per una rete interconnessa di server può sembrare laboriosa, ma il lavoro richiesto è molto inferiore rispetto a quello necessario per risolvere problemi imprevisti che potrebbero sorgere una volta lanciato un progetto del genere.
Sì, riconosco che Discourse non sia un servizio di autenticazione puro. Stiamo valutando tre opzioni potenziali:
Utilizzare Discourse come nostro provider di identità
Utilizzare WordPress come nostro provider di identità
Utilizzare un provider di identità esterno (SaaS o self-hosted)
Ognuna di queste opzioni presenta implicazioni diverse per costi, complessità e esperienza utente, che stiamo cercando di valutare, da qui le mie domande qui.
No, hai assolutamente ragione, è davvero complesso e non penseremmo mai di distribuire questa soluzione senza prima testarla in un ambiente di staging. Grazie mille per la spiegazione, molto apprezzata!
