ユーザをアイデンティティプロバイダに追加せずに認証したいなら、ビルトイン認証を設定できます。 詳細は「使用中のアイデンティティプロバイダ外のユーザのためにビルトイン認証を許可する」を参照してください。
サポートされているSAMLサービス
SAML 2.0標準を実装するすべてのアイデンティティプロバイダには、限定的なサポートを提供します。 内部的にテストを行った以下のアイデンティティプロバイダは公式にサポートされます。
- Active Directory フェデレーションサービス (AD FS)
- Azure Active Directory (Azure AD)
- Okta
- OneLogin
- PingOne
- Shibboleth
GitHub Enterpriseは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は永続的かつ一意でなければならず、ユーザのライフサイクルを通じて変化しないことが必要です。
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の設定
-
任意のページの右上で をクリックします。
-
左のサイドバーで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 インスタンスへのアクセスの削除
アイデンティティプロバイダからユーザを削除したなら、そのユーザを手動でサスペンドもしなければなりません。 そうしなければ、そのユーザはアクセストークンあるいはSSHキーを使って引き続き認証を受けることができてしまいます。 詳しい情報についてはユーザのサスペンドとサスペンドの解除を参照してください。
レスポンスメッセージについての要求
レスポンスメッセージは以下の要求を満たさなければなりません。
<Destination>要素はルートレスポンスドキュメントで指定されていなければならず、ACS URLに一致する必要があります。ただし、これはルートレスポンスドキュメントに署名がある場合のみです。 If the assertion is signed, it will be ignored.<AudienceRestriction>要素の一部として、<Audience>要素は常に指定する必要があります。 それはGitHub Enterprise ServerのエンティティIdに一致しなければなりません。 これは、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>
エラーメッセージ
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.
Audience が指定されていない、またはGitHub Enterprise Server エンティティ Id と一致しない場合は、auth ログに次のようなエラーメッセージが出力されます。
Audience is invalid. Audience attribute does not match your_instance_url