We've recently updated the navigation
You can find APIs and Integrations in their own sections in the horizontal menu bar at the top of the page.
Single Sign-On Support
You can use a Single Sign-On (SSO) provider to protect access to your organization's data in Buildkite. Buildkite supports many different SSO providers, and you can configure multiple SSO providers for a single Buildkite organization.
SSO is available to customers on the Buildkite Team, Business, and Enterprise plans.
Buildkite supports the following SSO providers:
- Google Workspace
- Google Workspace (SAML)
- Azure Active Directory
- Custom SAML
Many of the SSO providers can be configured by an organization admin using Organisation Settings → SSO Settings:
You can also configure SSO manually using the GraphQL API.
Once configured, all access to organization data requires signing into your SSO provider:
If you need to edit your SSO settings, temporarily stop logins using SSO, or want to delete your SSO provider, you'll first need to disable it.
There are two ways to disable a provider:
- Using the 'Disable' button in your SSO provider Settings, or
- Using the GraphQL API
If you have switched off all of your SSO providers, users will be required to log in using a username and password. If users don't have a password, and need access while SSO is switched off, they can perform a 'Forgotten Password' reset.
If you are the administrator of an organization within Buildkite with an existing SSO provider set up, and you want to switch to a different SSO provider, these are the steps you need to take:
- Add a new SSO provider, verify it, and allow login from both SSO providers. The users in your organization can continue to sign in and use the same user accounts within Buildkite as long as the emails stay the same.
- Disable and remove the SSO provider you no longer need. If the user credentials (email) stay the same, this is all you need to migrate from one SSO provider to another.
If you are also changing the email provider, make sure that Buildkite users in your organization sign in to their existing accounts when performing single sign-on through the new provider to prevent your organization being billed twice for the same users.
If you'd like to have some help with the migration, contact firstname.lastname@example.org.
Yes, team maintainers can select whether a user is 'required' to use SSO or whether it is 'optional'. This setting can be found in the team settings.
Yes, we do.
You will need to manually remove them from your Buildkite organization. This will not affect access to the user's personal account or any other organizations they are a member of.
Yes, as an admin you need to add and verify a new SSO provider. Next, you need to allow login from both SSO providers in the Organization settings. As long as the sign-in emails stay the same, the users in your organization can continue to sign in and use the same user accounts within Buildkite.
Yes, by adding multiple SSO providers. You can enable as many different identity providers for your organization as you need.
No, SSO must be verified before being enabled, and can easily be switched off if required. Once enabled, users will see a new "SSO" badge on the organization and will be required to authorise with your SSO provider to access organization data.
No, all of your builds, agents, and pipelines will continue to run as normal.
No, enabling SSO will not affect how much you are billed. However, whenever a new user signs in to Buildkite using SSO, they will be added to your organization as if you had invited them.
Yes, if you are able to associate your provider's groups with your Buildkite team UUIDs, you can adjust the SAML assertion to send 'teams' as an additional SAML User Attribute.
No, SSO providers are setup using a unique identifier and are unaffected when a Buildkite organization is renamed.
In short, yes, you can. However, merging Buildkite organizations that already have SSO providers might be a tricky scenario, and it's highly recommended that you contact email@example.com for help or guidance before you attempt such migration.
Why am I being asked for my password in the "Authorization Required" screen when signing in using SSO?
Signing in to your Buildkite organization requires authentication and authorization with both Buildkite and your SSO provider. Authentication determines if you are who you claim to be. Authorization determines if you have the correct permissions within the Buildkite organization you're trying to access.
Both authentication and authorization are necessary because SSO using one Buildkite organization shouldn't provide access to your other Buildkite organizations. Confirming your password is Buildkite's way to ensure that you are who you say you are. Once you've authenticated with Buildkite, it determines which organizations your account is authorized to access.
I'm already a member of a Buildkite organization. Should I create a new Buildkite user account if I want to work within a different organization (pet project, open source work, etc.)?
Some people choose to have multiple user accounts, one per Buildkite organization. It's fine to do this, but it can be slightly inconvenient as such an approach does not provide easy tools for switching between accounts. You will need to use different browsers or log in and out quite often.
It's recommended to have a single Buildkite user account and join multiple organizations when required.