SAML2 authentication - Just in Time Provisioning not working

I have set up a new Sentry 10 server using the getsentry/onpremise Docker setup (using an external, non-dockerized Postgres server). There is currently one account, the super-user account that was configured by the installation script (

I was able to configure SAML2 authentication against our Shibboleth identity provider. When I log in through my IdP, an account is not provisioned for me; instead, I am logged in as the admin user. There is only one user in the auth_user table in the database, the super-user.

This gist contains the log from the web container during the login attempt (showing that it logged me in as the super-user), and the SAML response returned by my IdP to Sentry.

The Attribute Mappings configure in Sentry match those in the SAML response:
IdP User ID -> urn:oid:0.9.2342.19200300.100.1.1 (FriendlyName=uid)
User Email -> urn:oid:0.9.2342.19200300.100.1.3 (FriendlyName=mail)
First Name -> urn:oid: (FriendlyName=givenName)
Last Name -> urn:oid: (FriendlyName=sn)

Require SSO is checked, and Default Role is set to Member.

Any advice or pointers is appreciated.

I tried blowing away everything and re-creating the containers; the issue still persists.

I’ve also tried inviting myself using my email address. I receive the email; clicking the link takes me to a page telling me that I “may create an account by authenticating with the organizations [sic] SSO provider”. Clicking the Join with SAML2 button takes my to our IdP login; after logging in, I’m logged into Sentry as the super-user.

I’ve also tried wiping out the v10 containers and installing 9.1.2 with the “git+” in requirements.txt. It throws an error when trying to save the SAML2 config:

web_1        | 2020-06-03T18:28:22.373078807Z Traceback (most recent call last):
web_1        | 2020-06-03T18:28:22.373109624Z   File "/usr/local/lib/python2.7/site-packages/django/core/handlers/", line 112, in get_response
web_1        | 2020-06-03T18:28:22.373113325Z     response = wrapped_callback(request, *callback_args, **callback_kwargs)
web_1        | 2020-06-03T18:28:22.373115900Z   File "/usr/local/lib/python2.7/site-packages/django/views/generic/", line 69, in view
web_1        | 2020-06-03T18:28:22.373118279Z     return self.dispatch(request, *args, **kwargs)
web_1        | 2020-06-03T18:28:22.373120630Z   File "/usr/local/lib/python2.7/site-packages/django/views/decorators/", line 57, in wrapped_view
web_1        | 2020-06-03T18:28:22.373123051Z     return view_func(*args, **kwargs)
web_1        | 2020-06-03T18:28:22.373125171Z   File "/usr/local/lib/python2.7/site-packages/sentry/web/frontend/", line 225, in dispatch
web_1        | 2020-06-03T18:28:22.373127322Z     return self.handle(request, *args, **kwargs)
web_1        | 2020-06-03T18:28:22.373129322Z   File "/usr/local/lib/python2.7/site-packages/django/db/", line 371, in inner
web_1        | 2020-06-03T18:28:22.373131473Z     return func(*args, **kwargs)
web_1        | 2020-06-03T18:28:22.373133526Z   File "/usr/local/lib/python2.7/site-packages/sentry/web/frontend/", line 212, in handle
web_1        | 2020-06-03T18:28:22.373135749Z     return helper.current_step()
web_1        | 2020-06-03T18:28:22.373137684Z   File "/usr/local/lib/python2.7/site-packages/sentry/auth/", line 630, in current_step
web_1        | 2020-06-03T18:28:22.373139808Z     helper=self,
web_1        | 2020-06-03T18:28:22.373141819Z   File "/usr/local/lib/python2.7/site-packages/django/views/decorators/", line 57, in wrapped_view
web_1        | 2020-06-03T18:28:22.373143978Z     return view_func(*args, **kwargs)
web_1        | 2020-06-03T18:28:22.373145941Z   File "/usr/local/lib/python2.7/site-packages/sentry/web/frontend/", line 225, in dispatch
web_1        | 2020-06-03T18:28:22.373148048Z     return self.handle(request, *args, **kwargs)
web_1        | 2020-06-03T18:28:22.373150015Z   File "/usr/local/lib/python2.7/site-packages/sentry_auth_saml2/generic/", line 70, in handle
web_1        | 2020-06-03T18:28:22.373152125Z     return helper.next_step()
web_1        | 2020-06-03T18:28:22.373154164Z   File "/usr/local/lib/python2.7/site-packages/sentry/auth/", line 638, in next_step
web_1        | 2020-06-03T18:28:22.373156292Z     return self.current_step()
web_1        | 2020-06-03T18:28:22.373158196Z   File "/usr/local/lib/python2.7/site-packages/sentry/auth/", line 630, in current_step
web_1        | 2020-06-03T18:28:22.373160308Z     helper=self,
web_1        | 2020-06-03T18:28:22.373162221Z   File "/usr/local/lib/python2.7/site-packages/sentry/auth/providers/", line 84, in dispatch
web_1        | 2020-06-03T18:28:22.373164317Z     auth = build_auth(request, saml_config)
web_1        | 2020-06-03T18:28:22.373166260Z   File "/usr/local/lib/python2.7/site-packages/sentry/auth/providers/", line 393, in build_auth
web_1        | 2020-06-03T18:28:22.373168402Z     return OneLogin_Saml2_Auth(saml_request, saml_config)
web_1        | 2020-06-03T18:28:22.373179225Z   File "/usr/local/lib/python2.7/site-packages/onelogin/saml2/", line 54, in __init__
web_1        | 2020-06-03T18:28:22.373181548Z     self.__settings = OneLogin_Saml2_Settings(old_settings, custom_base_path)
web_1        | 2020-06-03T18:28:22.373183603Z   File "/usr/local/lib/python2.7/site-packages/onelogin/saml2/", line 114, in __init__
web_1        | 2020-06-03T18:28:22.373185700Z     ','.join(self.__errors)
web_1        | 2020-06-03T18:28:22.373187672Z OneLogin_Saml2_Error: Invalid dict settings: sp_acs_url_invalid,sp_sls_url_invalid
web_1        | 2020-06-03T18:28:22.373189786Z 18:28:22 [ERROR] django.request: Internal Server Error: /organizations/sentry/auth/configure/ (status_code=500 request=<WSGIRequest: POST u'/organizations/sentry/auth/configure/'>)
web_1        | 2020-06-03T18:28:22.439113710Z - - [03/Jun/2020:18:28:22 +0000] "POST /organizations/sentry/auth/configure/ HTTP/1.1" 500 6669 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:77.0) Gecko/20100101 Firefox/77.0"

OK, figured this out: I was logged in as the superuser ( when setting up SAML2. Even though I logged in as myself (grahamb) when logging into the IdP when configuring SSO, it was associating that login with the superuser account. If I log into the IdP with another user after SSO is set up, it provisions a user with the proper email address.

This seems like a bug to me; at the very least, it should be documented.