Skip to main content

Enterprise Managed Users について

ID プロバイダー (IdP) から GitHub 上のエンタープライズ メンバーの ID とアクセスを一元管理することができます。

Enterprise Managed Users について

Enterprise Managed Users を使用すると、外部 ID 管理システム (IdP) から GitHub.com 上のユーザーのライフサイクルと認証を管理できます。 IdP の既存の ID とグループ メンバーシップを持つユーザーに、GitHub Enterprise Cloud へのアクセス権を提供できます。 IdP は、GitHub.com で Enterprise にアクセスできる新しいユーザー アカウントをプロビジョニングします。 IdP からユーザー アカウントのユーザー名、プロファイル データ、チーム メンバーシップ、リポジトリへのアクセスを制御します。

IdP では、各 マネージド ユーザー アカウント に、メンバー、エンタープライズ所有者、ゲスト コラボレーターなどのロールを付与できます。 マネージド ユーザー アカウントは、Enterprise 内の 組織を所有でき、他のマネージド ユーザー アカウントを 組織とその中の Team に追加できます。 詳細については、「Enterprise におけるロール」および「Organizationについて」を参照してください。

企業で OIDC SSO を使うと、GitHub は IdP の条件付きアクセス ポリシー (CAP) の IP 条件を自動的に使って、メンバーが IP アドレスを変更したとき、および personal access token またはユーザーアカウントに関連付けられた SSH キーを使用した認証のたびに、GitHub での操作を検証します。 詳しくは、「IdP の条件付きアクセス ポリシーのサポートについて」を参照してください。

マネージド ユーザー アカウントに、エンタープライズ内のリポジトリへのアクセス権と、そこに投稿する機能を付与できますが、マネージド ユーザー アカウントでは、パブリック コンテンツを作成したり、残りの GitHub で他のユーザー、組織、エンタープライズと共同作業を行ったりすることはできません。 詳しい情報については、「マネージド ユーザー アカウントの機能と制限」を参照してください。

Enterprise のマネージド ユーザー アカウントのユーザー名とそのプロファイル情報 (表示名やメール アドレスなど) は、IdP によって設定され、ユーザー自身が変更することはできません。 詳細については、「ユーザー名とプロファイル情報」を参照してください。

エンタープライズ所有者は、GitHub に対するマネージド ユーザー アカウントのすべてのアクションを監査できます。 詳しくは、「エンタープライズの監査ログ イベント」を参照してください。

Enterprise Managed Users を使用するには、Enterprise Managed Users を有効にした別の種類の エンタープライズアカウントが必要です。 このアカウントの作成について詳しくは、「Enterprise Managed Users の概要」をご覧ください。

注: GitHub Enterprise Cloud を使った ID とアクセスの管理には複数のオプションがあるので、Enterprise Managed Users はすべてのお客様にとって最適なソリューションではありません。 Enterprise Managed Users がお客様の企業に適しているかどうかについては、「GitHub Enterprise Cloud の Enterprise の種類の選択」 および 「マネージド ユーザー アカウントの機能と制限」を参照してください。

認証とユーザーのプロビジョニングについて

Enterprise Managed Users を使用すると、IdP は GitHub.com のユーザー アカウントを作成して更新できます。 GitHub.com でエンタープライズ リソースにアクセスするには、IdP でユーザーを認証する必要があります。 GitHub Enterprise Cloud は、ユーザー アカウントに対応する外部 ID の記録を IdP 上で管理します。

GitHub は、ID 管理システムの一部の開発者と提携し、Enterprise Managed Users との "paved-path" 統合を提供します。 構成を簡略化して完全なサポートを確保するため、GitHubは認証とプロビジョニングの両方に 1 つのパートナー IdP を使用することをお勧めします。これらの IdP は、主に SAML を使用した認証を提供します。 Microsoft Entra ID (旧称 Azure AD) には、認証用の OIDC も用意されています。 IdP アプリケーションは、システムを使用してクロスド メイン ID 管理 (SCIM) を使用してユーザーをプロビジョニングします。

パートナー IdPSAMLOIDCSCIM
Entra ID
Okta
PingFederate

その他の IdP は、認証のために SAML 2.0 仕様に準拠している必要があります。 GitHub の統合ガイドラインに準拠する IdP を使用してプロビジョニングを構成できます。 IdP は SCIM 2.0 仕様に準拠し、GitHub の REST API と通信する必要があります。 たとえば、IdP は、GitHub がテストしていない商用 ID 管理システムや、会社が構築するカスタム ID システムなどです。

メモ: GitHubのパブリック SCIM スキーマを使用したユーザーにプロビジョニングのサポートはパブリック ベータ版であり、変更される場合があります。

認証とプロビジョニングの詳細については、次の記事を参照してください。

認証とプロビジョニングの両方にパートナー IdP のアプリケーションを使用しない場合、SAML を使用して認証を構成し、GitHubの REST API を使用してユーザーをプロビジョニングできます。 詳細については「REST API を使用した SCIM でユーザーとグループのプロビジョニング」を参照し、IdP のドキュメント、サポート チーム、その他のリソースを参照してください。

