Discourse OpenID Connect (OIDC)

[Discourse]

	Riepilogo	Discourse OpenID Connect consente di utilizzare un provider OpenID Connect come provider di autenticazione per Discourse.
	Guida all’installazione	Questo plugin è incluso nel core di Discourse. Non è necessario installarlo separatamente.

Poiché si tratta di un plugin #ufficiale mantenuto dal team di Discourse, le richieste di Contribute > Bug, Contribute > UX e Contribute > Feature possono essere inviate nelle rispettive categorie qui su Meta, contrassegnate con l’etichetta del plugin appropriata. Il supporto è offerto in Support > SSO. Clicca su uno dei link sottostanti per aprirne uno.

Supporto Bug UX Funzionalità

Funzionalità

Il plugin mira a fornire un’implementazione minimale di la specifica. Nello specifico, supporta il “Flusso del codice di autorizzazione”. Per iniziare, segui le istruzioni per l’installazione del plugin o contatta il tuo provider di hosting.

Il nostro plugin oauth2-basic può essere utilizzato per connettersi ad alcuni provider openid-connect (OpenID Connect si basa su OAuth2). Tuttavia, questo plugin richiede molta meno configurazione manuale e può utilizzare il “ID Token” JWT se un’API JSON non è disponibile.

La configurazione viene eseguita automaticamente utilizzando un Documento di scoperta OpenID Connect. Secondo la specifica, questo dovrebbe trovarsi in <dominio_emittente>/.well-known/openid-configuration, ma Discourse supporta qualsiasi percorso per consentire implementazioni non conformi (ad esempio Azure B2C). Il documento di scoperta viene memorizzato nella cache per 10 minuti, per migliorare le prestazioni sui siti ad alto traffico.

Se il documento di scoperta include un parametro userinfo_endpoint, il plugin lo utilizzerà per raccogliere i metadati dell’utente. In caso contrario, il plugin estrarrà i metadati dal id_token (un JWT) fornito dall’endpoint del token. Il plugin NON verifica l’autenticità della firma JWT, poiché ciò aumenterebbe significativamente la complessità. Questa decisione è supportata da la specifica:

Se il ID Token viene ricevuto tramite comunicazione diretta tra il Client e l’Endpoint del Token (come avviene in questo flusso), la convalida del server TLS PUÒ essere utilizzata per convalidare l’emittente al posto della verifica della firma del token.

Per i provider di identità che supportano l’autorizzazione senza segreto utilizzando il “Flusso del codice di autorizzazione con chiave di prova per lo scambio di codici”, PKCE dovrebbe essere abilitato e la configurazione client_secret può essere omessa.

Configurazione

Opzioni di configurazione di base

• openid_connect_enabled: Abilita l’autenticazione OpenID Connect

• openid_connect_discovery_document: URL del documento di scoperta OpenID Connect. Normalmente situato in https://tuo.dominio/.well-known/openid-configuration

• openid_connect_client_id: ID client OpenID Connect

• openid_connect_client_secret: Segreto client OpenID Connect

• openid connect rp initiated logout: Reindirizza l’utente all’endpoint end_session_endpoint dopo il logout. Deve essere supportato dal tuo provider di identità e incluso nel documento di scoperta.

• openid connect rp initiated logout redirect: (opzionale) Il post_logout_redirect_uri che verrà passato all’endpoint di logout. Se fornito, deve essere registrato presso il provider di identità.

• openid_connect_authorize_scope: Gli ambiti (scopes) inviati all’endpoint di autorizzazione. Questo deve includere ‘openid’

• openid_connect_use_pkce: Abilita la Chiave di Prova per lo Scambio di Codici (PKCE) per l’autenticazione OpenID Connect.

• openid_connect_verbose_logging: Registra informazioni dettagliate sull’autenticazione openid-connect in /logs. Tieni questa opzione disabilitata durante l’uso normale.

Opzioni di configurazione avanzate

