tickets #134747
closed
Forum Login Issues - Ipsilon Issue
Added by malcolmlewis 9 months ago.
Updated 9 months ago.
Description
Hi
Useras are reporting random login issues. According to @hellcp this is
pointing to Ipsilon being broken?
From the Discourse logs;
Message (311 copies reported)
(oidc) Authentication failure! unauthorized_client:
OmniAuth::Strategies::OAuth2::CallbackError, unauthorized_client |
Unknown client ID
Backtrace
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-1.9.2/lib/omniauth/strategy.rb:163:in
`log'
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-1.9.2/lib/omniauth/strategy.rb:486:in
`fail!'
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-oauth2-1.7.3/lib/omniauth/strategies/oauth2.rb:89:in
`callback_phase'
/srv/www/vhosts/discourse/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb:107:in
`callback_phase'
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-1.9.2/lib/omniauth/strategy.rb:238:in
`callback_call'
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-1.9.2/lib/omniauth/strategy.rb:189:in
`call!'
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-1.9.2/lib/omniauth/strategy.rb:169:in
`call'
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-1.9.2/lib/omniauth/strategy.rb:192:in
`call!'
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-1.9.2/lib/omniauth/strategy.rb:169:in
`call'
/usr/lib64/ruby/gems/3.2.0/gems/omniauth-1.9.2/lib/omniauth/strategy.rb:192:in
`call!'
Env
HTTP HOSTS: forums.opensuse.org
--
Cheers Malcolm °¿° (Linux Counter #276890)
Tumbleweed 20230823 | GNOME Shell 44.3 | 6.4.11-1-default
HP Z440 | Xeon E5-2695 V4 X36 @ 2.10GHz | Quadro T400/Tesla P4
up 2 days 0:42, 3 users, load average: 0.75, 0.36, 0.16
- Category set to Accounts
- Assignee set to crameleon
- Private changed from Yes to No
The client ID need to match between the OIDC client (i.e. Discourse) and the client entry in the OIDC provider (i.e. Ipsilon). It is the one an Ipsilon admin generated for you when Discourse was initially set up. Usually if there is a mismatch this would result in authentication not being possible at all, and I wonder about your report about this only happening sporadically. Does it happen for specific users or are the affected users and occurrence times random?
It seems Discourse tries to use two different client ID's to authenticate against OIDC.
Here is a working authentication flow:
[Mon Aug 28 00:16:29.109750 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:35716] (null) - - [28/Aug/2023:00:16:29] "GET /openidc/Continue?ipsilon_transaction_id=b66b6f28-aac8-40f4-bee9-ba75ac361208 HTTP/1.1" 303 406 "https://id.opensuse.org/login/ldap?ipsilon_transaction_id=b66b6f28-aac8-40f4-bee9-ba75ac361208" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36"
[Mon Aug 28 00:16:29.326247 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:35730] [28/Aug/2023:00:16:29] DEBUG(providers/openidc/api.py:147 Token._authenticate_client()): openidc: Trying to authenticate client
[Mon Aug 28 00:16:29.328917 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:35730] [28/Aug/2023:00:16:29] DEBUG(providers/openidc/api.py:149 Token._authenticate_client()): openidc: Authorization header found
[Mon Aug 28 00:16:29.330438 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:35730] [28/Aug/2023:00:16:29] DEBUG(providers/openidc/api.py:152 Token._authenticate_client()): openidc: Authorization header is basic
[Mon Aug 28 00:16:29.332004 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:35730] [28/Aug/2023:00:16:29] DEBUG(providers/openidc/api.py:163 Token._authenticate_client()): openidc: Client ID: discourse.opensuse.org
[Mon Aug 28 00:16:29.333624 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:35730] [28/Aug/2023:00:16:29] DEBUG(providers/openidc/api.py:105 Token._handle_client_authentication()): openidc: Trying client auth for discourse.opensuse.org with method client_secret_basic
Here is a failing one:
[Mon Aug 28 01:55:08.489639 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:50250] (null) - - [28/Aug/2023:01:55:08] "GET /openidc/Continue?ipsilon_transaction_id=f2150e78-adce-4b84-854d-213bf2bceab5 HTTP/1.1" 303 406 "https://id.opensuse.org/login/ldap?ipsilon_transaction_id=f2150e78-adce-4b84-854d-213bf2bceab5" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0"
[Mon Aug 28 01:55:08.765006 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:50256] [28/Aug/2023:01:55:08] DEBUG(providers/openidc/api.py:147 Token._authenticate_client()): openidc: Trying to authenticate client
[Mon Aug 28 01:55:08.766838 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:50256] [28/Aug/2023:01:55:08] DEBUG(providers/openidc/api.py:149 Token._authenticate_client()): openidc: Authorization header found
[Mon Aug 28 01:55:08.768423 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:50256] [28/Aug/2023:01:55:08] DEBUG(providers/openidc/api.py:152 Token._authenticate_client()): openidc: Authorization header is basic
[Mon Aug 28 01:55:08.769955 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:50256] [28/Aug/2023:01:55:08] DEBUG(providers/openidc/api.py:163 Token._authenticate_client()): openidc: Client ID: discourse-oidc
[Mon Aug 28 01:55:08.771794 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:50256] [28/Aug/2023:01:55:08] DEBUG(providers/openidc/api.py:105 Token._handle_client_authentication()): openidc: Trying client auth for discourse-oidc with method client_secret_basic
[Mon Aug 28 01:55:08.773536 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:50256] [28/Aug/2023:01:55:08] ERROR: Client authentication with invalid client ID
[Mon Aug 28 01:55:08.775291 2023] [wsgi:error] [pid 29413] [remote 192.168.47.21:50256] [28/Aug/2023:01:55:08] DEBUG(providers/openidc/api.py:19 APIError.__init__()): OpenIDC API error: invalid_client, desc: client authentication error
The client ID "discourse-oidc" is not valid. In Ipsilon, only a client with the ID "discourse.opensuse.org" exists.
Can you check if there are possibly multiple OIDC backends configured in Discourse, and if so, disable all but the one configured to use the client ID "discourse.opensuse.org"?
There is only one plugin present;
"discourse-openid-connect"
I do see an entry called "openid connect error redirects" connected to an Admin account?
The plugin has a configuration option "client_id":
discourse01 (discourse):~ # head -n10 /srv/www/vhosts/discourse/plugins/discourse-openid-connect/config/settings.yml
plugins:
openid_connect_enabled:
default: false
openid_connect_discovery_document:
default: ""
openid_connect_client_id:
default: ""
openid_connect_client_secret:
default: ""
openid_connect_rp_initiated_logout:
Unfortunately I could not find where its value is stored outside of the GUI, hence please check again on your end - https://meta.discourse.org/t/discourse-openid-connect/103632#example-setup-5 says "Go to your Discourse site settings and search for “openid_connect”".
This is empty too:
discourse=# SELECT * FROM user_associated_accounts LIMIT 100;
id | provider_name | provider_uid | user_id | last_used | info | credentials | extra | created_at | updated_at
----+---------------+--------------+---------+-----------+------+-------------+-------+------------+------------
(0 rows)
Search done, which only has the one plugin information shown;
YES - openid connect enabled:
YES - openid connect discovery document: https://accounts.google.com/.well-known/openid-configuration
YES -openid connect client id: <client-id>
YES - openid connect client secret: <client-secret>
YES openid connect authorize scope: openid email (with a space in between)
In addition to the above, the following are selected/populated;
SELECTED - openid connect username association change
SELECTED - openid connect overrides email
AN ADMIN EMAIL/PASSWORD - openid connect error redirects
Yes the openid connect client id == discourse.opensuse.org
- Category changed from Accounts to Forum
- Assignee deleted (
crameleon)
Then I don't understand why it would sometimes send "discourse-oidc" as its client ID.
Sorry, but I do not think this is an issue with Ipsilon. Someone who installed this or knows more about the plugin should investigate why it reports itself with changing client IDs.
Ipsilon, like any OIDC provider, expects a static client ID and secret pair, which was provided when the client was created. The correct client ID, registered in Ipsilon, is "discourse.opensuse.org".
Seems like a combination of few things, somebody messed around with the admin settings for oidc, and the value was changed to discourse-oidc (it might even have been a missclick restoring the value to default), but discourse doesn't apply instance settings fully until you restart puma behind it, since some of this stuff is cached in a weird way, so it only applied to some sessions. I did change the setting back and restarted puma now
- Status changed from New to Resolved
Thank you for elaborating and solving, @hellcp!
As it's not easy to reproduce and I assume your solution was all that's needed, I'll close this ticket. We can of course re-open it should there still be related issue reports from users in the next days.
Also available in: Atom
PDF