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.