• openid_connect_token_scope: Gli ambiti inviati quando si richiede l’endpoint del token. La specifica ufficiale non lo richiede.

• openid_connect_error_redirects: Se il motivo dell’errore della callback contiene il primo parametro, l’utente verrà reindirizzato all’URL nel secondo parametro. Utilizzato per implementazioni insolite che inviano errori in risposta all’input dell’utente (ad esempio Azure B2C)

• openid_connect_allow_association_change: Consenti agli utenti di disconnettere e riconnettere i propri account Discourse dal provider OpenID Connect

• openid_connect_groups_claim: Il nome della clausola (claim) nella risposta OIDC^[1] che contiene i gruppi dell’utente come un array di stringhe. Lascia vuoto per disabilitare la sincronizzazione dei gruppi. Vedi Sincronizzazione dei gruppi di seguito.

• openid_connect_user_field_mappings: Mappature delle clausole OIDC^[2] che verranno memorizzate nei Campi Utente di Discourse. I campi utente sono identificati dal loro ID numerico, che può essere trovato nell’URL quando li modifichi tramite il pannello di amministrazione.

Sincronizzazione dei gruppi

Il plugin può sincronizzare automaticamente le appartenenze ai gruppi dal tuo provider OpenID Connect ai gruppi di Discourse. Ad ogni accesso, il plugin leggerà la clausola configurata dal token OIDC e aggiornerà di conseguenza le appartenenze ai gruppi dell’utente. Per abilitare la sincronizzazione dei gruppi:

1. Configura il tuo provider di identità per restituire un array di gruppi in una delle clausole. Questo deve essere un array di stringhe.

2. Imposta openid_connect_groups_claim sul nome della clausola nel token OIDC che contiene i gruppi dell’utente (ad esempio cognito:groups). Una volta impostato, inizierà a sincronizzare le informazioni con il sistema “Gruppi Associati” di Discourse.

3. Trova il Gruppo Discourse che desideri collegare. Vai su “Impostazioni” → “Membri” → “Automatico” e scegli i Gruppi Associati da collegare. Questo elenco a discesa viene popolato con le informazioni dal provider di identità, quindi almeno un membro del gruppo deve aver effettuato l’accesso affinché appaia un’opzione.

Esempio di configurazione

Qui configureremo il plugin openid-connect per connettersi al provider OpenID Connect di Google. Questo replica una funzionalità già esistente nel core di Discourse, ma funge da esempio accessibile.

1. Vai su OpenID Connect  |  Sign in with Google  |  Google for Developers e segui le istruzioni per ottenere le credenziali OAuth.

2. Nella stessa pagina, segui le istruzioni per aggiungere un URI di reindirizzamento. Questo dovrebbe essere https://<tuo_forum>/auth/oidc/callback (senza una barra finale)

3. Vai alle impostazioni del tuo sito Discourse e cerca “openid_connect”

   • openid connect enabled: [x]

   • openid connect discovery document: https://accounts.google.com/.well-known/openid-configuration

   • openid connect client id: <client-id>

   • openid connect client secret: <client-secret>

   • openid connect authorize scope: openid email (con uno spazio in mezzo)

4. Fatto. Il pulsante “Accedi con OpenID Connect” ora effettuerà l’accesso utilizzando Google . Questi stessi passaggi possono essere applicati ad altri provider con modifiche minime.

Debugging

Oltre all’impostazione verbose_logging descritta sopra, puoi accedere ai dati sulle associazioni OIDC utilizzando il plugin data-explorer:

SELECT user_id, provider_name, provider_uid
FROM user_associated_accounts
WHERE provider_name = 'oidc'

O sulla console rails:

User.find_by_username("david").user_associated_accounts.where(provider_name: 'oidc')

Note specifiche per provider

Sentiti libero di aggiornare questa sezione se trovi stranezze specifiche di un provider relative a questa integrazione:

Entra ID (precedentemente Azure AD)

Aggiungi l’ambito email e assicurati di utilizzare il documento di configurazione dell’endpoint versione 2. Ad esempio

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

