OpenID Connect Authentication Plugin

No, I haven’t, so I don’t know what to do.

Late to the party, sorry. I am having the same issue as @Joost_Naaijen here - auth opens in popup and after logging in to oidc server redirect happens in the popup. You can ofc then close either the popup or the parent window and both are logged in, but this is quite ugly.
I am on a new install, using bitnami docker images, latest versions, the only additional plugin is oidc. It could be the bitnami images, though a patch like that does not really make sense.
Went through the call stack and it is insane… I found a point where full_screen_login param is lost but I need more time to understand how everything works because it feels like the code there is generated… wrongly.

What do you mean by “latest”, what version specifically?

Version in CP is [v2.3.9-dirty], not sure what dirty stands for. And I am offered 2.4.0.beta10 as newest. There is a link below with the link to the diff and the commit id is of 2.3.9 tag.
Managed to find the code finally, dummy me. Seems things are much changed for 2.4 and that part is different. Could it be this has been changed/fixed for 2.4? I don’t see any 2.4 images so I will just wait for 2.4 I guess.
p.s. how would I force full_screen_login until 2.4 arrives for me?

Hi ! Thank you for the plugin.

Is it possible to prevent username changes, on signup, when using this plugin?

We have a pretty consistent user naming scheme, and would like to prevent people to change their username when signing-up through OID.

I know it would be possible to just “hide” the field, but that looks hackish (and easily bypassable by someone with enough knowledge).

It would be something like the " sso overrides username " option (for the discourse SSO), but this time for OIDC.

Thanks,

Rémy

2 Likes

Hi,

I’m facing a problem with redirect_uri.

My setup:

  • Discourse is running on docker, following the setup guide (version: 2.5.0.beta2)
  • Web access via separate nginx reverse proxy (according to Running other websites on the same machine as Discourse)
  • OpenId-Connect-provider is Keycloak, working well with other projects.
  • force_https is set active

So far: Discourse up and running :+1:, HTTPS works well.
BUT: When trying to login via OpenId, the redirect_uri in the link is only http, which leads Keycloak to throw error: “Invalid parameter: redirect_uri” - because this must be with https.

Thanks for hints on getting this solved
der-peer

Make sure you enable the force_https setting in your admin panel

1 Like

I ensured that, before writing my question :slight_smile: … as stated above.

Ah, sorry I missed that in your previous post. In that case, it sounds like your reverse proxy is not passing through the protocol correctly. Do you have

        proxy_set_header X-Forwarded-Proto https;

in your nginx config?

4 Likes

Yay! Thanks for pushing me into the right direction :grinning:. It was “nearly” correct, but:
proxy_set_header X-Forwarded_Proto https;
still is wrong. Now it works as expected. :+1:

Thanks for your quick help!

3 Likes

@der-peer I’m trying with Keycloak but I get (oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, missing discovery parameter authorization_endpoint

I’m confused about Keycloak configuration since the vocabulary and settings seem to be different from what’s available in the topic so far. Would you mind sharing an example configuration on the Keycloak side for the client?

Keycloak settings (very basic, working, but still work in progress):
Menu Clients, Clients Lookup, hit Create:

  • Client ID: myfancyforum
  • Client Protocol: openid-connect

Hit Save. Again in Clients Lookup, hit Edit on your new Client:

  • Access Type: confidential
  • Valid Redirect URIs: https://myfancyforum.example.com/*
  • Base URL: https://myfancyforum.example.com

Hit Save. Now Top Menu shows “Credentials”, copy Secret.
Done here.

Discourse settings:
Menu Settings, Plug-ins:

  • openid connect enabled: yes
  • openid connect discovery document: https://mykeycloak.example.com/auth/realms/{realmname}/.well-known/openid-configuration
  • openid connect client id: myfancyforum
  • openid connect client secret: paste Secret from above
  • openid connect authorize scope: openid

That’s it. Most difficult part is the URL to the openid config. In scope you can add profile and/or email (separated by spaces) - I don’t know (yet), how to do that, but there should be the possibility to fetch additional information from keycloak, e.g. picture or role assignments with these scopes.

2 Likes

Ha, I was missing the confidential and credentials part, thank you!

I use a proxy in Nginx since the canonical way of using Well-Known URLs is at the domain’s root:

        location = /.well-known/openid-configuration {
                proxy_pass http://keycloak/auth/realms/{realmname};
                include proxy_params;
        }

Now you can access https://example.com/.well-known/openid-authentication

I think it’s in User attributes.

I´m looking for the same, do you have any news about this?

No, no news. What I use in the mean time is this in the Dockerfile:

hooks:
  after_code:
    - exec:
        cd: $home/app
        cmd:
          - sed -i "s/input value=accountUsername/input value=accountUsername disabled=true/" assets/javascripts/discourse/templates/modal/create-account.hbs

That’s a hack, and I’m not liking it, but it works… mainly ( I guess someone smart would be able to just edit the form in the browser, with something like tamperdata ).

I managed to have the SAML setup working, while the OpenID-Connect setup still gives me the error I mentioned earlier. I need to investigate more. Will post about the proper SAML setup soon, which might need some more experiment to make it better.

@rgrunbla what OIDC provider are you using? It looks like you would rather do a mapping from accountUsername to username instead of skipping it. But your solution is very smart. Nice hack.

I’m using keycloak. But I’m not sure what you are saying: the connection between keycloak and discourse works as expected, I just want the username to be readonly.

1 Like

Hi,

With this plugin, is it possible for a user to link an external OpenID Connect account with its existing account, internal to Discourse?

Thank you

Yes it is, just enable the openid_connect_allow_association_change setting

1 Like

Yes, I’ve seen this config flag, but I didn’t realized it was incompatible with 2FA.
That’s why I was not able to link my account :wink:
That could be explained in the config setting.
Example:

openid_connect_allow_association_change : Allow users to disconnect and reconnect their Discourse accounts from the OpenID Connect provider (:warning: incompatible with 2FA)