mirror of https://github.com/zulip/zulip.git
125 lines
5.4 KiB
Markdown
125 lines
5.4 KiB
Markdown
# Supported authentication methods
|
|
|
|
Zulip supports several different authentications methods:
|
|
|
|
* `EmailAuthBackend` - Email/password authentication.
|
|
* `ZulipLDAPAuthBackend` - LDAP username/password authentication.
|
|
* `GoogleMobileOauth2Backend` - Google authentication.
|
|
* `ZulipRemoteUserBackend` - Authentication using an existing
|
|
Single-Sign-On (SSO) system that can set REMOTE_USER in Apache.
|
|
* `DevAuthBackend` - Only for development, passwordless login as any user.
|
|
* Likely more coming (e.g. there's work on [GitHub auth](https://github.com/zulip/zulip/issues/1042)).
|
|
|
|
The setup documentation for most of these is simple enough that we've
|
|
included it inline in `/etc/zulip/settings.py`, right above to the
|
|
settings used to configure them. The remote user authentication
|
|
backend is more complex since it requires interfacing with a generic
|
|
third-party authentication system, and so we've documented it in
|
|
detail here.
|
|
|
|
## Remote User SSO Authentication
|
|
|
|
Zulip supports integrating with a Single-Sign-On solution. There are
|
|
a few ways to do it, but this section documents how to configure Zulip
|
|
to use an SSO solution that best supports Apache and will set the
|
|
`REMOTE_USER` variable:
|
|
|
|
(0) Check that `/etc/zulip/settings.py` has
|
|
`zproject.backends.ZulipRemoteUserBackend` as the only enabled value
|
|
in the `AUTHENTICATION_BACKENDS` list, and that `SSO_APPEND_DOMAIN` is
|
|
correct set depending on whether your SSO system uses email addresses
|
|
or just usernames in `REMOTE_USER`.
|
|
|
|
Make sure that you've restarted the Zulip server since making this
|
|
configuration change.
|
|
|
|
(1) Edit `/etc/zulip/zulip.conf` and change the `puppet_classes` line to read:
|
|
|
|
```
|
|
puppet_classes = zulip::voyager, zulip::apache_sso
|
|
```
|
|
|
|
(2) As root, run `/home/zulip/deployments/current/scripts/zulip-puppet-apply`
|
|
to install our SSO integration.
|
|
|
|
(3) To configure our SSO integration, edit
|
|
`/etc/apache2/sites-available/zulip-sso.example` and fill in the
|
|
configuration required for your SSO service to set `REMOTE_USER` and
|
|
place your completed configuration file at `/etc/apache2/sites-available/zulip-sso.conf`
|
|
|
|
`zulip-sso.example` is correct configuration for using an `htpasswd`
|
|
file for `REMOTE_USER` authentication, which is useful for testing
|
|
quickly. You can set it up by doing the following:
|
|
|
|
```
|
|
/home/zulip/deployments/current/scripts/restart-server
|
|
cd /etc/apache2/sites-available/
|
|
cp zulip-sso.example zulip-sso.conf
|
|
htpasswd -c /home/zulip/zpasswd username@example.com # prompts for a password
|
|
```
|
|
|
|
and then continuing with the steps below.
|
|
|
|
(4) Run `a2ensite zulip-sso` to enable the Apache integration site.
|
|
|
|
(5) Run `service apache2 reload` to use your new configuration. If
|
|
Apache isn't already running, you may need to run `service apache2
|
|
start` instead.
|
|
|
|
Now you should be able to visit `https://zulip.example.com/` and
|
|
login via the SSO solution.
|
|
|
|
|
|
### Troubleshooting Remote User SSO
|
|
|
|
This system is a little finicky to networking setup (e.g. common
|
|
issues have to do with /etc/hosts not mapping settings.EXTERNAL_HOST
|
|
to the Apache listening on 127.0.0.1/localhost, for example). It can
|
|
often help while debugging to temporarily change the Apache config in
|
|
/etc/apache2/sites-available/zulip-sso to listen on all interfaces
|
|
rather than just 127.0.0.1 as you debug this. It can also be helpful
|
|
to change /etc/nginx/zulip-include/app.d/external-sso.conf to
|
|
proxy_pass to a more explicit URL possibly not over HTTPS when
|
|
debugging. The following log files can be helpful when debugging this
|
|
setup:
|
|
|
|
* /var/log/zulip/{errors.log,server.log} (the usual places)
|
|
* /var/log/nginx/access.log (nginx access logs)
|
|
* /var/log/apache2/zulip_auth_access.log (you may want to change
|
|
LogLevel to "debug" in the apache config file to make this more
|
|
verbose)
|
|
|
|
Here's a summary of how the remote user SSO system works assuming
|
|
you're using HTTP basic auth; this summary should help with
|
|
understanding what's going on as you try to debug:
|
|
|
|
* Since you've configured /etc/zulip/settings.py to only define the
|
|
zproject.backends.ZulipRemoteUserBackend, zproject/settings.py
|
|
configures /accounts/login/sso as HOME_NOT_LOGGED_IN, which makes
|
|
`https://zulip.example.com/` aka the homepage for the main Zulip
|
|
Django app running behind nginx redirect to /accounts/login/sso if
|
|
you're not logged in.
|
|
|
|
* nginx proxies requests to /accounts/login/sso/ to an Apache instance
|
|
listening on localhost:8888 apache via the config in
|
|
/etc/nginx/zulip-include/app.d/external-sso.conf (using the upstream
|
|
localhost:8888 defined in /etc/nginx/zulip-include/upstreams).
|
|
|
|
* The Apache zulip-sso site which you've enabled listens on
|
|
localhost:8888 and presents the htpasswd dialogue; you provide
|
|
correct login information and the request reaches a second Zulip
|
|
Django app instance that is running behind Apache with with
|
|
REMOTE_USER set. That request is served by
|
|
`zerver.views.remote_user_sso`, which just checks the REMOTE_USER
|
|
variable and either logs in (sets a cookie) or registers the new
|
|
user (depending whether they have an account).
|
|
|
|
* After succeeding, that redirects the user back to / on port 443
|
|
(hosted by nginx); the main Zulip Django app sees the cookie and
|
|
proceeds to load the site homepage with them logged in (just as if
|
|
they'd logged in normally via username/password).
|
|
|
|
Again, most issues with this setup tend to be subtle issues with the
|
|
hostname/DNS side of the configuration. Suggestions for how to
|
|
improve this SSO setup documentation are very welcome!
|