OpenID Connect support #752

nogweii · 2018-08-13T03:49:58Z

nogweii
Aug 13, 2018

It would be nice if healthchecks supported OAuth/OpenID Connect or similar for on-premise deployments. That way a user could be redirected to a central IAM platform (AWS's, Active Directory's Federated Services, Keycloak, there a number of similar providers and tools) that they likely are already logged in to.

nogweii · 2018-11-15T17:16:31Z

nogweii
Nov 15, 2018
Author

LDAP support (#198) is fairly similar to this request, though this is more about SSO -- redirecting the user to the authentication server rather than requiring them to type their username and password again.

0 replies

hongkongkiwi · 2018-11-27T05:42:36Z

hongkongkiwi
Nov 27, 2018

We would like to do Google Authentication, we already use this for all our other internal tools and it works really well taking the security burden away from us.

Can this be added? I think this would be invaluable for your amazing tool.

0 replies

jameskirsop · 2019-04-24T04:29:53Z

jameskirsop
Apr 24, 2019

Another way of approaching this would be to allow HTTP Headers to authenticate a user - in a similar way to Grafana or Zabbix (among many other tools) do.

Alternatively, I've got django_auth_adfs working quite well. I had to manually edit my superuser account to have my UPN as the username, but after that I'm able to sign in and get redirected to my projects with no issue.

Adding ADFS support was pretty simple (in the same way that adding plain AD support seemed easy in #198). I just needed to make sure that LOGIN_URL was set so it redirected my login requests to ADFS instead of the standard healthchecks.io login page.

0 replies

nogweii · 2019-04-25T04:59:30Z

nogweii
Apr 25, 2019
Author

@jameskirsop I would love to see any changes you've made to make ADFS work. Could you share those here, or perhaps as a gist?

0 replies

jameskirsop · 2019-04-30T23:12:29Z

jameskirsop
Apr 30, 2019

@evaryont, installed django_auth_adfs via pip and then used the following.

Added the appropriate config to INSTALLED_APPS, MIDDLEWARE and AUTHENTICATION_BACKENDS.

And used this:

    "SERVER": "adfs.mycompany.com.au",
    "CLIENT_ID": "microsoft:identityserver:companyname-healthio",
    "RESOURCE": "companyname-healthio",
    "AUDIENCE": "microsoft:identityserver:companyname-healthio",
    "CLAIM_MAPPING": {"first_name": "given_name",
                      "last_name": "family_name",
                      "email": "email",
                      },
    "USERNAME_CLAIM": 'upn',
}

LOGIN_URL = "django_auth_adfs:login"

A couple of caveats I've found:

When inviting a user via email address the address is translated to lowercase. For users with capitals in their UPN, and then (in some cases) also in the email address handed back in claims, they're logged in with a new account instead because the two don't match. Eg. JBlogs@domain.com is stored as jblogs@domain.com and ADFS can't find a match, it seems.
If a new user logs in without having an account, the 'username' field is populated with their UPN. While this is expected behaviour with django_auth_adfs, it breaks functionality with Healthchecks - particularly when you try and invite an existing ADFS-created user to a project/team - and results in a 500 error - I'm expecting because of the first caveat:

django.urls.exceptions.NoReverseMatch: Reverse for 'hc-check-token' with arguments '('lowercaseaddress@lowercase.com', 'LLFZNDr4u9iGDFlOcb-TVHgIHj5GK2ZU')' not found. 1 pattern(s) tried: ['accounts\\\\/check_token\\\\/(?P<username>[-a-zA-Z0-9_]+)\\\\/(?P<token>[-a-zA-Z0-9_]+)\\\\/$']

The way I get around both of these, currently, is manually copying the token created by Healthcheck, deleting the 'invited' account created by Healthcheck (via ./manage.py shell) and pasting the token into the username field in the database. It's a hacky way of doing it, but it seems to work.

Not using LowercaseEmailField for user accounts would be a step towards allowing better ADFS support in my opinion, but I do understand why it's a useful way of storing emails on public services. Alternatively, manually changing the way django_auth_adfs middleware handles this could be an appropriate option - to have it always translate email address claims to lowercase.

0 replies

jameskirsop · 2019-05-01T03:04:56Z

jameskirsop
May 1, 2019

A few hours later and I've made some significant progress with working around the above.

I've subclassed the AdfsBaseBackend and AdfsAuthCodeBackend classes from django_auth_adfs and made a minor tweak so that it handles getting the appropriate claim back and then translates it to work correctly within the existing HealthChecks framework.

I'm going to do some more testing and then put together a PR for a secondary backend that can optionally be used to bridge the divide between HealthCheck and ADFS.

0 replies

lukasmrtvy · 2019-10-25T08:41:37Z

lukasmrtvy
Oct 25, 2019

References:
OIDC: https://django-oauth-toolkit.readthedocs.io/
LDAP: https://django-auth-ldap.readthedocs.io/en/latest/
ADFS: https://django-auth-adfs.readthedocs.io/en/latest/

0 replies

nogweii · 2019-12-24T13:45:19Z

nogweii
Dec 24, 2019
Author

I have the ultimate hack, adding OpenID Connect support to Healthchecks without modifying any code:

from .settings import INSTALLED_APPS as settings_ia
from .settings import AUTHENTICATION_BACKENDS as settings_ab
from .settings import ROOT_URLCONF as settings_ru

INSTALLED_APPS = list(settings_ia)
INSTALLED_APPS.insert(INSTALLED_APPS.index("django.contrib.auth")+1, "mozilla_django_oidc")
INSTALLED_APPS = tuple(INSTALLED_APPS)

AUTHENTICATION_BACKENDS = settings_ab + ("mozilla_django_oidc.auth.OIDCAuthenticationBackend",)

OIDC_RP_CLIENT_ID = "client-789"
OIDC_RP_CLIENT_SECRET = "secret-123"
OIDC_OP_AUTHORIZATION_ENDPOINT = "https://example.com/openid-connect/auth"
OIDC_OP_TOKEN_ENDPOINT = "https://example.com/openid-connect/token"
OIDC_OP_USER_ENDPOINT = "https://example.com/openid-connect/userinfo"
OIDC_OP_JWKS_ENDPOINT = "https://example.com/openid-connect/certs"
OIDC_RP_SIGN_ALGO = "RS256"

LOGIN_REDIRECT_URL = '/'

from django.urls import path, include
from django.views.generic.base import RedirectView
from types import ModuleType

# Create a dynamic module that injects some additional routes before HC's
sys.modules['sneaky_url'] = ModuleType('sneaky_url')
class _Sneaky(ModuleType):
  @property
  def urlpatterns(self):
    return [
      path('oidc/', include('mozilla_django_oidc.urls')),
      path('accounts/login/', RedirectView.as_view(url='/oidc/authenticate', permanent=True)),
      path('', include(settings_ru))
    ]
sys.modules['sneaky_url'].__class__ = _Sneaky
ROOT_URLCONF = 'sneaky_url'

Copy & paste this into local_settings.py and it should, roughly, Just Work. Oh, and make sure you run pip install mozilla-django-oidc.

@cuu508 I'm sorry for this horrible python but it's pretty clever, eh?

0 replies

cuu508 · 2019-12-26T14:54:51Z

cuu508
Dec 26, 2019
Maintainer

@evaryont that's quite a hack indeed! 👍

I'm interested in adding "official" OpenID Connect support into the project and the hosted site as well. Picking the default identity providers will be tricky, but starting with Github and Google seems reasonable.

Checking out mozilla-django-oidc library now – looks like it's designed to support a single, preconfigured identity provider, right?

0 replies

nogweii · 2020-01-02T02:47:27Z

nogweii
Jan 2, 2020
Author

Indeed, looking around there isn't a way to configure it to support multiple providers simultaneously. You might be able to get it working by creating multiple applications, one for each provider, but boy that does sound hacky.

0 replies

decentral1se · 2020-04-10T13:47:47Z

decentral1se
Apr 10, 2020

Is anyone working on this? I'd be most interested in Keycloak integration and I see that there is https://django-keycloak.readthedocs.io/en/latest/. Is anyone against me taking a stab at integrating this just for Keycloak?

0 replies

cuu508 · 2020-04-14T07:57:36Z

cuu508
Apr 14, 2020
Maintainer

Hi @decentral1se – here's a quick summary of my plans and the current situation.

I've looked at adding OIDC auth option. I haven't started any development on it. When looking at this, and making a survey of what other similar services support, it seemed Google and Github would be good candidates for initial identity providers to support.
I haven't looked at how OIDC auth would integrate the existing authentication – what new database fields, forms, email messages etc. would be needed. Some nontrivial work and design decisions here.
I've also considered adding SAML support. No customer has explicitly asked for it, and there might be ways to support it indirectly via, say, Auth0. So I don't have near-term plans to work on it.

I'm not familiar with Keycloak (or, to be completely honest, with the other mentioned technologies), would Keycloak work as another OIDC identity provider? If that's the case, we should plan for supporting other OIDC providers in future too.

0 replies

lukasmrtvy · 2020-04-14T08:25:22Z

lukasmrtvy
Apr 14, 2020

Keycloak, https://github.com/dexidp/dex or generic oidc provider connector is always good start, because these will allow to You "federate" from other upstream oidc providers.

0 replies

lukasmrtvy · 2020-07-14T12:52:45Z

lukasmrtvy
Jul 14, 2020

@cuu508 is there any progress ?

0 replies

cuu508 · 2020-07-14T13:04:49Z

cuu508
Jul 14, 2020
Maintainer

@lukasmrtvy from my side, unfortunately no.

0 replies

jameskirsop · 2020-07-15T11:12:22Z

jameskirsop
Jul 15, 2020

Here's a blob of the subclasses I wrote for django_auth_adfs integration with Healthchecks. I've been using this in production for about 12 months now with no issue back against initially ADFS, and now AzureAD.

I don't know, @cuu508, if you'd like to have this in the project to allow for some support of third party logins for those who are hosting themselves?? It might be a little niche, but it would solve the problem for a number of people who've posted on this issue.

I'm happy to create a PR for this after writing up some documentation, if you'd like to have it included.

0 replies

peppelinux · 2020-07-17T15:49:22Z

peppelinux
Jul 17, 2020

I used djangosaml2 for doing SAML2 authentication, an example in my fork here, see saml2_sp and requirements:
https://github.com/UniversitaDellaCalabria/healthchecks

0 replies

Akruidenberg · 2022-01-03T07:12:18Z

Akruidenberg
Jan 3, 2022

+1 for this feature!

0 replies

peppelinux · 2022-01-03T09:11:52Z

peppelinux
Jan 3, 2022

I'd suggest also SATOSA as IAM Proxy

See
https://github.com/italia/Satosa-Saml2Spid

0 replies

nogweii · 2022-01-11T01:23:18Z

nogweii
Jan 11, 2022
Author

With the HTTP header auth merged in, I think the only thing that remains would be an example configuration of something like the following stack:

nginx/apache/traefik/caddy listening for incoming requests on 80 & 443
oauth2-proxy or vouch-proxy intercepting some portion of the requests (for example, we don't want to require an OIDC session to send a ping)
Everything else being reverse proxied to django & Healthchecks itself.

Documenting that and referring people to it should hopefully provide the foundation for plugging in whatever authentication proxies people would like.

@cuu508 the only I'd like to ask of you is do you have a list of routes that should be excluded from from authentication? I could make some guesses, but it would be nice to be more confident about the choices.

0 replies

cuu508 · 2022-01-13T11:57:27Z

cuu508
Jan 13, 2022
Maintainer

Hi @nogweii, here'sthe list of routes that I think would make sense to be excluded from authentication:

urlpattern	view	view name
`/`	hc.front.views.index	hc-index
`/accounts/unsubscribe_reports/<str:signed_username>/`	hc.accounts.views.unsubscribe_reports	hc-unsubscribe-reports
`/api/v1/badges/`	hc.api.views.badges
`/api/v1/channels/`	hc.api.views.channels
`/api/v1/checks/`	hc.api.views.checks
`/api/v1/checks/<sha1:unique_key>`	hc.api.views.get_check_by_unique_key
`/api/v1/checks/<sha1:unique_key>/flips/`	hc.api.views.flips_by_unique_key
`/api/v1/checks/<uuid:code>`	hc.api.views.single	hc-api-single
`/api/v1/checks/<uuid:code>/flips/`	hc.api.views.flips_by_uuid	hc-api-flips
`/api/v1/checks/<uuid:code>/pause`	hc.api.views.pause	hc-api-pause
`/api/v1/checks/<uuid:code>/pings/`	hc.api.views.pings	hc-api-pings
`/api/v1/metrics/`	hc.api.views.metrics
`/api/v1/notifications/<uuid:code>/status`	hc.api.views.notification_status	hc-api-notification-status
`/api/v1/status/`	hc.api.views.status
`/badge/<slug:badge_key>/<slug:signature>.<slug:fmt>`	hc.api.views.badge	hc-badge-all
`/badge/<slug:badge_key>/<slug:signature>/<quoted:tag>.<slug:fmt>`	hc.api.views.badge	hc-badge
`/checks/cron_preview/`	hc.front.views.cron_preview
`/docs/`	hc.front.views.serve_doc	hc-docs
`/docs/<slug:doc>/`	hc.front.views.serve_doc	hc-serve-doc
`/docs/cron/`	hc.front.views.docs_cron	hc-docs-cron
`/integrations/<uuid:code>/unsub/<str:signed_token>/`	hc.front.views.unsubscribe_email	hc-unsubscribe-alerts
`/integrations/<uuid:code>/verify/<slug:token>/`	hc.front.views.verify_email	hc-verify-email
`/integrations/add_pushover/`	hc.front.views.pushover_help	hc-pushover-help
`/integrations/add_slack/`	hc.front.views.slack_help	hc-slack-help
`/integrations/pagerduty/`	hc.front.views.pd_help	hc-pagerduty-help
`/integrations/telegram/`	hc.front.views.telegram_help	hc-telegram-help
`/integrations/telegram/bot/`	hc.front.views.telegram_bot	hc-telegram-webhook
`/ping/<slug:ping_key>/<slug:slug>`	hc.api.views.ping_by_slug
`/ping/<slug:ping_key>/<slug:slug>/<int:exitstatus>`	hc.api.views.ping_by_slug
`/ping/<slug:ping_key>/<slug:slug>/fail`	hc.api.views.ping_by_slug
`/ping/<slug:ping_key>/<slug:slug>/start`	hc.api.views.ping_by_slug
`/ping/<uuid:code>`	hc.api.views.ping
`/ping/<uuid:code>/`	hc.api.views.ping
`/ping/<uuid:code>/<int:exitstatus>`	hc.api.views.ping
`/ping/<uuid:code>/fail`	hc.api.views.ping
`/ping/<uuid:code>/start`	hc.api.views.ping
`/projects/<uuid:code>/checks/metrics/<slug:key>`	hc.front.views.metrics
`/projects/<uuid:code>/metrics/<slug:key>`	hc.front.views.metrics	hc-metrics
`/tv/`	hc.front.views.dashboard	hc-dashboard

0 replies

axelcypher · 2022-03-25T19:15:56Z

axelcypher
Mar 25, 2022

With the HTTP header auth merged in, I think the only thing that remains would be an example configuration of something like the following stack:

nginx/apache/traefik/caddy listening for incoming requests on 80 & 443

oauth2-proxy or vouch-proxy intercepting some portion of the requests (for example, we don't want to require an OIDC session to send a ping)

Everything else being reverse proxied to django & Healthchecks itself.

Documenting that and referring people to it should hopefully provide the foundation for plugging in whatever authentication proxies people would like.

@cuu508 the only I'd like to ask of you is do you have a list of routes that should be excluded from from authentication? I could make some guesses, but it would be nice to be more confident about the choices.

Soooo... did anyone managed to get it to work? Right now i'm trying to authenticate via Authentik with Traefik, but i can't get it to work...

1 reply

scheibling Mar 10, 2023

Recently set this up in Kubernetes, but should work on Docker as well (with the addition of a reverse proxy able to route things the way described in the ingress configuration, everything to the proxy except the /ping/ prefix) https://github.com/CloudyneS/healthchecks-k8s-oidc

cuu508 · 2022-12-16T10:18:48Z

cuu508
Dec 16, 2022
Maintainer

I currently have no plans to add OIDC authentication options. I want to preserve the discussion in the comments, so I'm converting this issue to a discussion rather than closing it.

0 replies

scheibling · 2023-03-10T11:05:43Z

scheibling
Mar 10, 2023

A very simple version of the oauth2-proxy/healthchecks setup (on k8s) is described here: https://github.com/CloudyneS/healthchecks-k8s-oidc. We recently set it up and it seems to be working well overall.

I have not specified the routes as explicitly as @cuu508 described, it's more of a working POC setup for adding authentication via OIDC that can be further customized. Will probably add those options at some point and convert it to a chart/something more complete and add a POC for docker as well.

0 replies

Coo-ops · 2023-05-01T05:17:32Z

Coo-ops
May 1, 2023

Need it, everything should have it. It's the future.

0 replies

Suertzz · 2024-02-12T15:56:17Z

Suertzz
Feb 12, 2024

Hello guys,

Do you plan to add it near 2024 ? We need this feature 😇

2 replies

cuu508 Feb 12, 2024
Maintainer

I currently have no plans to add OIDC authentication options.

If you are using a self-hosted instance, you can put an authentication proxy in front of Healthchecks. One example using oauth2-proxy was posted earlier in the comments – https://github.com/CloudyneS/healthchecks-k8s-oidc

IIUC some people are using Authelia with Healthchecks as well. I have no personal experience with either, so cannot give specific recommendations.

TheCataliasTNT2k Apr 14, 2024

Would be great to have it...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OpenID Connect support #752

{{title}}

Replies: 26 comments 3 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

OpenID Connect support #752

Replies: 26 comments · 3 replies

nogweii Nov 15, 2018 Author

nogweii Apr 25, 2019 Author

nogweii Dec 24, 2019 Author

cuu508 Dec 26, 2019 Maintainer

nogweii Jan 2, 2020 Author

cuu508 Apr 14, 2020 Maintainer

cuu508 Jul 14, 2020 Maintainer

nogweii Jan 11, 2022 Author

cuu508 Jan 13, 2022 Maintainer

cuu508 Dec 16, 2022 Maintainer

cuu508 Feb 12, 2024 Maintainer

Replies: 26 comments 3 replies

nogweii
Nov 15, 2018
Author

nogweii
Apr 25, 2019
Author

nogweii
Dec 24, 2019
Author

cuu508
Dec 26, 2019
Maintainer

nogweii
Jan 2, 2020
Author

cuu508
Apr 14, 2020
Maintainer

cuu508
Jul 14, 2020
Maintainer

nogweii
Jan 11, 2022
Author

cuu508
Jan 13, 2022
Maintainer

cuu508
Dec 16, 2022
Maintainer

cuu508 Feb 12, 2024
Maintainer