Bonjour 
, j’ai écrit ce module d’authentification SimpleSAMLphp afin de pouvoir utiliser Discourse comme fournisseur SSO au sein d’une installation SimpleSAMLphp. Autrement dit, vous pouvez utiliser Discourse comme fournisseur SSO pour tous les services prenant en charge l’authentification SAML ou Shibboleth, ce qui est vraiment pratique.
Dites-moi ce que vous en pensez (si vous souhaitez commenter le code, vous pouvez utiliser les Issues GitHub).
C’est super ! Si vous souhaitez rendre le module plus visible, vous pouvez créer un sujet à ce sujet dans notre catégorie #plugin:extras. Cette catégorie est un répertoire de toutes les extensions et intégrations pour Discourse qui ne sont pas des plugins Discourse,
EDIT : Image de maquette ajoutée
Je mets en œuvre ce SSO sur un site web existant et je souhaite simplement vérifier comment les gens « présentent » leur méthode de connexion aux utilisateurs.
Par exemple, supposons que mon site web www.example.com dispose d’un bouton Connexion dans la navigation supérieure.
Ce bouton de connexion doit-il emmener immédiatement les utilisateurs vers ma page d’authentification Discourse ? Ou est-il préférable d’afficher d’abord une page ou une fenêtre modale d’informations, quelque chose comme :
Je me demande simplement si les utilisateurs seront confus s’ils ne sont pas informés de ce qui va se passer ? 
Quelqu’un a-t-il des retours d’expérience ou des bonnes pratiques à partager ?
Et merci d’ailleurs à @techAPJ pour le premier message très détaillé dans ce fil, j’ai pu intégrer cela avec succès à mon site web ASP.NET à partir de zéro en suivant vos étapes 
Est-il possible d’inclure un paramètre d’état qui est renvoyé tel quel, comme c’est le cas dans OAuth ? Le middleware d’authentification d’ASP.NET Core dépend de la génération d’un identifiant de corrélation pour prévenir les attaques CSRF, et je n’ai actuellement pas de moyen simple de l’inclure.
Ne pourriez-vous pas en ajouter un à la chaîne de requête de votre URL de rappel avant de l’encapsuler ?
Par exemple :
nonce=NONCE&return_sso_url=https://www.example.com/my/callback_url.aspx?myparam=here
@jessicah J’ai essayé cela aujourd’hui et oui, cela fonctionne parfaitement.
' Créer une URL de retour
Dim strReturnURL As String = "https://www.example.com/authtestRETURNURL.aspx?myownparametershere=surewhynot"
' Générer un nonce aléatoire. Sauvegardez-le temporairement afin de pouvoir le vérifier avec la valeur de nonce renvoyée
Dim strNonce As String = Guid.NewGuid().ToString("N")
' Créer une nouvelle charge utile avec le nonce et l'URL de retour (vers laquelle Discourse redirigera l'utilisateur après vérification)
' La charge utile doit ressembler à : nonce=NONCE&return_sso_url=RETURN_URL
Dim strPayload As String = "nonce=" & strNonce & "&return_sso_url=" & strReturnURL
Ensuite, sur la page qui est rappelée, vous trouverez ceci dans votre chaîne de requête SSO décodée :
&return_sso_url=http%3A%2F%2Fwww.example.com%2FauthtestRETURNURL.aspx%3Fmyownparametershere%3Dsurewhynot&username=RichJ’espère que c’est bien ce que vous vouliez dire ?
Approches multi-sites pour l’utilisation de discourse-auth-proxy ?
Y a-t-il des exemples ou des recommandations pour utiliser Discourse comme fournisseur SSO pour une authentification multi-sites ?
Il semble qu’il existe deux approches multi-sites de base :
Je pense que l’une ou l’autre de ces approches pourrait fonctionner, mais le problème avec ces deux méthodes est que vous devez toujours vous connecter à chaque site différent.
Il existe également le risque que quelque chose soit stocké dans Postgres et soit écrasé par chaque connexion provenant des différents sites. Par exemple : site1.com, site2.com
(Je ne connais pas les détails du schéma d’authentification Discourse/PG, donc je ne sais pas).
L’idéal serait de pouvoir effectuer une seule connexion, ce qui vous permettrait d’être connecté à tous les sites du groupe multi-sites. Par exemple : site1.com, site2.com, site3.com
Apparemment, Stackoverflow fait cela en combinant le stockage localSession et les Iframes comme principal mécanisme d’activation. description technique
Mais j’aimerais vraiment savoir si quelqu’un a mis en œuvre une approche de connexion multi-sites en utilisant Discourse comme fournisseur SSO.
approche 1 : plusieurs instances de discourse-auth-proxy
approche 2 : discourse-auth-proxy modifié affectant return_sso_url dans la charge utile.
approche 3 : #1 ou #2 mis en œuvre de telle sorte qu’une seule connexion signifie que vous n’avez pas besoin de vous connecter à nouveau en passant de site1.com à site2.com
Je vous taggue @sam, puisque vous êtes l’auteur original du programme Go discourse-auth-proxy.
Bonjour,
Je suis bloqué sur la façon dont le fournisseur gère le signe + dans l’URL de retour SSO.
Dans mon cas, mon consommateur DiscourseConnect crée un return_sso_url comme suit :
http://example.com/foo/bar?wpLoginToken=123+\http%3A%2F%2Fexample.com%2Ffoo%2Fbar%3FwpLoginToken%3D123%2B%5CEnsuite, DiscourseConnect retourne vers :
http://example.com/foo/bar?wpLoginToken=123%20\&sso=foo&sig=barhttp://example.com/foo/bar?wpLoginToken=123+\&sso=foo&sig=barLe problème est que l’URL de retour est traitée par la fonction urldecode en PHP (c’est le flux de travail principal de l’authentification MediaWiki), et la valeur de wpLoginToken change de manière inattendue de 123+\ à 123 \.
Il semble que j’aie trouvé la cause :
https://www.php.net/manual/en/function.urlencode.php
En effet, le client et le serveur implémentent l’encodage/décodage mais suivent des spécifications différentes.
Je ne demande pas à Discourse de modifier son comportement, mais je cherche des conseils pour résoudre ce problème.
Merci.
Édition :
J’ai résolu le problème en codant deux fois le signe + en URL.
Merci !
Je suis en train de l’essayer en ce moment. Je t’ai envoyé deux PR sur GitHub : l’une pour mettre à jour la documentation et l’autre pour corriger un bug que j’ai rencontré.
Dans Paramètres > Connexion, les deux paramètres fournisseur de DiscourseConnect ne sont pas consécutifs et apparaissent mélangés aux autres paramètres de DiscourseConnect :
Étant donné que les paramètres liés au fournisseur et ceux qui ne le sont pas concernent des cas d’utilisation opposés — utiliser Discourse pour gérer des utilisateurs pour une autre application versus utiliser une autre application pour gérer des utilisateurs pour Discourse — le fait d’afficher ces paramètres mélangés invite à une mauvaise configuration. Il serait moins confus si les deux paramètres de fournisseur étaient consécutifs et soit entièrement avant, soit entièrement après les paramètres non liés au fournisseur.
@techAPJ Peut-on l’utiliser avec AWS Cognito ? Je souhaite créer une application dans AWS Amplify pour ma communauté Discourse et que mon application soit authentifiée via Discourse.
Désolé pour cette réponse très tardive. Vous avez tout à fait raison : il est déroutant qu’ils soient entremêlés de la sorte. Je les ai réorganisés dans cette PR :
@mdoggydog Merci pour la récente mise à jour de l’extension MediaWiki DiscourseSsoConsumer. Nous nous demandions quoi faire concernant les utilisateurs qui étaient déconnectés de notre wiki sans s’être déconnectés de Discourse, et $wgPluggableAuth_EnableAutoLogin n’était certainement pas ce que nous voulions, car cela empêche l’accès anonyme au wiki. Le paramètre $wgDiscourseSsoConsumer_AutoRelogin que vous avez ajouté est exactement ce dont nous avions besoin.
Bonjour 
!
J’essaie d’utiliser l’exemple PHP du post original, mais la façon dont ils stockent les choses n’a pas de sens. Ils stockent simplement des valeurs dans une base de données SQL avec les clés login et nonce. Si je veux utiliser SQL pour stocker les nonces, à quoi ressemblerait exactement ma base de données SQL ?
Quelques autres informations qui pourraient aider sont à quoi je destine ceci : j’espère lier un utilisateur Discourse à un compte Minecraft en générant un lien SSO lié à leur UUID. Après une connexion réussie avec Discourse, je vais stocker leur UUID et leur ID Discourse dans une table.
Jusqu’à présent, j’ai réussi à faire fonctionner l’exemple PHP, mais je ne comprends pas bien comment je devrais le modifier pour qu’il fonctionne pour mon cas d’utilisation. Idéalement, je veux générer le lien via une requête GET et l’envoyer à l’utilisateur, de sorte que l’UUID soit déjà associé au nonce.
Merci pour ce post, car je serais encore plus perdu sans lui !
Edit : Pour les nonces, ne serait-il pas préférable de stocker les nonces dans la table et de rechercher par celle-ci ? Je sais que je dois faire correspondre le nonce, mais à moins de pouvoir passer des informations supplémentaires dans l’URL de redirection (ce que je n’ai pas réussi à faire), je ne suis pas sûr de la façon de référencer correctement le nonce.
J’ai créé un guide qui permet à l’administrateur de configurer DiscourseConnect en protocole SAML standard via SimpleSAMLphp.
/session/sso_provider?sso=bm9uY2U9NDA3YTVlNjg1ZTEwMDlh...
Je ne suis pas sûr de la raison pour laquelle cela donne une erreur 502 Bad Gateway.
J’ai supprimé une partie de la valeur du paramètre sso que vous aviez fournie. À moins que quelqu’un ne connaisse votre clé secrète, il ne serait pas en mesure de décoder la valeur, mais il semblait tout de même plus sûr de ne pas fournir la valeur complète. Cela n’aura aucun rapport avec l’erreur 502 que vous rencontrez.
Il semble s’agir d’une erreur de base de données. En effet, j’ai essayé le même plugin et la même configuration sur un autre site web Discourse, et cela fonctionne. Comment puis-je résoudre ce problème ?
Il semble que tenter de s’authentifier dans discourse-auth-proxy avec des noms d’utilisateur ou des noms de groupe non-ASCII (chinois dans mon cas) entraîne une erreur car les cookies ne peuvent pas contenir ces caractères. Voici ma correction : (avertissement : je ne suis pas vraiment familier avec 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: "/",
Merci de votre signalement ! Pourriez-vous créer une Pull Request (PR) sur le dépôt GitHub afin que nous puissions intégrer ce changement dans la version officielle ?