一部のお客様は、パートナー IdP のアプリケーションを認証のみに使用し、プロビジョニングに別の ID 管理システムと組み合わせて使用​​したときに成功したことが報告されています。 たとえば、SAML SSO に Okta を使用し、ユーザー プロビジョニングにカスタム SCIM の実装を使用できます。 GitHubは、認証とプロビジョニングのためにパートナー IdP の混在と一致を明示的にサポートしていません。また、他の IdP と組み合わせてパートナー IdP をテストすることもなく、すべての ID 管理システムをテストしていません。

Enterprise Managed Users の概要

お客様の開発者が GitHub Enterprise Cloud と Enterprise Managed Users を使用できるようにするには、お客様が一連の構成手順を実行する必要があります。

  1. Enterprise Managed Users を使用するには、Enterprise Managed Users を有効にした別の種類の エンタープライズアカウントが必要です。 Enterprise Managed Users を試用するか、既存の エンタープライズから移行するためのオプションについて検討するには、GitHub の営業チームにお問い合わせください。

    GitHub セールス チームの担当者が、新しい マネージド ユーザーを含む Enterprise を作成するために協力します。 エンタープライズを設定するユーザーのメール アドレスと、エンタープライズメンバーのユーザー名のサフィックスとして使用されるショートコードを指定する必要があります。 短いコードは、エンタープライズに固有の 3 から 8 文字の英数字文字列にする必要があります。特殊文字を含めることはできません。 詳細については、「ユーザー名とプロファイル情報」を参照してください。

  2. エンタープライズを作成すると、GitHub からメールが届き、エンタープライズのセットアップ ユーザーのパスワードを選択するよう求められます。このユーザーは、エンタープライズの最初の所有者になります。 パスワードを設定し、ユーザーの回復コードを保存する際には、シークレットまたはプライベートブラウジングウィンドウを使用します。 セットアップ ユーザーは、エンタープライズのシングル サインオンと SCIM プロビジョニング統合を構成するためにのみ使用されます。 SSO 復旧コードを使用しない限り、SSO が構成されると、エンタープライズまたは組織の設定へのアクセスは許可されなくなります。

    セットアップ ユーザーのユーザー名は、エンタープライズのショートコードにサフィックス _admin 例えば、fabrikam_admin が付きます。 後でセットアップ ユーザーとしてサインインする必要がある場合は、任意のログイン ページでユーザー名とパスワードを入力できます。 便宜上、ログイン ページへのリンクも SSO ページに表示されます。

    セットアップ ユーザーのパスワードをリセットする必要がある場合、GitHub Support ポータル から GitHub Support に問い合わせます。

  3. セットアップ ユーザーとしたログインしたら、2 要素認証を有効にすることをお勧めします。 セットアップ ユーザーのパスワードと 2 要素資格情報を使用して sudo モードに入ることもできます。これは、機密性の高いアクションを実行するために必要です。 詳細については、「2 要素認証を設定する」および「Sudo モード」を参照してください。

  4. まず、メンバーが認証する方法を構成します。 IdP として Entra ID を使用している場合は、OpenID Connect (OIDC) と Security Assertion Markup Language (SAML) のいずれかを選択できます。 条件付きアクセス ポリシー (CAP) のサポートを含む OIDC をお勧めします。 マネージド ユーザー アカウント が 1 つのテナントからプロビジョニングされた複数のエンタープライズが必要な場合は、最初のエンタープライズ以降、それぞれに SAML を使用する必要があります。 Okta や PingFederate などの別の IdP を使っている場合は、メンバーの認証に SAML を使うことができます。

    まず、選択した認証方法のガイドを参照してください。

  5. SSO を構成したら、SCIM のプロビジョニングを構成できます。 SCIM は、IdP を使って GitHub.com にマネージド ユーザー アカウントを作成する方法です。 SCIM のプロビジョニングについて詳しくは、「エンタープライズ マネージド ユーザーの SCIM プロビジョニングの構成」を参照してください。

  6. 認証とプロビジョニングが構成されたら、IdP グループを Team と同期することで、マネージド ユーザー アカウントの 組織メンバーシップの管理を開始できます。 詳しくは、「ID プロバイダー グループを使用したチーム メンバーシップの管理」を参照してください。

エンタープライズのメンバーが 1 つのワークステーションを使って、マネージド ユーザー アカウントと個人アカウントの両方から、GitHub.com のリポジトリに投稿する必要がある場合は、サポートを提供できます。 詳しくは、「GitHub.com で複数のユーザー アカウントを持つ開発者をサポートする」をご覧ください。

組織メンバーシップの管理について

組織メンバーシップは、手動で管理することも、IdP グループを使用して自動的に更新することもできます。 IdP を使用して 組織メンバーシップを管理するには、メンバーを IdP グループに追加し、IdP グループを 組織内の Team に接続する必要があります。 組織およびチームのメンバーシップを自動的に管理する方法について詳しくは、「ID プロバイダー グループを使用したチーム メンバーシップの管理」を参照してください。

