Project

General

Profile

Actions

tickets #166250

open

Kanidm 1.4.0 upgrade preparation - oauth2

Added by firstyear about 2 months ago. Updated about 1 month ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
FreeIPA/Kanidm
Target version:
-
Start date:
2024-09-04
Due date:
% Done:

60%

Estimated time:

Description

In order to harder OAuth2 against certain classes of redirection attacks Kanidm will strictly enforce the redirection URIs used in future.

# kanidmd domain upgrade-check
📜 Using config file: "/etc/kanidm/server.toml"
00000000-0000-0000-0000-000000000000 WARN     🚧 [warn]: This is running as uid == 0 (root) which may be a security risk.
00000000-0000-0000-0000-000000000000 WARN     🚧 [warn]: WARNING: DB folder permissions on /var/lib/private/kanidm indicate it may not be RW. This could cause the server start up to fail!
00000000-0000-0000-0000-000000000000 INFO     i [info]: Running domain upgrade check ...
00000000-0000-0000-0000-000000000000 INFO     i [info]: domain_name            : infra.opensuse.org
00000000-0000-0000-0000-000000000000 INFO     i [info]: domain_uuid            : d3d06344-5441-4e07-80b1-ba478d2f2229
00000000-0000-0000-0000-000000000000 INFO     i [info]: domain_current_level   : 7
00000000-0000-0000-0000-000000000000 INFO     i [info]: domain_upgrade_level   : 8
00000000-0000-0000-0000-000000000000 INFO     i [info]: ------------------------
00000000-0000-0000-0000-000000000000 INFO     i [info]: upgrade_item           : security key usage
00000000-0000-0000-0000-000000000000 INFO     i [info]: status                 : PASS
00000000-0000-0000-0000-000000000000 INFO     i [info]: ------------------------
00000000-0000-0000-0000-000000000000 INFO     i [info]: upgrade_item           : oauth2 strict redirect uri enforcement
00000000-0000-0000-0000-000000000000 INFO     i [info]: status                 : FAIL
00000000-0000-0000-0000-000000000000 INFO     i [info]: description            : To harden against possible public client open redirection vulnerabilities, redirect uris must now be registered ahead of time and are validated rather than the former origin verification process.
00000000-0000-0000-0000-000000000000 INFO     i [info]: action                 : Verify the redirect uri's for OAuth2 clients and then enable strict-redirect-uri on each client.
00000000-0000-0000-0000-000000000000 INFO     i [info]: affected_entry         : gitlab@infra.opensuse.org
00000000-0000-0000-0000-000000000000 INFO     i [info]: affected_entry         : grafana@infra.opensuse.org
00000000-0000-0000-0000-000000000000 INFO     i [info]: affected_entry         : netbox@infra.opensuse.org
00000000-0000-0000-0000-000000000000 INFO     i [info]: affected_entry         : matomo@infra.opensuse.org

The following 4 entries need to be checked and updated so that:

  • kanidm system oauth2 set-landing-url matches the expected "frontpage" of the application
  • kanidm system oauth2 add-redirect-url matches the expected full URI where a client will redirect to. For example, https://example.app.suse.de/oauth2/redirect

Once configured, the strict url check needs to be enabled (enable-strict-redirect-url)

For example, grafana needs to change to https://grafana.infra.opensuse.org/login/generic_oauth or gitlab to https://gitlab.infra.opensuse.org/oauth/redirect

I didn't want to just change these myself, since this obviously has the capacity to cause some outages to the affected applications.

No client changes are needed - this is purely a Kanidm only change.


Checklist

  • Grafana
  • GitLab
  • Matomo
  • NetBox
  • Enable strict mode
Actions #1

Updated by crameleon about 2 months ago

  • Tracker changed from communication to tickets
  • Category set to FreeIPA/Kanidm
  • Private changed from Yes to No
Actions #2

Updated by crameleon about 2 months ago

  • Checklist item Grafana added
  • Checklist item GitLab added
  • Checklist item Matomo added
  • Checklist item NetBox added

With some applications I used the login path in the landing URL so the user gets directly logged in to the requested application when clicking the respective tile in idm.i.o.o.

The redirect URLs, some applications are a bit specific, for example Matomo uses query parameters in the redirect URL, but of course we shall set them.

Actions #3

Updated by crameleon about 2 months ago

  • Checklist item Grafana set to Done
Actions #4

Updated by crameleon about 1 month ago

  • Checklist item GitLab set to Done
  • Status changed from New to In Progress
  • Assignee set to crameleon
  • % Done changed from 0 to 50
Actions #5

Updated by crameleon about 1 month ago · Edited

  • Checklist item Matomo set to Done
  • % Done changed from 50 to 60
  • Were the URLs you provided for GitLab and Grafana just examples? They do not match the parameters I find upon login:

GitLab:

redirect_uri=https%3A%2F%2Fgitlab.infra.opensuse.org%2Fusers%2Fauth%2Fopenid_connect%2Fcallback
=> https://gitlab.infra.opensuse.org/users/auth/openid_connect/callback

Grafana:

redirect_uri=https%3A%2F%2Fmonitor.opensuse.org%2Fgrafana%2Flogin%2Fgeneric_oauth
=> https://monitor.opensuse.org/grafana/login/generic_oauth

Matomo (not one you provided one for, but listing as well for completeness):

redirect_uri=https%3A%2F%2Fbeans.opensuse.org%2Fmatomo%2Findex.php%3Fmodule%3DLoginOIDC%26action%3Dcallback%26provider%3Doidc
=> https://beans.opensuse.org/matomo/index.php?module=LoginOIDC&action=callback&provider=oidc

  • Should the existing/old redirect URLs (which I might have set accidentally to the root of the application when originally configuring the oauth2 clients) be deleted?
oauth2_rs_origin: https://gitlab.infra.opensuse.org/
oauth2_rs_origin: https://monitor.opensuse.org/grafana/
oauth2_rs_origin: https://beans.opensuse.org/
  • Can I test if the whitelist behaves correctly before enabling the strict mode? Not a problem if not, just wondering if it's logged somewhere if a redirect URL matches. :-)
Actions #6

Updated by crameleon about 1 month ago

  • Checklist item Enable strict mode added
Actions #7

Updated by firstyear about 1 month ago · Edited

Sadly there isn't really a way to test before you turn on strict. Best option is configure the URLs, enable strict and test, then if it fails, disable the strict mode again.

Re the urls, I did look them up but I didn't confirm if gitlab/grafana were correct. So if the URLs you found here are the ones, lets configure those :)

And yes, once we know it's working we should remove the old urls too.

Actions

Also available in: Atom PDF