SAML 構成リファレンス

SAML 構成について

GitHub に対する認証に SAML シングル サインオン (SSO) を使うには、外部 SAML ID プロバイダー (IdP) と GitHub 上のエンタープライズまたは組織の両方を構成する必要があります。 SAML 構成では、GitHub は SAML サービス プロバイダー (SP) として機能します。 Enterprise の認証の詳細については、「ID とアクセス管理の基礎」を参照してください。

GitHub は、SAML 2.0 仕様に準拠した統合を提供します。 詳細については、OASIS の Web サイトの SAML Wiki を参照してください。

GitHub 用に SAML SSO を構成する場合は、SAML IdP から一意の値を入力する必要があります。また、IdP 上では GitHub から一意の値を入力する必要もあります。

SAMLのメタデータ

これらのステップを実行してください：

GitHub Enterprise Cloud 用の SP メタデータは、SAML SSO を使う organization または Enterprise で使用できます。 GitHub は、urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST バインディングを使います。

Enterprise Managed Users を使用する場合は、エンタープライズ レベルでのみ SAML SSO を有効にすることができます。

組織

エンタープライズ内の個々の組織向けの SAML SSO を構成できます。 また、GitHub Enterprise Cloud で個々の organization を使い、Enterprise アカウントを使わない場合は、organization 向けの SAML SSO を構成できます。 詳しくは、「組織で SAML シングルサインオン (SSO) を管理する」をご覧ください。

GitHub 上の Organization の SP メタデータは https://github.com/orgs/ORGANIZATION/saml/metadata で入手できます。ここで、ORGANIZATION は、GitHub 上でご使用の Organization の名前です。

値	その他の名前	説明	例
SP エンティティーID	SP URL、対象ユーザー制限	GitHub.com上の組織の最上位の URL	https://github.com/orgs/ORGANIZATION
SP アサーションコンシューマーサービス (ACS) URL	応答、受信者、または宛先 URL	IdP が SAML レスポンスを送信する URL	https://github.com/orgs/ORGANIZATION/saml/consume
SP シングルサインオン (SSO) URL
IdP が SSO を開始する URL	https://github.com/orgs/ORGANIZATION/sso

エンタープライズ

ご利用の環境に応じて、GitHub Enterprise Cloud 上のエンタープライズの SP メタデータは、次のいずれかで入手できます。

•         `https://github.com/enterprises/ENTERPRISE/saml/metadata` (**ENTERPRISE** はエンタープライズの名前)
  

•         `https://SUBDOMAIN.ghe.com/enterprises/SUBDOMAIN/saml/metadata` (**SUBDOMAIN** はエンタープライズのサブドメインの名前)
  

値	その他の名前	説明	例
SP エンティティーID	SP URL、対象ユーザー制限	GitHub.com上の エンタープライズの最上位の URL	https://github.com/enterprises/ENTERPRISE
SP アサーションコンシューマーサービス (ACS) URL	応答、受信者、または宛先 URL	IdP が SAML レスポンスを送信する URL	https://github.com/enterprises/ENTERPRISE/saml/consume
SP シングルサインオン (SSO) URL
IdP が SSO を開始する URL	https://github.com/enterprises/ENTERPRISE/sso

SAMLの属性

GitHub では、次の SAML 属性を使用できます。

名前	必須	説明
NameID		永続ユーザ識別子。 任意の名前識別子の形式を使用できます。 Enterprise Managed Users で Enterprise を使用する場合、代替アサーションのいずれかが指定されていない限り、GitHub は、NameID 要素を正規化し、ユーザー名として使用します。 詳しくは、「外部認証のユーザー名に関する考慮事項」をご覧ください。

          > 
          [!NOTE] 人間が判読できる永続的識別子を使うことが重要です。 
          `urn:oasis:names:tc:SAML:2.0:nameid-format:transient` のような一時的な識別子の形式を使うと、サインインするたびにアカウントが再リンクされます。これは認可管理に悪影響を与える可能性があります。  |

