SSO provider implementation - Admin, moderator and groups ignored?

Support
1

I have a problem very similar to Avatars not pulling from SSO. While users can login with my SSO provider (consideratio/discourse-sso-oidc-bridge), and discourse show up information in logs about it, the provided information about the signed in user being admin or not etc is ignored.

In other words, my SSO provider returns admin: true for example, but it does not affect the user that remains non-admin.

image
image1013×53 12.3 KB

Ideas on what can be wrong or how to debug this further? I’m using v2.3.0.beta5 +169.

3

Suspicion 1

Discourse manages to say “User was logged on” and list “admin: true”. Am I correct to assume that when this happens, the user is meant to become an admin if the user wasn’t already? Or, does it require additional steps?

I saw the following from Official Single-Sign-On for Discourse (sso), but I’m thinking this is mostly if you want to sync without having a user login at all, but you can also sync while the user is logging in. Or? Hmmm…

image
image713×145 17.1 KB

4

Suspicion 2

When I inspected the logs further, I found that params listed does not contain the full sso param, but only a truncated part. What is going on here? The only information within the sso params that is truncated is nonce=01bcdfd0a32b809567991b3dbd59fe9f&return_sso_url=https%3A%2F%2Fdiscour, but discourse has parsed more information at some point so I assume this is a artifact of the logger.

### Env

hostname <redacted>
process_id 17301
application_version da187f096734f8cf1716cbc89a8a6dd7b48cea41
HTTP_HOST <redacted>
REQUEST_URI /session/sso_login?sso=bm9uY2U9MDFiY2RmZDBhMzJiODA5NTY3OTkxYjNkYmQ1OWZlOWYmcmV0dXJuX3Nzb191cmw9aHR0cHMlM0ElMkYlMkZkaXNjb3Vyc2UuZHNwLnNhbmR2aWsuY29tJTJGc2Vzc2lvbiUyRnNzb19sb2dpbiZhZG1pbj10cnVlJm1vZGVyYXRvcj10cnVlJmVtYWlsPWVyaWsuc3VuZGVsbCU0MHNhbmR2aWsuY29tJmxvY2FsZT1lbi1VUyZuYW1lPUVyaWslMjBTdW5kZWxsJnVzZXJuYW1lPWVyaWsuc3VuZGVsbCU0MHNhbmR2aWsuY29tJmV4dGVybmFsX2lkPTAwdTdzeG5nbXh0bkVmalE4MzU2&amp;sig=069549ea561b3e68e583866a05d5d84a2df291c7219295fe4236c4c467b449d5
REQUEST_METHOD GET
HTTP_USER_AGENT Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
HTTP_ACCEPT text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
HTTP_X_FORWARDED_FOR <redacted>, <redacted>
HTTP_X_REAL_IP <redacted>
params:
  sso bm9uY2U9MDFiY2RmZDBhMzJiODA5NTY3OTkxYjNkYmQ1OWZlOWYmcmV0dXJuX3Nzb191cmw9aHR0cHMlM0ElMkYlMkZkaXNjb3Vyc
  sig 069549ea561b3e68e583866a05d5d84a2df291c7219295fe4236c4c467b449d5
5

Code inspection

I tried to figure something out, but I failed…

Starting point - Discourse gets user information from my SSO provider

I found my way here by spotting the “User was logged on” text from /logs in Discourse.

https://github.com/discourse/discourse/blob/fdf4145d4b09fa1dab651c554d201f05f1f87fb8/app/controllers/session_controller.rb#L109

In the sso_login, a DiscourseSingleSignOn instance named sso is created

https://github.com/discourse/discourse/blob/fdf4145d4b09fa1dab651c554d201f05f1f87fb8/app/controllers/session_controller.rb#L116

sso.lookup_or_create_user is called

https://github.com/discourse/discourse/blob/f8be43644b72bd36dd499c4c477cd440ceb0249f/app/models/discourse_single_sign_on.rb#L49

The admin stuff is set

https://github.com/discourse/discourse/blob/f8be43644b72bd36dd499c4c477cd440ceb0249f/app/models/discourse_single_sign_on.rb#L78-L85

6

Yes, setting the SSO parameter admin to true should be all that’s required to log a user in as an admin. When I test this on my own site it works for me. From the screenshot in your initial post, it looks like the parameter is set correctly. Are you still having trouble getting this to work?

7

Ah thanks for confirming that @simon! Yepp the issue persist and I have failed to find another clue on what may be wrong. =/

8

Is this for a forum that we are hosting, or is it a self-hosted site?

9

This forum is a self hosted site, using a SSO provider I’ve written myself based on previous work of others (github.com/consideratio/discourse-sso-oidc-bridge).

10

Enable verbose SSO logs, logout, log in with a user that sends the admin flag in the payload, check logs.

1 Like
11

@falco thanks, it does only contain the kind of warning log entry about a sso request starting and another log entry indicating a successful login.

12

No, it doesn’t.

Click on the entry, then on the tabs below, and it will have every key in the payload and the respective value in a table format.

2 Likes
13

I had multiple issues, resolving them did the trick for me.

  1. My group names needed to meet certain cirteria:

    • must be at least %{min} characters
    • must be no more than %{max} characters
    • must only include numbers, letters, dashes, and underscores
    • must be unique
    • must be present
    • must begin with a letter, a number or an underscore
    • must end with a letter or a number
    • must not contain a sequence of 2 or more special chars (.-_)
    • must not end with a confusing suffix like .json or .png etc.

  2. I did not understand that I needed to create the groups in advance. I thought that they would be created if they did not exist.

  3. I needed to avoid caching in the sso-provider and ensure I get a refreshed list of groups etc.

2 Likes
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.