メモ
SAML シングル サインオンを使うには、organization が GitHub Enterprise Cloud を使っている必要があります。 GitHub Enterprise Cloud を無料で試す方法の詳細については、「GitHub Enterprise Cloud の試用版を設定する」を参照してください。
SAML SSO について
シングル サインオン (SSO) により、organization 所有者と Enterprise 所有者は、リポジトリ、issue、pull request などの organization リソースへのアクセス権を制御し、セキュリティで保護することができます。
SAML SSO を構成した場合、組織のメンバーは引き続き GitHub.com で個人アカウントにサインインします。 メンバーが組織内のほとんどのリソースにアクセスすると、 GitHub はメンバーを IdP にリダイレクトして認証します。 認証が成功すると、IdP によってメンバーが GitHubにリダイレクトされます。 詳しくは、「シングル サインオンでの認証について」をご覧ください。
メモ
SAML SSO は、 GitHubの通常のサインイン プロセスに代わるものではありません。 Enterprise Managed Usersを使用しない限り、メンバーは引き続きGitHub.comで個人アカウントにサインインし、各個人アカウントは IdP 内の外部 ID にリンクされます。
次のように特定の方法でパブリック リポジトリにアクセスする場合、IdP 認証は必要ありません。
- リポジトリの概要ページとファイルの内容を GitHub 上で表示する
- リポジトリをフォークする
- リポジトリのクローンなど、Git を使って読み取り操作を実行する
issue、pull request、プロジェクト、リリースの閲覧など、パブリック リポジトリへのその他のアクセスには認証が必要です。
メモ
外部コラボレーターには SSO 認証は必要ありません。 外部コラボレーターの詳細については、「組織の役割」を参照してください。
Organization のオーナーは、個々の Organization に SAML SSO を適用できます。または、Enterprise のオーナーは、Enterprise アカウント内のすべての Organization に SAML SSO を適用できます。 詳細については、「ID とアクセス管理の基礎」および「Enterprise 向けの SAML シングルサインオンを設定する」を参照してください。
Organization で SAML SSO を有効化する前に、IdP を Organization に接続する必要があります。 詳しくは、「アイデンティティプロバイダを Organization に接続する」をご覧ください。
1 つの Organization に対して、SAML SSO は無効化、強制なしの有効化、強制ありの有効化ができます。 Organization に対して SAML SSO を有効にし、Organization のメンバーが IdP での認証に成功した後、SAML SSO 設定を強制できます。 GitHub組織に SAML SSO を適用する方法の詳細については、「組織における SAML シングルサインオンを施行する」を参照してください。
認証を受けて Organization のリソースにアクセスするために、メンバーは定期的に IdP の認証を受ける必要があります。 このログイン間隔は利用しているアイデンティティプロバイダ (IdP) によって指定されますが、一般的には 24 時間です。 このように定期的にログインしなければならないことから、アクセスの長さには制限があり、ユーザがアクセスを続行するには再認証が必要になります。
コマンド ラインで API と Git を使用して組織の保護されたリソースにアクセスするには、メンバーは personal access token キーまたは SSH キーを使用して承認および認証する必要があります。 詳細については、「シングル サインオンに使用する個人用アクセス トークンの認可」および「シングル サインオンに使用する SSH キーの認可」を参照してください。
メンバーが SAML SSO を使用して初めて組織にアクセスする際、GitHub は、組織、GitHub 上のメンバーのアカウント、および IdP 上のメンバーのアカウントを関連付けるレコードを自動的に作成します。 組織またはエンタープライズアカウントのメンバーに関連付けられた SAML ID、アクティブセッション、および承認された資格情報の表示と取り消しが可能です。 詳細については、「組織に対するメンバーの SAML アクセスの表示と管理」および「Enterprise へのユーザの SAML アクセスの表示および管理」を参照してください。
新しいリポジトリを作成するときにメンバーが SAML SSO セッションでサインインする場合、そのリポジトリのデフォルトの可視性はプライベートになります。 それ以外の場合、デフォルトの可視性はパブリックです。 リポジトリの可視性の詳細については、「リポジトリについて」を参照してください。
また、組織のメンバーは、 OAuth appを承認するためにアクティブな SAML セッションを持っている必要があります。 GitHub サポート ポータル に連絡することで、この要件の適用を受けないようにできます。 GitHub では、この要件をオプトアウトすることはお勧めしません。これにより、アカウントの引き継ぎや潜在的なデータ損失のリスクが高くなります。
GitHub は SAML シングル ログアウトをサポートしていません。 アクティブなSAMLセッションを終了させるには、ユーザーは直接SAML IdPでログアウトしなければなりません。
サポートされているSAMLサービス
GitHub は、SAML 2.0 標準を実装する IdP を使用した SAML SSO をサポートします。 詳細については、OASIS の Web サイトの SAML Wiki を参照してください。
GitHub は、SAML に対して次の IdP を正式にサポートし、内部的にテストします。
- Microsoft Active Directory フェデレーション サービス (AD FS)
- Microsoft Entra ID (旧称 Azure AD)
- Okta
- OneLogin
- PingOne
- Shibboleth
一部の IdP では、SCIM を介した GitHub 組織へのアクセスのプロビジョニングがサポートされています。 詳しくは、「組織におけるSCIMについて」をご覧ください。
SCIM のこの実装は、エンタープライズ アカウントまたは マネージド ユーザーを含む組織 では使えません。 エンタープライズで Enterprise Managed Users が有効になっている場合、SCIM の別の実装を使う必要があります。 それ以外の場合、SCIM はエンタープライズレベルでは使えません。 詳しくは、「エンタープライズ マネージド ユーザーユーザーを管理するための SCIM プロビジョニングの構成」をご覧ください。
SAML SSO で Organization にメンバーを追加する
SAML SSO を有効にした後、Organization に新しいメンバーを追加する方法は複数あります。 組織の所有者は、 GitHub または API を使用して、新しいメンバーを手動で招待できます。 詳細については、「組織参加へのユーザーの招待」および「組織のREST APIエンドポイント」を参照してください。
Organization のオーナーからの招待なしで新しいユーザーをプロビジョニングするには、URL https://github.com/orgs/ORGANIZATION/sso/sign_up を使用し、ORGANIZATION を、ご自分の Organization の名前に置き換えます。 たとえば、IdP にアクセスできるすべてのユーザーが IdP のダッシュボードのリンクをクリックして、 GitHub 組織に参加できるように IdP を構成できます。
メモ
https://github.com/orgs/ORGANIZATION/sso/sign_up を使用した新しいユーザーのプロビジョニングは、SAML SSO が organization レベルで構成されている場合にのみサポートされ、SAML SSO が Enterprise アカウント レベルで構成されている場合はサポートされません。 Enterprise アカウント用の SAML SSO の詳細については、「エンタープライズ IAM の SAML について」を参照してください。
IdP が SCIM をサポートしている場合、 GitHub は IdP へのアクセスを許可するときに、自動的にメンバーを組織に招待できます。 SAML IdP で GitHub 組織へのメンバーのアクセス権を削除すると、そのメンバーは GitHub 組織から自動的に削除されます。 詳しくは、「組織におけるSCIMについて」をご覧ください。
ユーザーは、チーム同期を使用して、ID プロバイダーを介して organization メンバーをチームに自動的に追加および削除できます。 詳細については、「チームを ID プロバイダー グループと同期する」を参照してください。
Organization のメンバーが 100,000 人を超える場合、一部の UI エクスペリエンスと API 機能が低下する可能性があります。