| SessionNotOnOrAfter | | 関連付けられたセッションが GitHub によって無効化される日付。 無効になった後、企業のリソースにアクセスするには、ユーザーはもう一度認証を行う必要があります。 詳細については、「セッションの継続時間とタイムアウト」を参照してください。 | | | | full_name | | Enterprise 向けの SAML SSO を構成し、Enterprise Managed Users を使用する場合、 ユーザーのプロファイル ページに表示するユーザーのフル ネーム。 | | emails | | ユーザーのメール アドレス。GitHub Enterprise Server と GitHub Enterprise Cloud 間でライセンス使用状況を同期する場合、複数の製品にまたがって一意のユーザーを識別するために、GitHub Connect は emails を使います。 詳しくは、「GitHub Enterprise Server からクラウドへのライセンス使用量の同期」をご覧ください。 | | public_keys | | Enterprise 向けの SAML SSO を構成し、Enterprise Managed Users を使用する場合、 ユーザーのパブリック SSH キー。 複数のキーを指定できます。 | | gpg_keys | | Enterprise 向けの SAML SSO を構成し、Enterprise Managed Users を使用する場合、 ユーザーの GPG キー。 複数のキーを指定できます。 |

属性に複数の値を指定するには、複数の <saml2:AttributeValue> 要素を使用します。

<saml2:Attribute FriendlyName="public_keys" Name="urn:oid:1.2.840.113549.1.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>ssh-rsa LONG KEY</saml2:AttributeValue>
    <saml2:AttributeValue>ssh-rsa LONG KEY 2</saml2:AttributeValue>
</saml2:Attribute>

SAML 応答の要件

GitHub では、IdP からの応答メッセージが次の要件を満たしている必要があります。

• IdP では、ルート応答ドキュメントで <Destination> 要素を指定し、ルート応答ドキュメントが署名されている場合にのみ ACS URL と一致する必要があります。 IdP がアサーションに署名する場合、GitHub はそのアサーションを無視します。

• IdP では常に、<Audience> 要素の一部として <AudienceRestriction> 要素を指定する必要があります。 値は GitHub の EntityId と一致している必要があります。

  • 組織の SAML を構成する場合、この値は https://github.com/orgs/ORGANIZATIONです。
  • Enterprise の SAML を構成する場合、この URL は https://github.com/enterprises/ENTERPRISE または https://SUBDOMAIN.ghe.com/enterprises/SUBDOMAIN です。

• IdP では、デジタル署名で応答に単一アサーションを提供する必要があります。 これを行うには、<Assertion> 要素に署名するか、<Response> 要素に署名します。

• IdP では、<NameID> 要素の一部として <Subject> 要素を指定する必要があります。 任意の永続的な名前識別子の形式を使用できます。

• IdP には Recipient 属性を含める必要があり、これは ACS URL に設定される必要があります。 次の例は、属性を示しています。

  <samlp:Response ...>
    <saml:Assertion ...>
      <saml:Subject>
        <saml:NameID ...>...</saml:NameID>
        <saml:SubjectConfirmation ...>
          <saml:SubjectConfirmationData Recipient="https://github.com/enterprises/ENTERPRISE/saml/consume" .../>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:AttributeStatement>
        <saml:Attribute FriendlyName="USERNAME-ATTRIBUTE" ...>
          <saml:AttributeValue>monalisa</saml:AttributeValue>
        </saml:Attribute>
      </saml:AttributeStatement>
    </saml:Assertion>
  </samlp:Response>
  

セッションの継続期間とタイムアウト

ユーザーの IdP で他のユーザーが認証を行い、無期限に認可される状態を防ぐため、 Enterprise のリソース に対してアクセス権を持つ各ユーザー アカウントのセッションは、GitHub によって定期的に無効にされます。 無効になると、ユーザーは IdP でもう一度認証を行う必要があります。

既定では、IdP が SessionNotOnOrAfter 属性の値をアサートしない場合、IdP による認証に成功してから 24 時間後に、GitHub によってセッションが無効にされます。

GitHub でカスタマイズしたセッション期間がサポートされるのは、IdP が SessionNotOnOrAfter 属性と値を構成するオプションを提供している場合です。。

カスタマイズされたセッション継続時間の値を 24 時間未満に定義すると、GitHub がリダイレクトを開始するたびに、GitHub からユーザーに対して認証が求められる場合があります。

認証エラーを防ぐため、最短セッション期間を 4 時間にすることをお勧めします。 詳しくは、「SAML認証のトラブルシューティング」をご覧ください。