エンタープライズによって所有されている 組織にメンバーを追加する方法によって、組織からメンバーを削除する方法が決定されます。

  • メンバーを手動で 組織に追加した場合、手動で削除する必要があります。 IdP 上の GitHub Enterprise Managed User アプリケーションからユーザーの割り当て解除を行うと、ユーザーは停止されますが、組織から削除されません。
  • 組織内の 1 つ以上の Team にマップされた IdP グループに追加されたために、ユーザーが 組織のメンバーになった場合、組織に関連付けられている "すべて" のマップされた IdP グループからユーザーを削除すると、ユーザーは 組織から削除されます。__

メンバーが 組織に追加された方法を確認するには、メンバー リストを種類でフィルター処理できます。 詳しくは、「Enterprise の人を表示する」を参照してください。

マネージド ユーザー アカウント として認証を行う

マネージド ユーザー アカウントは、自分の IdP を介して認証を行う必要があります。 マネージド ユーザー アカウント 認証の方法は、SAML 認証と OIDC 認証のどちらを構成するかによって異なります。

企業が SAML 認証用に構成されている場合、マネージド ユーザー アカウント は IdP アプリケーション ポータルにアクセスして自分の企業にアクセスできます。 企業が OIDC 認証用に構成されている場合、マネージド ユーザー アカウント は 、GitHub.com のログイン ページを使用して自分の企業にアクセスできます。 IdP によって開始される認証は現在、OIDC 向けにはサポートされていません。 どちらの構成でも、マネージド ユーザー アカウント は、GitHub.com 上の組織または企業のページから直接認証を開始できます。

既定では、認証されていないユーザーが Enterprise Managed Users を使用する Enterprise にアクセスしようとすると、GitHub によって 404 エラーが表示されます。 エンタープライズ所有者は、必要に応じて、404 の代わりにシングル サインオン (SSO) への自動リダイレクトを有効にすることができます。 詳しくは、「Enterprise でセキュリティ設定のポリシーを適用する」を参照してください。

SAML 構成エラーまたは ID プロバイダー (IdP) の問題によって SAML SSO を使用できない場合は、復旧コードを使用してエンタープライズにアクセスできます。 詳細については、「Enterprise のリカバリ コードの管理」を参照してください。

GitHub.com

を介してマネージド ユーザー アカウントとして認証を行う

  1. https://github.com/login に移動します。
  2. [Username or email address] テキスト ボックスに、アンダースコアとショートコードを含むユーザー名を入力します。 フォームでユーザー名が認識されると、フォームは更新されます。 このフォームでパスワードを入力する必要はありません。
  3. ID プロバイダーにサインインするには、 [Sign in with your identity provider] (ID プロバイダーでサインインする) をクリックします。

ユーザー名とプロファイル情報

GitHub Enterprise Cloud は、IdP から提供された識別子を正規化することにより、各自のユーザー名を自動的に作成します。 詳しくは、「外部認証のユーザー名に関する考慮事項」を参照してください。

マネージド ユーザー アカウントのプロファイル名とメール アドレスは IdP によって提供されます。 マネージド ユーザー アカウントでは、GitHub 上のプロファイル名またはメール アドレスを変更できません。IdP が提供できるメール アドレスは 1 つのみです。 IdP のユーザーに関連付けられているメール アドレスを変更すると、古いメール アドレスに関連付けられている投稿履歴からユーザーのリンクが解除されます。 

IdP から提供された識別子の一意の部分が正規化中に削除されると、ユーザーをプロビジョニングするときに競合が発生する場合があります。 ユーザー名の競合が原因でユーザーをプロビジョニングできない場合は、IdP によって提供されるユーザー名を変更する必要があります。 詳しくは、「外部認証のユーザー名に関する考慮事項」を参照してください。

注: 各ユーザー名を作成するときに GitHub によって IdP から提供された正規化された識別子にアンダースコアと短いコードが追加されるため、各 マネージド ユーザーを含む Enterprise 内でのみ競合が発生する可能性があります。 マネージド ユーザー アカウント では、IdP の識別子とメール アドレスを、そのエンタープライズ外の GitHub.com 上の他のユーザー アカウントと共有することができます。

GitHub.com で複数のユーザー アカウントを持つ開発者をサポートする

Team のユーザーは、マネージド ユーザーを含む Enterprise の外部にある GitHub.com のリソースに投稿することが必要になる場合があります。 たとえば、会社のオープンソース プロジェクト用に別のエンタープライズを保持したい場合があります。 マネージド ユーザー アカウントではパブリック リソースに投稿できないため、ユーザーはこの作業のために個別の個人アカウントを維持する必要があります。

1 つのワークステーションを使用して GitHub.com で 2 つのユーザー アカウントから投稿する必要があるユーザーは、Git を設定してプロセスを簡略化できます。 詳しくは、「複数のアカウントの管理」を参照してください。

個人アカウントと 1 つ以上の マネージド ユーザー アカウント など、GitHub.com のアカウントを定期的に切り替える必要があるユーザーがチームにいる場合は、複数のアカウントにサインインし、再認証が常に不要ですばやく切り替えることができます。 詳しくは、「アカウント間の切り替え」を参照してください。