Single sign-on

By default, Spacelift uses GitHub as its identity provider. This is rather convenient for organizations who use GitHub teams to manage access to their repositories. Some organizations however prefer a single sign-on approach, where access to resources is centralized. To accommodate this use-case, Spacelift supports single sign-on using SAML 2.0.

Setting up the integration

In order to activate single sign-on on your Spacelift account, please go to the Settings section of your account view. Right now it only contains a single tab - Single sign-on. If SSO is not enabled for your account, all you're going to see is instructions on how to get started and a . The first steps are always taken in your identity provider (GSuite, Okta, Auth0, ActiveDirectory etc).

These URLs will be different for your account

When setting up Spacelift on your identity provider, you may want to add three attribute mappings:

  • FirstName is used to build human-friendly user name;

  • LastName is used to build human-friendly user name;

  • Teams can be used by login and stack access policies to determine the level access to the Spacelift account and/or individual Stacks;

Depending on your identity provider and your use case, your mapping may be different. Especially with regards to Teams, some identity providers (eg. Okta) will support an arbitrary list of memberships similar to GitHub teams out of the box, some will need extra customizations like (eg. GSuite), and some won't. In should always be possible to map Teams to something reasonably generic, like organization, department or job title. This will allow you to write policies that don't need to deal explicitly with individual users.

Some identity providers (eg. Okta) will allow you to provide a custom per-user SAML 2.0 Subject for SAML assertions. You could use this feature to map GitHub usernames to your identity provider users and thus get the exact same experience as when using GitHub as your identity provider.

When setting up SSO without this GitHub mapping, your future logins will appear as new users since Spacelift has no way of mapping those without your assistance. New users will count against your seat quota and you may run out of seats. If you run into this problem, you can contact us and as a courtesy we will flush your login history.

IdP-initiated SSO

While certainly more convenient, IdP-initiated SSO lacks some of the protections awarded by SP-initiated SSO and is thus inherently less safe. Since Spacelift manages some of your most valuable resources, we decided against supporting this feature.

If our server detects an IdP-initiated SSO session, it simply redirects the browser using 303 See other HTTP status code to the endpoint that triggers a regular SP-initiated SSO flow. As a result, you can still access Spacelift by clicking on the link in your IdP catalog, but are not exposed to the vulnerabilities of the IdP-initiated SSO.

Disabling SSO

In order to disable SSO integration for your Spacelift account, or change the IdP provider, please click the Disable button to delete the integration. This change takes effect immediately for new logins, but won't invalidate existing sessions, which will only expire after an hour since they were created. New sessions will be created using the new SSO identity provider or - if none is set up - they will use GitHub by default.

Again, please note that new usernames will occupy new seats, even if they're the same users registered with a different identity provider.