Cross-enterprise organization membership: allow org invites to reference an external @org/team
#206522
Unanswered
wallentx
asked this question in
Other Feature Feedback, Questions, & Ideas
Replies: 1 comment
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Product Feedback
💬 Feature/Topic Area
Other
Body
Context
We are collaborating with an external partner that has its own GitHub Enterprise Cloud
account. On our side we created a bespoke organization for the joint work, with teams and
child teams to drive repo access and role assignment, and we want to invite the partner's
people into that org rather than granting access repo by repo.
GitHub Support confirmed there is no supported way to do this across enterprises and
pointed me here.
The problems
Enterprise Managed Users can block it entirely. Per the
documented restrictions,
a managed user "cannot be invited to organizations or repositories outside of the
enterprise, or to other enterprises." If the partner uses EMU, its people can neither join
our org nor be added as outside collaborators. If the host uses EMU, external people must
be provisioned in the host IdP, which a real third party will not be. Either way the only
supported workaround disappears, and there is no way to discover the other side's
configuration short of attempting an invite and watching it fail.
The perverse result: the more rigorously either enterprise governs identity, the less able
it is to collaborate. What remains is partner staff using personal GitHub accounts, which
puts the work outside both enterprises' provisioning and audit and leaves offboarding to
goodwill.
The invite has no concept of the other enterprise. One username or email at a time, no
way to invite a team as a unit, and nothing keeps membership in sync when someone joins or
leaves on their side. Our team structure governs nothing about who arrives.
Double licensing. Each invited member consumes a seat on our enterprise even though
their employer already pays for Enterprise Cloud, which turns "who hosts the repos" into a
budget negotiation instead of a technical decision.
internalvisibility does not help, since it stops at the enterprise boundary, which isexactly the boundary in question.
The ask
Let an organization invite reference an external enterprise's principals:
@partner-org/team(or@partner-org/user) into our org, optionally mapped ontoone of our teams, so their joiners and leavers propagate automatically.
revoke it, removing access for everyone at once.
enterprise's SSO, with actions in both audit logs. This should work for managed user
accounts, since the point is that identity stays owned by the home enterprise.
If only part of this is feasible, the
@org/teaminvite with mutual consent andhome-license retention is what matters most. Team granularity and EMU support are what make
it usable rather than just cheaper.
Without something like this, the alternatives teams reach for are shared machine accounts,
mirrored repos, source drops over email or object storage, or moving the work off GitHub.
All reactions