SAMLの利用

使用しているアイデンティティプロバイダに追加せずにユーザを認証したい場合、ビルトイン認証を設定できます。詳細は「アイデンティティプロバイダ外のユーザに対するビルトイン認証を許可する」を参照してください。

このガイドの内容は以下のとおりです。

• サポートされているSAMLサービス
• SAMLでのユーザ名についての考慮
• 2 要素認証
• SAMLのメタデータ
• SAMLの属性
• SAMLの設定
• GitHub Enterprise Server インスタンスへのアクセスの削除
• レスポンスメッセージについての要求
• エラーメッセージ

サポートされているSAMLサービス

弊社では、SAML 2.0 標準を実装するすべてのアイデンティティプロバイダに対して限定的なサポートを提供します。内部的にテストされた以下のアイデンティティプロバイダを公式にサポートします:

• Active Directory Federation Services (AD FS)
• Azure Active Directory (Azure AD)
• Okta
• OneLogin
• PingOne
• Shibboleth

GitHub Enterprise は、SAML シングルログアウトをサポートしません。アクティブな SAML セッションを終了するには、ユーザは SAML サーバーで直接ログアウトしなければなりません。

SAMLでのユーザ名についての考慮

各GitHub Enterprise Serverユーザ名は、SAMLの応答で次のアサーションのいずれかによって決定され、優先順位で並べられます。

• カスタムユーザ名属性 (定義済みかつ存在する場合)
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameアサーション (存在する場合)
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddressアサーション (存在する場合)
• NameID要素

NameID要素は、他の属性が存在する場合でも必須です。

NameIDとGitHub Enterprise Serverユーザ名の間にマッピングが作成されるので、NameIDは永続的かつ一意でなければならず、ユーザのライフサイクルを通じて変化しないことが必要です。

GitHub Enterprise Server のユーザ名には、英数字文字とダッシュ (-) のみが利用できます。GitHub Enterprise Server はアカウントのユーザ名内の非英数字文字をダッシュに正規化します。たとえば gregory.st.john のユーザ名は gregory-st-john に正規化されます。正規化されたユーザ名の先頭や末尾はダッシュにする事ができません。また、2 つ連続でダッシュを含むこともできません。

メールアドレスから生成されたユーザ名は、@ 文字の前の正規化された文字から生成されます。

複数のアカウントが正規化されて同一の GitHub Enterprise Server ユーザ名になる場合、1 つめのユーザアカウントだけが作成されます。同じユーザ名のそれ以降のユーザは、サインインできなくなります。

以下の表は、ユーザ名が GitHub Enterprise Server でどのように正規化されるかの例です。

2要素認証

SAML あるいは CAS を利用する場合、2要素認証は GitHub Enterprise Server アプライアンス上ではサポートあるいは管理されませんが、外部の認証プロバイダによってサポートされることはあります。Organization での 2 要素認証の強制はできません。Organization での 2 要素認証の強制に関する詳しい情報については、「Organization で 2 要素認証を要求する」を参照してください。

SAMLのメタデータ

GitHub Enterprise Server インスタンスのサービスプロバイダメタデータは、http(s)://[hostname]/saml/metadata にあります。

アイデンティティプロバイダを手動で設定するなら、Assertion Consumer Service (ACS) URLはhttp(s)://[hostname]/saml/consumeです。 これはurn:oasis:names:tc:SAML:2.0:bindings:HTTP-POSTバインディングを利用します。

SAMLの属性

以下の属性が利用できます。 administrator属性以外の属性の名前はManagement Consoleで変更できます。

SAMLの設定

1. 任意のページの右上の隅で をクリックしてください。

   

2. 左サイドバーで [Management Console] をクリックします。

   

左サイドバーで [Authentication] をクリックします。

3. SAMLを選択してください。

   

4. あるいは、ユーザがGitHub Enterprise Server インスタンスのアイデンティティプロバイダに属していないなら、Allow built-in authentication（ビルトイン認証の許可）を選択して、ビルトイン認証を使うように招待することもできます。

   