@andy.czerwonka

• Assicurati di utilizzare la versione 2.0 dell’endpoint di configurazione come indicato nelle note sopra. L’endpoint v1.0 predefinito non supporta gli ambiti email o profile.
• Se ci sono problemi con il segreto client, prova a generarne uno nuovo. Abbiamo avuto alcuni problemi, ma dopo averne generati un paio sembrava tutto a posto.
• Assicurati di attivare “Accedi e leggi il profilo utente” come “Autorizzazione delegata” in Azure AD quando crei la voce per il tuo sito.
• Assicurati di aggiungere il callback corretto, che è ‘https://tuo-sito/auth/oidc/callback’

Azure B2C

I dettagli dell’URL del documento di scoperta si trovano qui: Web sign in with OpenID Connect - Azure AD B2C | Microsoft Learn

Ad esempio, il documento di metadati per il flusso utente b2c_1_sign_in in fabrikamb2c.onmicrosoft.com si trova in:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=b2c_1_sign_in

Per far funzionare le email:

@Umer_Nawab

Per ottenere l’email nelle clausole, dovrai utilizzare policy personalizzate. Per farlo, ho utilizzato il pacchetto di avvio delle policy menzionato qui:

Tutorial - Create user flows and custom policies - Azure Active Directory B2C | Microsoft Learn

Dopo aver implementato i passaggi menzionati nell’articolo sopra, la clausola email è iniziata ad apparire quando l’utente si è registrato, ma quando un utente esistente ha effettuato l’accesso, la clausola email mancava dal token. Poi ho dovuto apportare alcune modifiche al file XML della policy personalizzata seguendo i passaggi menzionati in questo post:

https://stackoverflow.com/questions/59669666/email-claims-not-populated-with-custom-policies-in-azure-b2c

Dopo queste modifiche, la clausola email ora appare quando l’utente si registra e anche quando l’utente effettua l’accesso.

Yahoo

1. Vai su https://developer.yahoo.com/apps e crea una nuova app

2. Inserisci il nome dell’applicazione e imposta il dominio di callback sul dominio del tuo forum (ad esempio meta.discourse.org)

3. Sotto Autorizzazioni API, scegli Profili: Lettura/Scrittura Pubblica e Privata. Questo è l’unico modo che conosco per ottenere l’indirizzo email dell’utente

4. Salva l’app

5. Nelle impostazioni OIDC di Discourse, imposta il documento di scoperta su

   https://login.yahoo.com/.well-known/openid-configuration
   

6. Inserisci l’ID client e il segreto da Yahoo

7. Abilita il plugin OIDC

AWS Cognito

1. Vai su Cognito e seleziona o crea un nuovo pool di utenti.
2. Definisci un’app in Client app.
3. Lascia tutto ai valori predefiniti, ma modifica la configurazione dei Flussi di Autenticazione per selezionare solo ALLOW_REFRESH_TOKEN_AUTH.
4. Vai alle impostazioni del client app e seleziona la nuova app.
5. Modifica l’URL di callback in https://tuosito.example.com/auth/oidc/callback.
6. Seleziona solo il flusso di concessione del codice di autorizzazione tra “Flussi OAuth consentiti”.
7. Seleziona tutti gli ambiti necessari (io li ho tutti selezionati).

Okta

1. Configura Discourse con l’ID client e il segreto della tua app Okta

2. Imposta l’URL del documento di scoperta su

   https://{tua-app}.okta.com/.well-known/openid-configuration
   

3. In Discourse, imposta openid connect authorize scope su openid email

Ospitato da noi? Questo plugin è disponibile nei nostri piani Business e Enterprise. OAuth 2.0 & OpenID Connect Support | Discourse - Civilized Discussion

Devi automatizzare le registrazioni degli utenti? Vedi Auto-provisioning user accounts when SSO is enabled

---

1. token o payload userinfo ↩︎

2. dal token o dal payload userinfo ↩︎