Sto cercando un plugin SSO che mi permetta di sfruttare le rivendicazioni provenienti dal mio IdP per i miei utenti Discourse.
Nel plugin OIDC sei praticamente bloccato all’endpoint userinfo. Non è male, ma stavo cercando di utilizzare altre informazioni dal nostro identity store e il risultato di userinfo non può essere modificato. Avevo provato a forzare il plugin OIDC a utilizzare id_token_info per fabbricare l’utente, ma senza successo.
Sono tornato al plugin oauth, ma in apparenza ha la stessa restrizione di base, ovvero dipende dalle informazioni dell’utente da un endpoint specifico. Sto lavorando per vedere se riesco a trovarne uno che restituisca il contenuto delle rivendicazioni JWT, ma non è un caso d’uso molto comune, quindi non mi aspetto molto.
Originariamente pensavo che i “callback userinfo paths” sull’oauth basic potessero essere utilizzati per mappare le rivendicazioni all’utente, ma sembro sempre ottenere null nella risposta e l’inserimento fallisce. Posso decodificare il token dall’IdP e vedere le rivendicazioni corrette e in questo caso alla radice del JSON come iss, exp, ecc., ma non riesco a collegarle al lato ActiveRecord.
Sto guardando jwt ma non sembra avere affatto la mappatura delle rivendicazioni all’utente. In pratica, se ottieni un 200 sei a posto, il che non è quello che cercavo neanche.
Qualcuno può indicarmi la direzione di un plugin attualmente mantenuto per mappare le rivendicazioni JWT a un utente o dove potrei sbagliare con uno dei plugin esistenti?
A meno che oggi non sia particolarmente ottuso, copre solo l’autenticazione con attributi fissi. Nessun modo per fare un mapping di claim che ho potuto trovare. Se dovessi fare un fork di qualcosa, probabilmente inizierei da lì, ma volevo assicurarmi di non perdermi qualcosa di ovvio là fuori.
E per aggiungere un po’ di contesto per chi si imbatte in questo argomento.
L’OAuth di base sembra supportare solo l’acquisizione di attributi da un endpoint di dati utente definito e non supporta il mapping delle dichiarazioni JWT. Quindi è simile al plugin OIDC, ma invece della posizione userinfo fornita dal discovery doc è possibile puntare a qualsiasi endpoint JSON e quindi mappare per percorso. Aggiungendo le impostazioni per includere l’autenticazione nell’header è possibile raggiungere luoghi come https://graph.microsoft.com/v1.0/me che utilizziamo per l’OAuth basato su Entra.
Ora Entra ID offre una certa estensibilità per gli oggetti principali, ma non è facile come aggiungere un claim opzionale e sarebbe una modifica globale da quello che vedo. Quindi non sono sicuro che sia un’opzione reale per noi. Facendo un passo indietro nel percorso di maturità e utilizzando semplicemente il plugin JWT sembra l’unica strada, ma richiederebbe del lavoro di PR per aggiungere il supporto al mapping dei claim. In sostanza, nello stesso modo in cui l’oauth2-basic esistente consente di personalizzare il mapping del campo Discourse a un attributo JSON, dovrebbe consentire una maggiore personalizzazione del campo ai claim JWT.
Ora questa è una strada per noi, ma mi sono imbattuto in un problema diverso che penso blocchi tutto.
Dopo aver fatto funzionare oauth2-basic, richiede un nuovo utente e vede che esiste già un utente che utilizza l’email dall’uso del plugin OIDC esistente. Anche se condividono lo stesso attributo email, penso che non possa passare da un provider all’altro per lo stesso utente Discourse. Far ricominciare tutti da capo non è un’opzione reale e, sebbene potrei probabilmente integrare una migrazione di un record di provider oauth in user_associated_accounts da un provider oidc, sembra che stia solo chiedendo guai. Quindi, anche se JWT avesse il supporto al mapping dei claim, tutti gli utenti esistenti sono bloccati al provider OIDC senza qualche manipolazione del database o la creazione di un gestore di “utenti esistenti” per consentire la modifica dell’account associato, sembra che si sia bloccati.
Avevo sperato che si collegassero consentendo \u003e1 record_associato_utente per utente Discourse (per provider_id) o un prompt di "collegamento" per consentire il passaggio da un provider a un nuovo provider. Nei miei test, tuttavia, non è stato così e si limita a notare che l’email è in uso e chiede di creare un nuovo Utente.
Se fossi rimasto sullo stesso plugin, sono sicuro che sarebbe stato semplice, ma in questo caso si tratta di provider_id unici, ciascuno con i propri metadati.