SAMLの利用

ここには以下の内容があります:

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

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

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

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

• Active Directory フェデレーションサービス (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. 任意のページの右上で をクリックします。

   

2. 左のサイドバーでManagement Consoleをクリックしてください。

   

3. 左のサイドバーで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. GitHub Enterprise Server インスタンス 上のユーザの管理者権限を SAML プロバイダに決めさせたくない場合、[Disable administrator demotion/promotion] を選択します。

   

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

   

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

   

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

    

11. [Verification certificate] の下で、[Choose File] をクリックし、IdP からの SAML のレスポンスを検証するための証明書を選択してください。

    

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.