SAMLの利用

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

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

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

Active Directory フェデレーションサービス (AD FS)
Azure Active Directory (Azure AD)
Okta
OneLogin
PingOne
Shibboleth

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

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 は永続的で一意でなければならず、ユーザのライフサイクルにおいて変更にさらされないようにする必要があります。

注釈: ユーザの NameID が IdP で変更された場合、ユーザが GitHub Enterprise Server インスタンスにサインインしようとすると、エラーメッセージが表示されます。ユーザのアクセスを復元するには、ユーザアカウントの NameID マッピングを更新する必要があります。詳しい情報については、「ユーザの SAML NameID を更新する」を参照してください。

GitHub Enterprise Serverのユーザ名に使えるのは、英数字とダッシュ（-）のみです。 GitHub Enterprise Serverは、アカウントのユーザ名に含まれている非英数字をダッシュに変換します。たとえばgregory.st.johnというユーザ名は、gregory-st-johnに変換されます。変換されたユーザ名の先頭及び末尾はダッシュであってはならないことに注意してください。 2つの連続するダッシュを含めることもできません。

メールアドレスから作成されたユーザ名は、@以前の文字を変換して作成されます。

複数のアカウントが変換後に同じGitHub Enterprise Serverのユーザ名になる場合、最初のユーザアカウントだけが作成されます。同じユーザ名のそれ以降のユーザは、サインインできません。

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

ユーザ名	変換されたユーザ名	結果
Ms.Bubbles	`ms-bubbles`	このユーザ名の作成は成功します。
!Ms.Bubbles	`-ms-bubbles`	このユーザ名はダッシュで始まるので作成されません。
Ms.Bubbles!	`ms-bubbles-`	このユーザ名はダッシュで終わるので作成されません。
Ms!!Bubbles	`ms--bubbles`	このユーザ名には連続する2つのダッシュが含まれるので作成されません。
Ms!Bubbles	`ms-bubbles`	このユーザ名は作成されません。変換されたユーザ名は正当ですが、すでに存在しています。
Ms.Bubbles@example.com	`ms-bubbles`	このユーザ名は作成されません。変換されたユーザ名は正当ですが、すでに存在しています。

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で変更できます。

デフォルトの属性名	種類	説明
`NameID`	必須	永続ユーザ識別子。任意の名前識別子の形式を使用できます。どの代替アサーションも指定しない場合、GitHub Enterprise Serverユーザ名には`NameID`要素が使用されます。
`administrator`	任意	この値が 'true' であれば、ユーザは自動的に管理者に昇格します。他の値、あるいは値が存在しない場合は、ユーザは通常のユーザアカウントに降格します。
`ユーザ名`	任意	GitHub Enterprise Server のユーザ名
`full_name`	任意	ユーザのプロフィールページに表示されるユーザ名です。ユーザはプロビジョニング後に名前を変更できます。
`emails`	任意	ユーザのメールアドレス。複数指定することができます。
`public_keys`	任意	ユーザの公開 SSH キー。複数指定することができます。
`gpg_keys`	任意	ユーザの GPG キー。複数指定することができます。

SAMLの設定

GitHub Enterprise Serverの管理アカウントから、任意のページの右上にあるをクリックしてください。
左のサイドバーでManagement Consoleをクリックしてください。
左のサイドバーでAuthentication（認証）をクリックしてください。
SAMLを選択してください。
あるいは、ユーザがGitHub Enterprise Serverのインスタンスのアイデンティティプロバイダに属していないなら、Allow built-in authentication（ビルトイン認証の許可）を選択して、ビルトイン認証を使うように招待することもできます。
オプションで、未承諾応答SSOを有効化する場合は [IdP initiated SSO] を選択します。デフォルトでは、GitHub Enterprise Serverは未承認アイデンティティプロバイダ (IdP) 起点のリクエストに対して、IdPへのAuthnRequest返信で応答します。

