Konten automatisch mit externem SSO-Anbieter bereitstellen? (Aufforderung "Neues Konto erstellen" überspringen)

I’ve just setup a Discourse instance and added the discourse-openid-connect to it, connecting Keycloak as the OIDC provider.

After following the 3 conditions stated here with a recent update, I get the behaviour to authenticate via Keycloak, or if already logged in, clicking the “Login” button will prompt me to “Create New Account” with the fields filled in sourced from Keycloak info on the user.

Is there a way to skip this part requiring an additional step from the user? These are fields are naturally already populated from Keycloak, so there shouldn’t be a need for the user to modify them specifically for Discourse.

The account creation should be handled implicitly, similar to how Grafana is able to do it? I am aiming for each service provided by the community to support this seamless experience, that the original community account that is signed-up is all they have to deal with.

This might not make sense if you’re thinking about external auth such as Google / Facebook / Github / etc. A user can register their community account via Keycloak with one of those, but Keycloak itself which is only used internally is what is intended to work with all the individual services, so implicit/automated consent and sign-up is desirable.

New to discourse, i’ve got my SSO OAUTH2 provider setup and working. New users are seeing the prompt the first time they arrive and authenticate to discourse. How can I streamline this process and have the user automatically created. The values populated in that screen are correct, and a one time thing. What can I do to eliminate that screen and streamline the account creation process for my community users?

This is not currently possible. When users first create an account, they will need to click the “Create New Account” button on the signup form.

The behaviour that you are looking for is similar to how Discourse’s implementation of SSO works. In that case, accounts are created in the background without the user filling in the signup form. It seems it should be possible to implement similar functionality for OAuth2 logins, but possibly there are cases where not enough information is passed from the OAuth2 provider to create an account.

I haven’t put much time into this since my post here, but I did end up getting Discourse SSO feature instead to use a bridging service I came across for OpenID-Connect, it was a python service that had a docker container, that made deploying with my docker-compose setup easier.

So Keycloak provided the account already registered and signed-in, visiting Discourse would then sign-up the user with details provided from the bridge iirc. It’s been a while since I dealt with it, but this was a slightly better process than Discourse OAuth/OpenID-Connect support afaik(at least at the time, haven’t checked if anything has been done to improve it).

Either way, you don’t get account details sync’d as expected. The user needs to sign out of Discourse and back in for any sync to occur, and even then I think there were some things that could not be sync’d from the SSO provider to Discourse(groups/roles, something like that iirc had some gotchas).

You would need to detect the user details being updated from the provider to trigger updating Discourse via it’s APIs I think to get a proper sync setup. Otherwise you can have duplicated details that aren’t in sync, or confusing sync to the users.


So uhh, if the OAuth2 SSO integration you currently have is not the Discourse SSO feature that generally requires an SSO bridge afaik, but that plugin alternative, changing to the non-plugin version with an SSO bridge should get that desired experience you want iirc…

Ich bin auch daran interessiert, das Fenster „Neues Konto erstellen

Ich habe einige neue Seiteneinstellungen hinzugefügt, die dabei helfen werden. Um den Bildschirm ‘Neues Konto erstellen’ zu überspringen, aktivieren Sie sso_overrides_username, sso_overrides_email und sso_overrides_name.

Um das Popup vollständig zu überspringen, aktivieren Sie external_auth_skip_create_confirm.

Wenn Sie diese Option nicht sehen, stellen Sie sicher, dass Sie die neueste Version von tests-passed verwenden.

external_auth_skip_create_confirm ist aktiviert

Wir haben ein Problem:

  1. In unserem Discourse existiert bereits das Konto test__EMAIL__.
  2. Wenn ich mich mit OpenID und dem Benutzernamen test sowie der E-Mail-Adresse test__EMAIL__ anmelde, erscheint ein Fenster für ein neues Konto, das mich auffordert, einen neuen Benutzernamen (test1) und die E-Mail-Adresse test__EMAIL__ anzugeben.

Es gibt keine Möglichkeit, das alte Konto mit OpenID zu verknüpfen.

Verifiziert Ihr OpenID Connect-Anbieter die E-Mail-Adressen der Benutzer? Wir können die E-Mail aus OIDC nur dann ‘vertrauen’, wenn sie verifiziert wurde und das boolesche Feld ‘verified’ korrekt gesetzt ist.

Kein OID-Anbieter – Keycloak mit LDAP-Benutzer-Föderation
Wir haben die Lösung gefunden: Alte Benutzer können OpenID über die Benutzereinstellungen-Oberfläche verbinden.

@david wir haben 2.5.2 stable – diese Option fehlt…… Kann diese Option in den stable-Zweig übernommen werden? Wir brauchen sie, aber wir verwenden in der Produktion nichts anderes als den stable-Zweig…

Das ist leider nicht möglich, wir portieren keine neuen Funktionen auf den stabilen Zweig zurück. Behalte #releases im Auge, um zu erfahren, wann die nächste stabile Version veröffentlicht wird.

@david
Es ist nicht ganz klar, worum es bei der nächsten stabilen Version geht… Minor-Version 2.5.3? Oder Version 2.6.0?

Die nächste Hauptversion wird 2.6.0 sein. Minor-Versionen (2.5.x) werden nur für Sicherheitsupdates veröffentlicht.

@david
Danke! Jetzt ist es klar. Wird 2.6.0 dieses Jahr veröffentlicht oder nicht? )))

Wir haben noch kein bestätigtes Datum, aber ja, es besteht eine gute Chance, dass es noch in diesem Jahr sein wird :slight_smile: