Page MenuHomePhabricator

Login integration for Sentry
Open, Needs TriagePublic

Description

Sentry should have unified login via LDAP (getsentry-ldap-auth) or Oauth (python-social-auth?).

Event Timeline

Tgr created this task.Apr 24 2015, 2:37 PM
Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a project: Sentry.
Tgr added a subscriber: Tgr.
Restricted Application added a project: Multimedia. · View Herald TranscriptApr 24 2015, 2:37 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Sitic added a subscriber: Sitic.Jul 19 2015, 11:34 PM
Sitic added a comment.Jul 20 2015, 1:27 AM

They seem to be in the process of moving away from python/django-social-auth and implemented their own generic auth system in src/sentry/auth, see issue:1372. I'm not sure what the status of that is, I still see plenty of social-auth references.

Change 240949 had a related patch set uploaded (by Gergő Tisza):
[WIP] LDAP support

https://gerrit.wikimedia.org/r/240949

Tgr added a comment.Sep 29 2015, 8:52 PM

Sentry just opensourced their own login modules: http://blog.getsentry.com/2015/09/29/sso-for-all.html

Tgr added a comment.Oct 6 2015, 12:36 AM

Ori recommended a simpler approach: use some Apache authn module (probably LDAP) and Django's built-in REMOTE_USER-based authentication.

ori added a subscriber: ori.Oct 30 2015, 11:51 PM
In T97133#1704282, @Tgr wrote:

Ori recommended a simpler approach: use some Apache authn module (probably LDAP) and Django's built-in REMOTE_USER-based authentication.

Specifically, the approach we ended up taking with Grafana -- having a public, read-only vhost and a private RW one: see T109723#1759237

Tgr added a comment.Nov 2 2015, 8:12 AM
In T97133#1770795, @ori wrote:

Specifically, the approach we ended up taking with Grafana -- having a public, read-only vhost and a private RW one: see T109723#1759237

The task is private.

The current Sentry role used nginx (that was recommended in the Sentry docs, presumably because it scales better). Nginx does not have native LDAP support. On the internets people usually recommend compiling in nginx-auth-ldap, which does not inspire confidence.

Maybe I can run both apache and nginx, on different ports/vhosts? The user interface does not need to scale and the logging interface does not need auth. I am not sure I can set separate base URLs for them though. Or just discard nginx completely and how apache will be fine under load. Or go back to django_ldap_auth...

ori added a comment.Nov 2 2015, 8:18 AM
In T109723#1759237, @ori wrote:
  • grafana itself is listening only on localhost, on a machine with no public IP.
  • Requests are proxied by Nginx (for SSL) -> Varnish -> Apache / mod_proxy_http.
  • grafana logs in users based on the value of the X-WEBAUTH-USER header set on the request.
  • We serve grafana via two different vhosts: grafana-admin.wikimedia.org and grafana.wikimedia.org.
  • The grafana-admin.wikimedia.org Apache vhost uses mod_authnz_ldap to authenticate the user as a member of ops/wmf/nda groups. It unsets any user-supplied X-WEBAUTH-USER header and sets X-WEBAUTH-USER to the LDAP user CN.
  • The grafana.wikimedia.org Apache vhost does not require authentication. It unsets any user-supplied X-WEBAUTH-USER and sets X-WEBAUTH-USER to 'Anonymous', which is a Grafana account with read-only privileges.
  • For extra insurance, grafana.wikimedia.org also prohibits any POST / PUT / DELETE requests.
  • For extra insurance, X-WEBAUTH-USER is also unset on the varnish layer.
In T97133#1772722, @Tgr wrote:

Maybe I can run both apache and nginx, on different ports/vhosts? The user interface does not need to scale and the logging interface does not need auth.

You could, but that is a bit inelegant. Apache should scale just fine.

Or just discard nginx completely and how apache will be fine under load.

That's what I would do, I think.

Tgr added a comment.Nov 2 2015, 8:54 AM

Thanks, I'll do that.

I'm not sure I understand the point of having two vhosts. Can't you just configure mod_authnz to ask for credentials but then not require valid-user, or use mod_authn_anon?