FlakeHub now supports GitHub Enterprise Managed Users

Today, we have some good news for GitHub Enterprise users: FlakeHub now supports authentication via GitHub Enterprise Managed Users (EMU). If your org’s developers sign into GitHub with accounts that your identity provider (IdP) creates and controls:

• They can also sign into FlakeHub with those same accounts
• The policies you already enforce on GitHub apply without you needing to configure anything a second time

In turn, this means that the identity controls your security team already runs on GitHub now extend to your private flakes and your binary cache: the same sign-on, the same provisioning, and the same access rules, with nothing extra to administer. This post lays out what your org stands to gain.

What’s changing

In an ordinary GitHub organization, every developer shows up with a personal GitHub account that they own as an individual. While an enterprise can invite that account in and revoke the invitation later, the account itself never stops belonging to the individual rather than to the org.

Enterprise Managed Users inverts that and makes your enterprise IdP the source of truth for who exists in the system from the standpoint of your org. GitHub has optimized integrations with Microsoft Entra ID, Okta, and PingFederate, and supports any IdP that implements Security Assertion Markup Language (SAML) 2.0 and System for Cross-domain Identity Management (SCIM) 2.0.

What happens is that these IdPs are empowered to create, name, and suspend accounts. Managed users can’t change their own username or email, and they can’t create public content or collaborate outside your org. While ordinary organizations can require two-factor authentication and remove members, they can’t do much more than that. With EMU, however, your enterprise decides things like whether the account exists, which authentication factors are required, and how long a session lasts, and when someone leaves, the identity leaves with them rather than living on as a personal account that you’ve removed from the org.

If your GitHub accounts are managed this way, three things now carry through to FlakeHub without any extra configuration or management:

• Single sign-on (SSO)
• SCIM provisioning
• Conditional Access Policy (CAP)

Single sign-on

With GitHub EMU, your developers authenticate against your IdP—Okta, Entra, and so on—rather than against GitHub. Your IdP applies whatever you enforce there to log into GitHub, be it multi-factor authentication, hardware keys, session lifetimes, step-up authentication, or something else. That authentication barrier in turn becomes the authentication barrier for FlakeHub.

The practical effect is that FlakeHub doesn’t introduce any new credentials into your environment, so there’s no separate FlakeHub password to issue, no separate password policy to stay aligned with, and no forgotten accounts who still have access in principle.

SCIM provisioning

SCIM is the protocol that IdPs use to push user lifecycle events to GitHub. Someone joins a team and the account appears; someone changes groups and their access changes with it; someone leaves and the account is suspended. Offboarding is where this event-driven logic matters most. You need to strenuously avoid situations in which, for example, you revoke a departing developer’s access but their access still lingers for weeks or months without you even realizing it.

With support for EMU, that revocation reaches FlakeHub too. When SCIM deprovisions a managed account, that account can no longer authenticate to GitHub, and so can no longer sign in to FlakeHub. Any FlakeHub web session that’s already open expires at the earlier of the exp claim on the token your IdP issued and 15 minutes, and with it that person’s access to your private flakes and Nix binary cache slices.

On the flip side, when a user joins your organization, getting them onto FlakeHub is short work. Your IdP group membership gets them a GitHub account they can sign in to FlakeHub with, but it doesn’t add them to your FlakeHub organization, since FlakeHub doesn’t provision members or seats from SCIM. Once your organization is on a paid plan with a seat for them, an admin adds their GitHub account as a member and they’re off to the races on day one.

Conditional Access Policy

When your enterprise uses OpenID Connect (OIDC) SSO with EMU (which GitHub supports with Microsoft Entra ID) GitHub validates access against your IdP’s CAP whenever a developer authenticates. GitHub applies the IP address restrictions you’ve already written to your developers’ GitHub sessions—requests from your enterprise network only, this set of countries but not that one—and re-validates them on each authentication with a personal access token or SSH key, not just at browser sign-in. This has a few implications:

• GitHub enforces your IdP’s IP restrictions but doesn’t enforce device compliance conditions
• Multi-factor policies apply at the point of sign-in to your IdP rather than on every request
• FlakeHub itself doesn’t re-evaluate your CAP on each request to a private flake or to FlakeHub Cache

CAP support requires OIDC SSO specifically, which, take note, GitHub currently offers only for Microsoft Entra ID. If your enterprise is on SAML, SSO and SCIM provisioning still work as described above, but GitHub doesn’t evaluate your conditional access policies. For more information, see GitHub’s documentation on what migrating from SAML to OIDC involves.

Getting started

GitHub Enterprise Managed Users support for FlakeHub works for any organization on GitHub Enterprise Cloud with EMU enabled. To get set up, you need to connect your FlakeHub organization to your enterprise. You can do that by reaching out to us at sales@determinate.systems and we can walk through your IdP configuration and get you up and running. If you’re coming from Entra or Okta, we have onboarding guides for both.

Once your organization is connected, the experience for developers is pretty straightforward. If you’re a developer using Determinate Nix, you can now log in to FlakeHub using Determinate Nixd:

determinate-nixd auth login

This opens FlakeHub’s sign-in page in your browser. Choose GitHub, and because your account is an enterprise managed account, GitHub redirects you to your IdP rather than asking for a GitHub password. At that point, do whatever your IdP requires—a multi-factor prompt, a hardware key, and so on—and you’ll be sent back to FlakeHub as a properly authenticated user. There, you can generate an authentication token and paste it into your terminal, where Determinate Nixd handles the rest.

To confirm that it worked:

determinate-nixd status

You should see something like this:

Logged in: true
Auth mechanism: static-token
FlakeHub user name: ...

From here, operations like nix build and nix develop can fetch from your organization’s private flakes and FlakeHub Cache slices using that identity.

If you’ve been evaluating FlakeHub and GitHub identity governance has been a blocker, now is a great time to take another look.