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のユーザ名になる場合、最初のユーザアカウントだけが作成されます。 同じユーザ名のそれ以降のユーザは、サインインできません。

以下の表は、ユーザ名がGitHub Enterprise Serverでどのように変換されるかの例を示しています。

2要素認証

SAMLあるいはCASを利用する場合、GitHub Enterprise Server上では2要素認証はサポートあるいは管理されませんが、外部の認証プロバイダではサポートされることがあります。 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. In the upper-right corner of any page, click .

   

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

   

3. In the left sidebar, click Authentication.

   

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

   

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

   

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

   

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

7. Select Disable administrator demotion/promotion if you do not want your SAML provider to determine administrator rights for users on GitHub Enterprise Server インスタンス.

   

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

   

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

   

10. In the Signature Method and Digest Method drop-down menus, choose the hashing algorithm used by your SAML issuer to verify the integrity of the requests from GitHub Enterprise Server インスタンス. Name Identifier Format（Name Identifier形式）ドロップダウンメニューから形式を指定してください。

    

11. Under Verification certificate, click Choose File and choose a certificate to validate SAML responses from the IdP.

    

12. 必要に応じて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.