Single Sign-On (SSO)

Single sign-on (or SSO) allows you to manage your organization’s entire membership via a third-party provider.

Before you get around to actually turning on SSO, you’ll want to keep in mind that once it’s activated, all existing users will need to link their account before they are able to continue using Sentry. Because of that we recommend coordinating with your team during off-peak hours. That said, it’s super quick to link accounts, so we don’t consider it a true hurdle.

With that out of the way, head on over to your organization home. You’ll see an “Auth” link in the sidebar if you have access to SSO. Start by hitting that, and then continue to the “Configure” link next to provider you wish to configure.

Additionally we’ll automatically send each pre-existing member an email with instructions on linking their account. This will happen automatically once SSO is successfully configured. Even if they don't click the link, the next time they try to hit any page within the organization we’ll require them to link their account (with the same auth flow you just went through).

Every member who creates a new account via SSO will be given global organization access with a member role. This means that they can access events from any team, but they won’t be able to create new projects or administer current ones.

Our SSO implementation prioritizes security. We aggressively monitor linked accounts and will disable them if there's any reasonable sign that the account’s access may have been revoked. Generally this will be transparent to you, but if the provider is functioning in an unexpected way you may experience more frequent re-authorization requests.

Sessions last for Django's default session length, which is two weeks. For individual organizations with single sign-on, we expire organization access after one day (20 hours).

Enabling the Google integration will ask you to authenticate against a Google Apps account. Once done, membership will be restricted to only members of the given Apps domain (i.e. sentry.io).

The GitHub integration will authenticate against all organizations, and once complete prompt you for the organization which you wish to restrict access by.

Sentry provides SAML2 based authentication which may be configured manually using the generic SAML2 provider, or a specific provider listed below that provides defaults specific to that identity provider:

Sentry supports the following SAML services:

  • Identity and Service Provider initiated SSO
  • Identity Provider initiated SLO (Single Logout)

Sentry’s Assertion Consumer Service uses the HTTP-POST bindings.

Sentry’s SAML endpoints are as follows, where the [organization_slug] is substituted for your organization slug:

ACS:

https://sentry.io/saml/acs/[organization_slug]/

SLS:

https://sentry.io/saml/sls/[organization_slug]/

Metadata:

https://sentry.io/saml/metadata/[organization_slug]/

In your Auth0 dashboard, locate the Sentry app under the SSO Integrations page and add it to your organization.

As part of the Auth0 SSO configuration, you must provide the Auth0 Identity Provider metadata to Sentry. This URL is available under the Tutorial tab of the Sentry SSO integration.

You may refer to the Auth0 documentation for more detailed setup instructions.

In your Azure AD dashboard, locate the Sentry app under Enterprise Applications and add it to your organization.

You may refer to our documentation for more detailed setup instructions.

In your Okta admin dashboard, locate the Sentry app in the Okta Application Network and add it to your organization.

As part of the Okta SSO configuration, you must provide the Okta Identity Provider metadata to Sentry. This URL can be located under the Sign-On Methods SAML2 settings panel, look for the ‘Identity Provider metadata’ link which can may right click and copy link address.

You may refer to our documentation for more detailed setup instructions.

In your OneLogin dashboard, locate the Sentry app in the app catalog and add it to your organization.

As part of OneLogin SSO configuration, you must to provide the OneLogin identity provider issuer URL to Sentry. This URL is specific to your OneLogin account and can be found under the "SSO" tab on the Sentry OneLogin application configuration page.

You may refer to the OneLogin documentation for more detailed setup instructions.

In your Rippling admin dashboard, locate the Sentry app in the list of suggested apps and select it.

When prompted with the Rippling Metadata URL, copy this into the Sentry Rippling provider configuration. You will have to complete the Rippling application configuration before completing the Sentry provider configuration.

In your Jumploud Admin portal:

  1. Navigate to User Authentication > SSO.
  2. Add a new SSO application and search for Sentry.
  3. Click "Configure".
  4. Under the SSO menu, update the SP Entity ID and ACS URLs for your tenant. They should be in the format as described here.
  5. Click "save".

Be sure that you have assigned yourself to the Sentry app in Jumpcloud before attempting these next steps.

  1. In sentry.io, navigate to Settings > Auth in your organization.
  2. Click "Configure" on the Jumpcloud provider.
  3. Go to the "XML" within the register page.
  4. Download your Jumpcloud metadata under the "SSO" tab in your Jumpcloud Sentry SSO app by clicking "Export Metadata".
  5. Paste your XML metadata into the text field and click "Parse Metadata".
  6. On the "Map Identity Provider" page, fill in 'uniqueID', 'email', 'firstname', and 'lastname' if you have left your Jumpcloud attributes as the defaults for the Sentry app.

Now, Sentry should be configured for Jumpcloud SSO.

For other SAML2 SSO providers not listed above, Sentry provides generic connectors for SAML2 based authentication, which may be configured manually.

System for Cross-Domain Identity Management (SCIM) is a standard implemented by Identity Providers and applications to facilitate automated identity management. Sentry supports a subset of the specification for provisioning organization members and teams. See the relevant documentation for your use case:

  • Okta SCIM Setup
  • Azure AD SCIM Setup
  • If your Provider is not listed here, SCIM may be supported as it is a common standard. If you are having issues please contact our support team.
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").