Auth0 integration

[washort]

Auth0 uses OpenID Connect, similar to Google's signin system, so much of the existing code should be adaptable.

[alison985]

After speaking with Blake last week I created my own Auth0 account for testing purposes.

[alison985]

First PR: https://github.com/mozilla/redash/pull/123

[alison985]

Here is the branch where I am working on this: https://github.com/alison985/mozilla-redash/tree/37_auth0

Current status is that going to http://localhost:5000/ takes you to http://localhost:5000/oauth/auth0?next=http%3A%2F%2Flocalhost%3A5000%2F and gives an Internal Server Error (FYI: 500). This is the error message generated in the console:

server_1 | [2017-07-21 17:46:50,354][PID:135][ERROR][redash] Exception on /oauth/auth0 [GET] server_1 | Traceback (most recent call last): server_1 | File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1988, in wsgi_app server_1 | response = self.full_dispatch_request() server_1 | File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1641, in full_dispatch_request server_1 | rv = self.handle_user_exception(e) server_1 | File "/usr/local/lib/python2.7/dist-packages/flask_restful/init.py", line 271, in error_router server_1 | return original_handler(e) server_1 | File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1544, in handle_user_exception server_1 | reraise(exc_type, exc_value, tb) server_1 | File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1639, in full_dispatch_request server_1 | rv = self.dispatch_request() server_1 | File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1625, in dispatch_request server_1 | return self.view_functionsrule.endpoint server_1 | File "/app/redash/authentication/auth0_oauth.py", line 81, in login server_1 | return auth0_remote_app().authorize(callback=callback, state=next_path) server_1 | File "/app/redash/authentication/auth0_oauth.py", line 38, in auth0_remote_app server_1 | consumer_secret=settings.AUTH0_CLIENT_SECRET server_1 | File "/usr/local/lib/python2.7/dist-packages/flask_oauthlib/client.py", line 71, in remote_app server_1 | remote = OAuthRemoteApp(self, name, **kwargs) server_1 | File "/usr/local/lib/python2.7/dist-packages/flask_oauthlib/client.py", line 276, in init server_1 | "OAuthRemoteApp requires consumer key and secret" server_1 | TypeError: OAuthRemoteApp requires consumer key and secret

However, the consumer_key and consumer_secret are clearly being passed here: https://github.com/alison985/mozilla-redash/blob/37_auth0/redash/authentication/auth0_oauth.py#L37-L38

This is the section of the library that is complaining: Note it clearly refers to the variable names consumer_key and consumer_secret.

I'm at a loss. @washort any thoughts?

[washort]

Looks like Auth0 provides their own Python module for this: https://auth0.com/docs/quickstart/webapp/python

I'll have a look at using it instead of flask-oauthlib here.

[rafrombrc]

Decided to punt on auth0 in the app and instead do the auth in nginx and pass headers back. Relevant upstream issue: https://github.com/getredash/redash/issues/1648

[rafrombrc]

Related: https://bugzilla.mozilla.org/show_bug.cgi?id=1393030

[arikfr]

Does Auth0 support SAML?

[rafrombrc]

In order for the nginx module to meet our needs it has to grow the ability to pass LDAP groups through in an HTTP header. Need to check w EngOps and OpSec re: getting this work done and ongoing ownership.

[jezdez]

I've opened https://github.com/mozilla-services/cloudops-deployment/pull/1514 as the first step towards making this possible.

[jezdez]

And opened #311 with the Redash side of the feature.

@washort @robotblake Could you sanity check if this is something that makes sense for our purposes?

[jezdez]

Note, I did not actually copy the remote_user_auth module into an own module that would contain the user group feature since it's tightly coupled with the index view which would increase the size of the patch to upstream drastically (which I strive not to do with any new feature we add). Also, adding a REMOTE_GROUPS-like feature has a nice parity quality to the already existing REMOTE_USER functionality.

[rafrombrc]

The code work for this is complete, we're waiting on updated auth0 URLs from the ops side, postponing this deployment until m14.

[rafrombrc]

@jasonthomas You're taking this on now, right? We were waiting on this one until we had the release branch / rc environment set up so we could test without breaking things. That stuff is all set up, and ideally I'd like to get this pushed out and working with the next deployment, which we're targeting for immediately after the all hands. Do you have what you need to move forward on this?

[jasonthomas]

I need to look into this further because it will require provisioning auth0 credentials for each environment and configuring nginx to support this method. The effort is fairly low and I should be able to handle this after the all hands.

[rafrombrc]

Waiting for credentials from IT, need to get this pushed to stage so we can validate before pushing to prod.

[jasonthomas]

This is now on stage for validation. https://pipeline-sql.stage.mozaws.net/

[madalincm]

@jasonthomas Stage is up and running at this moment and basic login/logout flows are working. Do you have some sscenarios in mind to validate this other than basic regression testing around the login/logout flows?

[jasonthomas]

I was thinking more on the security side if we are able to bypass the remote_login flow if the client sends the header as part of the request. I can test that part.

[jasonthomas]

I was thinking more on the security side if we are able to bypass the remote_login flow if the client sends the header as part of the request. I can test that part.

Okay I tried testing this two ways - one of by sending the REMOTE_USER as part of the client request and using a REMOTE_USER not associated with me (aka another users email address) after I authenticated successfully. Both method didn't allow me to gain access so I think we are good here.

[jasonthomas]

This has been deployed to all environments.

[madalincm]

No issues have been found during the latest regression testing session so I will mark this bug as verified fixed.