SSO を使用する認証について
シングル サインオン (SSO) により、organization 所有者と Enterprise 所有者は、リポジトリ、issue、pull request などの organization リソースへのアクセス権を制御し、セキュリティで保護することができます。Organization の所有者は、GitHub 上のユーザーの個人用アカウントを、SSO を使う organization に参加するよう招待できます。これにより、ユーザーは organization にコントリビュートし、GitHub での既存の ID とコントリビューションを保持することができます。
リポジトリ、プロジェクト、パッケージなど、Enterprise 内の SSO で保護された internal リソースにアクセスするには、Enterprise 内の organization に対する SSO セッションが必要です。 これにより、ユーザーが各 organization に参加しなくても、Enterprise 内の organization 間でコードと作業を共有できます。
マネージド ユーザーを含む Enterprise のメンバーである場合は、プロビジョニングされ、エンタープライズによって管理された新しいアカウントを代わりに使用します。 詳しくは、「GitHub アカウントの種類」をご覧ください。
SSO を使う organization 内のほとんどのリソースにアクセスしようとすると、GitHub はユーザーを認証のために organization の SSO ID プロバイダー (IdP) にリダイレクトします。 IdP でアカウントが正常に認証されると、IdP はGitHubに戻り、Organization のリソースにアクセスできます。
次のように特定の方法でパブリック リポジトリにアクセスする場合、IdP 認証は必要ありません。
- リポジトリの概要ページとファイルの内容を GitHub 上で表示する
- リポジトリをフォークする
- リポジトリのクローンなど、Git を使って読み取り操作を実行する
issue、pull request、プロジェクト、リリースの閲覧など、パブリック リポジトリへのその他のアクセスには認証が必要です。
メモ
外部コラボレーターには SSO 認証は必要ありません。 外部コラボレーターの詳細については、「Organizationのロール」を参照してください。
最近ブラウザで Organization の SAML IdP が認証された場合、SAML SSO を使う GitHub の Organization へのアクセスは自動的に認可されます。 最近ブラウザで Organization の SAML IdP が認証されていない場合は、Organization にアクセスする前に SAML IdP で認証を受ける必要があります。
GitHubで organization のリソースの認証を受けてアクセスするには、IdP で定期的に認証を受けておく必要があります。 IdP による別の指定がない限り、このログイン間隔は 24 時間です。 このように定期的にログインしなければならないことから、アクセスの長さには制限があり、アクセスを続行するには再認証が必要になります。 アクティブな SSO セッションは、セキュリティの設定で表示し、管理できます。 詳しくは、「アクティブな SSO セッションの表示と管理」をご覧ください。
リンクされた外部 ID
IdP アカウントで認証を行い、GitHub に戻ると、GitHub は、GitHub 個人アカウントとサインインした外部 ID の間の organization または Enterprise 内のリンクを記録します。 このリンク ID は、その組織のメンバーシップを検証するために使用されます。また、組織またはエンタープライズの設定に応じて、あなたがどの組織やチームのメンバーになっているかを判断するためにも使用されます。 各 GitHub アカウントは、organization ごとに 1 つの外部 ID にリンクできます。 同様に、各外部 ID は、organization 内の 1 つの GitHub アカウントにリンクできます。
別の GitHub アカウントに既にリンクされている外部 ID でサインインすると、その ID でサインインできないことを示すエラー メッセージが表示されます。 この状況は、組織内で新しい GitHub アカウントを使用しようとしている場合に発生する可能性があります。 その GitHub アカウントでその外部 ID を使用しない場合は、その外部 ID からサインアウトしてから、SSO ログインを繰り返す必要があります。 その外部 ID を GitHub アカウントで使用する場合は、新しいアカウントにリンクできるように、古いアカウントから外部 ID のリンクを解除するように管理者に依頼する必要があります。 Organization または Enterprise の設定によっては、管理者が ID プロバイダー内で ID を再割り当てする必要がある場合もあります。 詳しくは、「組織に対するメンバーの SAML アクセスの表示と管理」をご覧ください。
サインインする外部 ID が、現在 GitHub アカウントにリンクされている外部 ID と一致しない場合は、アカウントを再リンクしようとしているという警告が表示されます。 外部 ID はアクセスとチーム メンバーシップを管理するために使用されるため、新しい外部 ID を使用して続けると、GitHub 内のチームや organization にアクセスできなくなる可能性があります。 今後、その新しい外部 ID を認証に使用することがわかっている場合にのみ続けます。
SSO を使った personal access token と SSH キーの認可
SSO を使用する organization 内の保護されたコンテンツにアクセスするためにコマンド ラインで API または Git を使うには、認可された personal access token を HTTPS 経由で使うか、認可された SSH キーを使う必要があります。
personal access token または SSH キーを持っていない場合は、コマンド ラインの personal access token を作成するか、新しい SSH キーを生成することができます。 詳細については、「個人用アクセス トークンを管理する」または「新しい SSH キーを生成して ssh-agent に追加する」を参照してください。
新しい、または既存の personal access token か SSH キーを、SSO を使うか適用している organization で利用するには、organization で使うためにそのトークンや SSH キーを認可する必要があります。 詳細については、「シングル サインオンに使用する個人用アクセス トークンの認可」または「シングル サインオンに使用する SSH キーの認可」を参照してください。
OAuth apps、GitHub Apps、SSO について
SSO を使うか適用している organization にアクセスするために OAuth app または GitHub App を認可するたびに、アクティブな SSO セッションが必要です。 アプリにサインインするときに SSO を必要とする organization に対するアクティブなセッションがない場合、アプリはその organization にアクセスできません。 ブラウザーで https://github.com/orgs/ORGANIZATION-NAME/sso または https://github.com/enterprises/ENTERPRISE-NAME/sso に移動して、アクティブな SSO セッションを作成できます。
Enterprise または organization の所有者が organization に対して SSO を有効にしたか、適用した後で、ユーザーが SSO を介して初めて認証を行った後、ユーザーは以前に organization へのアクセスを認可した OAuth apps または GitHub Apps を再認可する必要があります。
認証した OAuth apps を表示するには、OAuth apps ページにアクセスします。 認証した GitHub Apps を表示するには、GitHub Apps ページにアクセスします。
詳しくは、「SAML と GitHub Apps」をご覧ください。