J’ai activé l’authentification unique (SSO) sur le site Discourse de notre entreprise, permettant aux utilisateurs externes de notre application de se connecter. Cependant, certains membres du personnel ayant des adresses e-mail d’entreprise ont besoin d’un accès en tant que modérateurs ou administrateurs. Comme ces membres du personnel ne sont pas enregistrés dans l’application, nous ne pouvons pas créer de comptes SSO pour eux.
Existe-t-il une solution intégrée pour gérer leur connexion séparément, afin qu’ils puissent s’authentifier en utilisant leur e-mail d’entreprise, même avec le SSO activé pour les utilisateurs externes ?
Mais AFAIK cela ne fonctionne que pour les administrateurs, n’est-ce pas ? Je veux me connecter pour le personnel et les modérateurs, c’est-à-dire les utilisateurs avancés mais non administrateurs.
Si je comprends bien, alors vous ne pouvez pas utiliser le SSO. Le premier S signifie “Single” (unique). Je pense que vous devrez utiliser plusieurs connexions OAuth2.
Pourquoi vos administrateurs ne peuvent-ils pas utiliser votre système d’authentification ?
Je n’ai pas de solution, mais il me semble me souvenir que ce problème exact est survenu plusieurs fois par le passé. Il est regrettable que vous ne puissiez pas faire des utilisateurs des modérateurs et leur donner accès au site via la route /u/admin-login.
Au cas où ce serait pertinent, qu’utilisez-vous pour l’authentification unique ? Est-ce DiscourseConnect, OAuth2 ou OpenID Connect ?
Nous souhaitons que nos administrateurs, notre personnel et nos modérateurs utilisent leur e-mail d’entreprise pour se connecter. Cependant, notre mécanisme SSO actuel repose sur l’authentification par OTP (code à usage unique) basé sur le numéro de téléphone, et l’utilisateur doit être enregistré sur notre application avec son adresse e-mail, ce qui n’est pas réalisable pour ces utilisateurs.
Bien que nous puissions implémenter une gestion personnalisée pour mettre sur liste blanche certains e-mails dans notre SSO, nous explorons une solution plus prête à l’emploi. Par exemple, s’il était possible que le SSO coexiste avec la connexion locale, nous pourrions désactiver la connexion locale pour les utilisateurs réguliers tout en permettant aux administrateurs et aux utilisateurs externes de se connecter avec leur e-mail et leur mot de passe. Malheureusement, je ne pense pas que le SSO et la connexion locale puissent coexister de cette manière.
C’est exact. Lorsque DiscourseConnect est activé, les utilisateurs ne peuvent se connecter que via le site du fournisseur d’authentification DiscourseConnect.
J’avais l’idée que la route /u/admin-login fonctionnait pour tout le personnel (administrateurs et modérateurs), mais en y regardant maintenant, je vois qu’elle ne permet qu’aux administrateurs de contourner les connexions DiscourseConnect. Il est possible qu’un plugin puisse être développé pour permettre aux membres d’un groupe personnalisé de se connecter avec la méthode de connexion administrateur, mais il serait probablement préférable de trouver un moyen d’intégrer les utilisateurs externes sur votre site d’authentification SSO.
Cela semble juste. La meilleure solution serait de faire fonctionner votre SSO. Il n’est pas très logique qu’il ne soit pas « réalisable » que votre SSO ne fonctionne pas pour vos employés, mais c’est peut-être pour cela que je travaille à mon compte. (Mais vos employés n’utilisent pas votre application ? S’ils le faisaient, il devrait être assez facile d’ajouter leur adresse e-mail avec l’API).
Mais les gens qui prennent de mauvaises décisions sont ceux qui me font vivre ! Quand je ne convaincs pas les gens d’utiliser les fonctionnalités existantes, ce que j’aime vraiment faire, c’est obliger Discourse à faire des choses pour lesquelles il n’est pas conçu (comme installer Discourse).
Je serais heureux de développer, ou de vous aider à développer, un plugin qui ferait fonctionner la route /u/admin-login (ou une autre) pour les membres de votre groupe d’équipe (qui inclut automatiquement les utilisateurs avec votre e-mail d’entreprise), et de créer une page qu’ils pourraient visiter et où ils entreraient leur e-mail pour obtenir un lien de connexion.
Peut-être qu’il pourrait même rediriger automatiquement les utilisateurs anonymes sur votre VPN vers la page de connexion ou faire autre chose pour que ce soit plus transparent pour vos employés.
(Mais vos employés n’utilisent pas votre application ? S’ils le faisaient, il devrait être assez facile d’ajouter leur adresse e-mail avec l’API).