Ciao 
, ho scritto questo modulo di autenticazione SimpleSAMLphp per poter utilizzare Discourse come provider SSO all’interno di un’installazione SimpleSAMLphp. Cioè, puoi usare Discourse come provider SSO per qualsiasi servizio che supporti l’autenticazione SAML o Shibboleth, il che è davvero utile.
Fammi sapere cosa ne pensi (se sei interessato a commentare il codice, puoi usare le Issue di Github).
È fantastico! Se desideri rendere il modulo più visibile, potresti creare un argomento al riguardo nella nostra categoria #plugin:extras. Questa categoria è un elenco di tutte le estensioni e integrazioni per Discourse che non sono plugin di Discourse,
AGGIORNAMENTO: Aggiunta immagine di mockup
Sto implementando questo SSO su un sito web esistente e vorrei solo verificare come le persone “presentano” il proprio metodo di accesso agli utenti.
Ad esempio, supponiamo che il mio sito web www.example.com abbia un pulsante Accedi nella barra di navigazione in alto.
Quel pulsante di accesso dovrebbe portare immediatamente gli utenti alla mia pagina di autenticazione Discourse? O è preferibile mostrare prima una pagina o un modale con informazioni, qualcosa del genere:
Mi chiedo solo se gli utenti potrebbero confondersi se non viene loro detto cosa sta per accadere? 
Qualcuno ha esperienze utente o migliori pratiche da condividere?
Grazie anche a @techAPJ per il primo post molto dettagliato in questa discussione; sono riuscito a integrare con successo questa funzionalità nel mio sito web ASP.NET da zero seguendo i tuoi passaggi 
È possibile includere un parametro di stato che venga restituito invariato, come avviene in OAuth? Il middleware di autenticazione di ASP.NET Core si basa sulla generazione di un ID di correlazione per prevenire attacchi CSRF, e al momento non ho un modo semplice per includerlo.
Non potresti aggiungerlo alla stringa di query del tuo URL di callback prima di incapsularlo?
Ad esempio:
nonce=NONCE&return_sso_url=https://www.example.com/my/callback_url.aspx?myparam=here
@jessicah Ci ho provato oggi e sì, funziona perfettamente.
' Crea un URL di ritorno
Dim strReturnURL As String = "https://www.example.com/authtestRETURNURL.aspx?myownparametershere=surewhynot"
' Genera un nonce casuale. Salvalo temporaneamente in modo da poterlo verificare con il valore del nonce restituito
Dim strNonce As String = Guid.NewGuid().ToString("N")
' Crea un nuovo payload con nonce e URL di ritorno (dove Discourse reindirizzerà l'utente dopo la verifica)
' Il payload dovrebbe essere del tipo: nonce=NONCE&return_sso_url=RETURN_URL
Dim strPayload As String = "nonce=" & strNonce & "&return_sso_url=" & strReturnURL
Poi, nella pagina che viene richiamata, troverai questo all’interno della stringa di query SSO decodificata:
&return_sso_url=http%3A%2F%2Fwww.example.com%2FauthtestRETURNURL.aspx%3Fmyownparametershere%3Dsurewhynot&username=RichSpero che sia questo che intendevi?
Approcci multi-sito per l’utilizzo di discourse-auth-proxy?
Esistono esempi o raccomandazioni per utilizzare Discourse come provider SSO per l’autenticazione multi-sito?
Sembra che ci siano due approcci di base per il multi-sito:
Penso che entrambi possano funzionare, ma il problema con questi due approcci è che è comunque necessario accedere a ciascun sito diverso.
Esiste inoltre il rischio che qualcosa venga memorizzato in Postgres e sovrascritto da ogni accesso proveniente dai diversi siti, ad esempio: site1.com, site2.com
(Non conosco i dettagli dello schema di autenticazione di Discourse/PG, quindi non lo so)
L’ideale sarebbe avere un metodo che permetta di eseguire l’accesso una sola volta, ottenendo così l’accesso a tutti i siti del gruppo multi-sito, ad esempio: site1.com, site2.com, site3.com
A quanto pare, Stackoverflow lo fa utilizzando una combinazione di storage locale Session e Iframe come principali abilitatori. descrizione tecnica
Ma mi piacerebbe davvero sapere se qualcuno ha implementato un approccio per l’accesso multi-sito utilizzando Discourse come provider SSO.
approccio 1: più istanze di discourse-auth-proxy
approccio 2: discourse-auth-proxy modificato che influisce su return_sso_url nel payload.
approccio 3: #1 o #2 implementati in modo tale che, accedendo una sola volta, non sia necessario accedere nuovamente passando da site1.com a site2.com
Ti taggo @sam, dato che hai originariamente scritto il programma Go discourse-auth-proxy.
Ciao.
Sono bloccato su come il provider gestisce il segno + nell’URL di ritorno SSO.
Nel mio caso, il mio consumer DiscourseConnect creerà un return_sso_url come:
http://example.com/foo/bar?wpLoginToken=123+\http%3A%2F%2Fexample.com%2Ffoo%2Fbar%3FwpLoginToken%3D123%2B%5CPoi DiscourseConnect restituirà a:
http://example.com/foo/bar?wpLoginToken=123%20\&sso=foo&sig=barhttp://example.com/foo/bar?wpLoginToken=123+\&sso=foo&sig=barIl problema è che l’URL di ritorno verrà gestito dalla funzione urldecode in PHP (è il flusso di lavoro principale nell’autenticazione MediaWiki), e il valore di wpLoginToken cambierà in modo imprevisto da 123+\ a 123 \.
Sembra che abbia trovato la causa:
Bene, il client e il server implementano codifica/decodifica ma seguono specifiche diverse.
Non sto chiedendo a Discourse di cambiare, ma cerco consigli su come risolvere il problema.
Grazie.
Modifica:
Ho risolto codificando in URL il segno + due volte.
Grazie!
Sto provando in questo momento. Ti ho inviato due PR su GitHub: una per aggiornare la documentazione e una per correggere un bug che ho riscontrato.
In Impostazioni > Accesso, le due impostazioni provider di DiscourseConnect non sono consecutive e appaiono intercalate con le impostazioni di DiscourseConnect:
Poiché le impostazioni relative al provider e quelle non relative al provider riguardano casi d’uso opposti: utilizzare Discourse per gestire utenti per qualcos’altro rispetto a utilizzare qualcos’altro per gestire utenti per Discourse, mostrare queste impostazioni mescolate insieme favorisce configurazioni errate. Sarebbe meno confuso se le due impostazioni del provider fossero consecutive e completamente prima o completamente dopo le impostazioni non relative al provider.
@techAPJ Questo può essere utilizzato con AWS Cognito? Voglio creare un’app in AWS Amplify per la mia community Discourse e desidero che la mia app sia autenticata tramite Discourse.
Scusa per la risposta così tardiva. Hai assolutamente ragione: è confuso che siano disposte in quel modo. Le ho sistemate in questa PR:
@mdoggydog Grazie per il recente aggiornamento dell’estensione MediaWiki DiscourseSsoConsumer. Stavamo pensando a cosa fare riguardo agli utenti che venivano disconnessi dal nostro wiki senza essersi disconnessi da Discourse, e $wgPluggableAuth_EnableAutoLogin non era decisamente ciò che volevamo, poiché impedisce l’accesso anonimo al wiki. L’impostazione $wgDiscourseSsoConsumer_AutoRelogin che hai aggiunto è esattamente ciò di cui avevamo bisogno.
Ciao 
!
Sto cercando di usare l’esempio PHP del post originale, ma il modo in cui memorizzano le cose non ha senso. Stanno solo memorizzando valori in un database SQL con le chiavi login e nonce. Se voglio usare SQL per memorizzare i nonce, come dovrebbe essere esattamente il mio database SQL?
Altre informazioni che potrebbero aiutare sono per cosa lo sto usando: spero di collegare un utente Discourse a un account Minecraft generando un link SSO associato al loro UUID. Dopo aver effettuato correttamente l’accesso con Discourse, memorizzerò il loro UUID e l’ID Discourse in una tabella.
Finora, sono riuscito a far funzionare l’esempio PHP, ma immagino di non capire appieno come dovrei modificarlo per funzionare per il mio caso d’uso. Idealmente, voglio generare il link tramite una richiesta GET e inviarlo all’utente, in modo che l’UUID sia già associato al nonce.
Grazie per questo post, altrimenti sarei ancora più perso!
Modifica: Per i nonce, sarebbe meglio memorizzare i nonce nella tabella ed effettuare ricerche tramite essi? So che devo associare il nonce, ma, a meno che non possa passare ulteriori informazioni nell’URL di reindirizzamento (cosa che non sono riuscito a fare), non sono sicuro di come fare riferimento correttamente al nonce.
Ho creato una guida che consente all’amministratore di configurare DiscourseConnect nel protocollo SAML standard tramite SimpleSAMLphp.
/session/sso_provider?sso=bm9uY2U9NDA3YTVlNjg1ZTEwMDlh...
Non sono sicuro del motivo per cui si verifica un 502 bad gateway.
Ho modificato parte del valore del parametro sso che avevi fornito. A meno che qualcuno non conoscesse la tua chiave segreta, non sarebbe stato in grado di decodificare il valore, ma mi è sembrato comunque più sicuro non fornire il valore completo. Non sarà correlato all’errore 502 che stai riscontrando.
Sembra un errore del database. Perché provo lo stesso plugin e la stessa configurazione su un altro sito web Discourse e funziona. Come posso risolvere questo problema?
Sembra che il tentativo di autenticarsi in discourse-auth-proxy con nomi utente o nomi di gruppo non ASCII (cinese nel mio caso) porti a un errore perché i cookie non possono contenere questi caratteri. Questa è la mia correzione: (disclaimer: non ho molta familiarità con golang)
diff --git a/main.go b/main.go
index 1b1dc28..18f8c9e 100644
--- a/main.go
+++ b/main.go
@@ -154,7 +154,12 @@ func redirectIfNoCookie(handler http.Handler, r *http.Request, w http.ResponseWr
var username, groups string
if err == nil && cookie != nil {
- username, groups, err = parseCookie(cookie.Value, config.CookieSecret)
+ var value string
+ value, err = url.QueryUnescape(cookie.Value)
+ if err != nil {
+ return
+ }
+ username, groups, err = parseCookie(value, config.CookieSecret)
}
if err == nil {
@@ -224,7 +229,7 @@ func redirectIfNoCookie(handler http.Handler, r *http.Request, w http.ResponseWr
cookieData := strings.Join([]string{username, strings.Join(groups, "|")}, ",")
http.SetCookie(w, &http.Cookie{
Name: cookieName,
- Value: signCookie(cookieData, config.CookieSecret),
+ Value: url.QueryEscape(signCookie(cookieData, config.CookieSecret)),
Expires: expiration,
HttpOnly: true,
Path: "/",
Grazie per la segnalazione! Ti dispiacerebbe creare una PR (Pull Request) contro il repository GitHub in modo che possiamo unire questa modifica alla versione ufficiale?