The discussion revolves around whether the sso overrides groups feature works with OAuth2 in Discourse. simon clarifies that this feature only works with Discourse’s implementation of SSO (soon to be renamed DiscourseConnect) and not with OAuth2. mattdm is looking to use this feature with OAuth2 and is disappointed to learn it’s not possible.
mattdm asks if this limitation is intentional, and simon explains that syncing groups via OAuth2 hasn’t been implemented. mattdm shares potential patches for implementing groups with OAuth2 but lacks a staging environment to test them.
Falco offers to review the patches if submitted as PRs. mattdm is looking for help to test the patches. david mentions that they will look into getting it working with the OAuth2 plugin once a related feature is finished.
jontrossbach tests the patches and doesn’t find any issues but needs help to verify the changes work as expected. mattdm is interested in finding a way to test the patches, and abompard offers to add them to a staging OAuth2 instance for testing.
I would like to use this feature. We’re on the Business hosted plan, so SAML is not available to us, so we’re using Oauth2 / OpenID Connect. I believe I have everything configured correctly (sso overrides groups is on, and oauth2 scope is set to openid profile email https://id.fedoraproject.org/scope/groups).
I am a little confused about how Discourse uses the word SSO and what options appear where. However, we’re using sso overrides username and that works. Should I expect this to as well?
Ouch, that’s unfortunate. The rename will definitely help reduce confusion, but doesn’t help my needs. Is this limitation intentional or it just not implemented?
The setting uses a separate code path from what’s used with OAuth2 logins. Syncing groups via OAuth2 hasn’t been implemented. Being able to sync Discourse groups with groups from an external site has a lot of use cases with Discourse, so hopefully it’s something that can be implemented in the future. For now, your only option is to manage group membership via the API.
However since we’re using the hosted plan we don’t have a quick staging environment in which to test them, so they’re completely theoretical. Will try to get such an environment set up sometime soon but it is literally no one’s day job, so if it happens that anyone else could help review and test these that would be amazing.
I deployed the changes linked above and they didn’t seem to break discourse. Is their documentation on how to run your tests so that I can verify the changes didn’t break anything?
Long story short, I don’t know unless I use a mock system on the Fedora Accounts System (FAS) – or some other OIDC system – to try it but I would also be interested in learning how to use the smoke test from discourse that seems to run on a headless chrome browser but I’m struggling to find anything on that.
Does someone from Discourse know where I might be able to find how to run a smoke test?
Could someone from Fedora give a mock FAS system to test against?
Hmmm. The Fedora Account System is … kind of big. (But (as of major upgrade this year) it’s FreeIPA under the hood, so theoretically anyone could create something like it.)
Maybe we could connect your test Discourse to the actual Fedora Account System?
However since we’re using the hosted plan we don’t have a quick staging environment in which to test them, so they’re completely theoretical. Will try to get such an environment set up sometime soon but it is literally no one’s day job, so if it happens that anyone else could help review and test these that would be amazing.