Skip to main content

IdP Integration for GitHub Username for Self Hosted

Feature RequestsAccess Control

Context

We are using self-hosted spacelift with a VCS Integration to GitHub Enterprise Server (self-hosted). Unfortunately, GitHub Enterprise is not a supported IdP for Spacelift self-hosted which means we must fall back on Google Workspace for our IdP. Usernames provided by Google Workspace (SAML) are of the format firstname.lastname@company.com while github username’s are assigned as firstname-lastname. This makes it difficult to associate a github user with the corresponding Spacelift user.

Request

I believe the “Slack member ID” integration was meant to help reconcile any differences between IdP-assigned username which may be an email address or other format of identifier with the Slack-assigned ID of the same person. Adding a similar integration for GitHub Username would help us construct Approval Policies based on a user’s GitHub activity.

Workaround
Problem
See description above.
Status: ✅ Completed2 comments

Log in to comment and vote

Comments2

  • Red Pudding

    •

    Jul 16, 2025

    Leveraging GHES as IdP would be crucial for us as well. Using Google Workspace or Okta to manage groups is not as ideal. We hope to leverage GitHub Teams because that ties directly into CODEOWNERS files. Unfortunately, it is not feasible to use the public github.com since we have our enterprise environment but we are losing out on a key feature for managing playbooks.

    By having GHES as an IdP, we can then use the same set of user base to configure policy in Spacelift and access to repositories and CODEOWNERs in GHES. This is available in the public github.com but unavailable for GHES environment due to the lack of this capability.

  • Black Breeze

    •

    May 10, 2025

    👋 Thanks for the suggestion! We’d love to understand a bit more about the job you’re trying to do here.

    Are you aiming to:

    • Automatically align Spacelift approval logic with GitHub ownership rules?

    • Reduce drift between code ownership and who can approve infrastructure changes?

    • Eliminate the need to manually maintain mapping logic inside Rego?

    Today, it’s possible to define a GitHub-to-Spacelift user map directly in your approval policy body, and even automate its refresh using a Stack (e.g., pulling from CODEOWNERS or your GitHub org via API). But we totally get that this might feel brittle or bespoke.

    We’re curious:

    • What breaks down with the current approach?

    • How dynamic is your ownership model?

    • What would “it just works” look like for your team?

    Happy to explore whether this is a missing primitive, or just a doc+example gap we can fix quickly.