5. オプションで、未承諾応答SSOを有効化する場合は [IdP initiated SSO] を選択します。 デフォルトでは、GitHub Enterprise Serverは未承認アイデンティティプロバイダ (IdP) 起点のリクエストに対して、IdPへのAuthnRequest返信で応答します。

   

   ノート：この値は選択しないでおくことをおすすめします。 この機能を有効にするのは、SAMLの実装がサービスプロバイダ起点のSSOをサポートしないまれな場合と、GitHub Enterprise Supportによって推奨された場合だけにすべきです。

6. GitHub Enterprise Server インスタンス上のユーザの管理者権限をSAMLプロバイダに決めさせたくないなら、Disable administrator demotion/promotion（管理者の降格/昇格の無効化を選択してください。

   

7. Single sign-on URL（シングルサインオンURL）フィールドに、使用するIdpのシングルサインオンのリクエストのためのHTTPあるいはHTTPSエンドポイントを入力してください。 この値はIdpの設定によって決まります。 ホストが内部のネットワークからしか利用できない場合、GitHub Enterprise Server インスタンスを内部ネームサーバーを利用するように設定する必要があるかもしれません。

   

8. または、[Issuer] フィールドに、SAML の発行者の名前を入力します。 これは、GitHub Enterprise Server インスタンス へ送信されるメッセージの真正性を検証します。

   

9. Signature Method（シグニチャ方式）及びDigest Method（ダイジェスト方式）のドロップダウンメニューでは、SAMLの発行者がGitHub Enterprise Server インスタンスからのリクエストの整合性の検証に使うハッシュアルゴリズムを選択してください。 Name Identifier Format（Name Identifier形式）ドロップダウンメニューから形式を指定してください。

   

10. Verification certificate（検証証明書）の下でChoose File（ファイルの選択）をクリックし、IdPからのSAMLのレスポンスを検証するための証明書を選択してください。

    

11. 必要に応じてSAMLの属性名はIdPに合わせて修正してください。あるいはデフォルト名をそのまま受け付けてください。

    

GitHub Enterprise Server インスタンスへのアクセスの削除

アイデンティティプロバイダからユーザを削除したなら、そのユーザを手動でサスペンドもしなければなりません。 そうしなければ、そのユーザはアクセストークンあるいはSSHキーを使って引き続き認証を受けることができてしまいます。 詳しい情報についてはユーザのサスペンドとサスペンドの解除を参照してください。

レスポンスメッセージについての要求

レスポンスメッセージは以下の要求を満たさなければなりません。

• <Destination>要素はルートレスポンスドキュメントで指定されていなければならず、ACS URLに一致する必要があります。

<AudienceRestriction>要素の一部として<Audience>要素が指定されている場合は、GitHub Enterprise ServerエンティティIdと比較チェックされます。これはGitHub Enterprise ServerインスタンスのURLで、https://ghe.corp.example.comなどです。

• レスポンス中での各アサーションは、電子署名で保護されていなければなりません。 これは、個々の<Assertion>要素に署名するか、<Response>要素を署名するかすることによって行います。
• <Subject>要素の一部として<NameID>要素を指定する必要があります。 任意の名前識別子の形式を使用できます。
• Recipient 属性は存在しなければならず、ACS URL に設定されなければなりません。 例:

<samlp:Response ...>
  <saml:Assertion ...>
    <saml:Subject>
      <saml:NameID ...>...</saml:NameID>
      <saml:SubjectConfirmation ...>
        <saml:SubjectConfirmationData Recipient="https://ghe.corp.example.com/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>

エラーメッセージ

RecipientがACS URLと一致しなかった場合、authログに以下のエラーメッセージが残されます。

Recipient in the SAML response was not valid.

Recipientがレスポンスメッセージの一部ではなかった場合、authログに以下のエラーメッセージが残されます。

Recipient in the SAML response must not be blank.

SAMLレスポンスが署名されていなかった場合、あるいは署名が内容とマッチしなかった場合、authログに以下のエラーメッセージが残されます。

SAML Response is not signed or has been modified.