Questo è fantastico, molto meglio del plugin oauth2, che non funzionava. Ma questo funziona (con Keycloak).
Tuttavia, più origini oidc sarebbero una funzionalità molto gradita.
È un’idea interessante. Puoi parlarci di più del tuo caso d’uso per spiegarne i vantaggi e, se possibile, quali origini di accesso vorresti utilizzare?
Risposta alla domanda nel post n. 2 sopra: il nostro caso d’uso e le fonti di accesso di cui abbiamo bisogno.
Gestiamo un forum pubblico di comunità per un’iniziativa di ricerca dell’UE, ospitato su un servizio di hosting gestito di Discourse all’interno dell’UE.
Abbiamo bisogno di abilitare contemporaneamente due provider OIDC:
- EU Login, il provider di identità della Commissione Europea. Viene utilizzato dal personale della Commissione, dalle parti interessate alle politiche e dai partecipanti ai progetti finanziati dall’UE. È un OIDC standard, con il documento di discovery disponibile presso
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration. - EGI Check-in, un proxy di identità accademica federata che gestisce gli account istituzionali e ORCID. È utilizzato in tutte le infrastrutture di ricerca europee. Anche in questo caso si tratta di OIDC standard.
Nessuno dei due copre gli utenti dell’altro. Un funzionario politico accede con EU Login e non ha un’identità di ricerca istituzionale. Un ricercatore accede con un account universitario o con ORCID tramite il nostro proxy e non ha EU Login. La nostra comunità è composta da entrambi i gruppi, quindi la scelta di un singolo provider significherebbe escludere metà delle persone per cui il forum è stato creato.
Entrambi i provider supportano OIDC standard e ciascuno funziona da solo. Il problema è che discourse-openid-connect espone un unico spazio dei nomi per le impostazioni non numerato: openid_connect_client_id, anziché openid_connect_1_client_id e openid_connect_2_client_id. È possibile configurare solo un provider OIDC per sito.
Sarebbe utile avere il supporto per più provider. La forma più naturale sarebbe uno spazio dei nomi per le impostazioni per ciascun provider, che potrebbe consistere in impostazioni numerate o in un elenco gestito dall’amministratore, dove ogni provider ha il proprio documento di discovery, le proprie credenziali del client, lo scope e il titolo del pulsante.
Esiste un precedente in Multiple openid-connect authentication providers del 2021, in cui la necessità riguardava diversi realm di Keycloak. Si tratta della stessa limitazione in una forma diversa.
Possiamo fornire ulteriori informazioni se necessario, oppure testare implementazioni se ciò può essere d’aiuto.
1 Mi Piace
Una cosa che potresti provare è configurare un servizio Authentik e “federarlo” con questi due provider. In questo modo potresti avere un SSO interno per il tuo team e un SSO proxy per gli utenti esterni. Sarebbe un po’ più complicato, considerando la necessità di ospitare il proprio SSO, ma potrebbe essere più rapido rispetto alla modifica del plugin OIDC, a seconda delle tue capacità.
Detto ciò, vedo impostazioni (Corporate Login Provider) ovunque nelle impostazioni di Discourse, quindi sarebbe davvero bello poter aggiungere le nostre. Forse forcare il plugin OIDC e cambiare i nomi?
4 Mi Piace
Grazie per il suggerimento. Il servizio di check-in EGI è già un proxy IdP che consente l’uso di numerosi IdP.
Il vincolo attuale è che la policy di EU Login non consente l’uso di un proxy. È richiesta una connessione diretta con il servizio.
1 Mi Piace
In tal caso, se l’altro può gestire OAuth2, puoi configurarlo tramite Discourse OAuth2 Basic, in modo da poter mantenere OIDC per EU EIDAS. In passato c’era anche un plugin SAML, forse è stato deprecato.
2 Mi Piace
Grazie per la suggerimento. In effetti, stiamo attualmente valutando l’uso di Discourse OAuth2 Basic con EGI Check-in.
Ho voluto portare questo caso all’attenzione della comunità, poiché la possibilità di supportare più provider OIDC probabilmente gioverà a più organizzazioni in futuro e renderà le cose più semplici.
L’opzione SAML non era nei nostri radar; potrebbe essere una terza opzione da considerare. Ho trovato il plugin: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
2 Mi Piace