ノート：この値は選択しないでおくことをおすすめします。この機能を有効にするのは、SAMLの実装がサービスプロバイダ起点のSSOをサポートしないまれな場合と、GitHub Enterprise Supportによって推奨された場合だけにすべきです。
GitHub Enterprise Serverのインスタンス上のユーザの管理者権限を SAML プロバイダに決めさせたくない場合、[Disable administrator demotion/promotion] を選択します。
Single sign-on URL（シングルサインオンURL）フィールドに、使用するIdpのシングルサインオンのリクエストのためのHTTPあるいはHTTPSエンドポイントを入力してください。この値はIdpの設定によって決まります。ホストが内部のネットワークからしか利用できない場合、GitHub Enterprise Serverのインスタンスを内部ネームサーバーを利用するように設定する必要があるかもしれません。
または、[Issuer] フィールドに、SAML の発行者の名前を入力します。これは、GitHub Enterprise Serverのインスタンスへ送信されるメッセージの真正性を検証します。
[Signature Method] および [Digest Method] ドロップダウンメニューで、SAML の発行者が GitHub Enterprise Serverのインスタンスからのリクエストの整合性の検証に使うハッシュアルゴリズムを選択します。 Name Identifier Format（Name Identifier形式）ドロップダウンメニューから形式を指定してください。
[Verification certificate] の下で、[Choose File] をクリックし、IdP からの SAML のレスポンスを検証するための証明書を選択してください。
必要に応じてSAMLの属性名はIdPに合わせて修正してください。あるいはデフォルト名をそのまま受け付けてください。

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

GitHub Enterprise Serverの管理アカウントから、任意のページの右上にあるをクリックしてください。
SAMLを選択してください。
ユーザーのリストで、NameID マッピングを更新するユーザ名をクリックします。
ページ右上にある、 Security（セキュリティ） をクリックしてください。
[Update SAML NameID] の右にある [Edit] アイコンをクリックします。
[NameID] フィールドに、ユーザの新しい NameID を入力します。
[Update NameID] をクリックします。

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

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

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

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

<Destination>要素はルートレスポンスドキュメントで指定されていなければならず、ACS URLに一致する必要があります。ただし、これはルートレスポンスドキュメントに署名がある場合のみです。アサーションに署名がある場合は無視されます。
<AudienceRestriction>要素の一部として、<Audience>要素は常に指定する必要があります。 <AudienceRestriction>要素の一部として、<Audience>要素は常に指定する必要があります。これは、https://ghe.corp.example.comというような、GitHub Enterprise ServerインスタンスへのURLです。
レスポンス中での各アサーションは、電子署名で保護されていなければなりません。これは、個々の<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>

SAML認証

GitHub Enterprise Server は、認証ログの /var/log/github/auth.log で失敗した SAML 認証のエラーメッセージをログに記録します。 SAML レスポンス要件の詳細については、「レスポンスメッセージの要件」を参照してください。

エラー:「別のユーザがすでにアカウントを所有しています」

ユーザが SAML 認証を使用して初めて GitHub Enterprise Server にサインインすると、GitHub Enterprise Server はインスタンスにユーザアカウントを作成し、SAML NameID をアカウントにマップします。

ユーザが再度サインインすると、GitHub Enterprise Server はアカウントの NameID マッピングを IdP のレスポンスと比較します。 IdP のレスポンスの NameID が、GitHub Enterprise Server がユーザに対して想定している NameID とマッチしなくなると、サインインは失敗します。ユーザには次のメッセージが表示されます。

別のユーザが既にアカウントを所有しています。管理者に認証ログを確認するようご依頼ください。

このメッセージは通常、その人のユーザ名またはメールアドレスが IdP で変更されたということを示します。 GitHub Enterprise Server のユーザアカウントの NameID マッピングが IdP のユーザの NameID とマッチすることを確認します。詳しい情報については、「ユーザの SAML NameID の更新」を参照してください。

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

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

Recipient in the SAML response must not be blank.

Recipient in the SAML response was not valid.

IdP の Recipient の値を、GitHub Enterprise Server インスタンスの完全な ACS URL に設定してください。例: https://ghe.corp.example.com/saml/consume

エラー:「SAML レスポンスが署名されていないか、変更されています」

IdP が SAML レスポンスに署名しない場合、または署名が内容と一致しない場合、次のエラーメッセージが認証ログに表示されます。

SAML Response is not signed or has been modified.

IdP で GitHub Enterprise Server アプリケーションの署名済みアサーションを設定していることを確認してください。

エラー:「Audience が無効です」または「アサーションが見つかりません」

IdP のレスポンスに Audience の値がないか、または正しくない場合、次のエラーメッセージが認証ログに表示されます。

Audience is invalid. Audience attribute does not match https://YOUR-INSTANCE-URL

IdP の Audience の値を、GitHub Enterprise Server インスタンスの EntityId に設定してください。これは、GitHub Enterprise Server インスタンスへの完全な URL です。例: https://ghe.corp.example.com

製品で調べる

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