SAML 構成について
GitHub に対する認証に SAML シングル サインオン (SSO) を使うには、外部 SAML ID プロバイダー (IdP) と GitHub 上の Enterprise または organization の両方を構成する必要があります。 SAML 構成では、GitHub は SAML サービス プロバイダー (SP) として機能します。 Enterprise の認証の詳細については、「ID とアクセス管理について」を参照してください。
GitHub は、SAML 2.0 仕様に準拠した統合を提供します。 詳細については、OASIS の Web サイトの SAML Wiki を参照してください。
GitHub 用に SAML SSO を構成する場合は、SAML IdP から一意の値を入力する必要があります。また、IdP 上では GitHub から一意の値を入力する必要もあります。
SAMLのメタデータ
GitHub Enterprise Cloud 用の SP メタデータは、SAML SSO を使う organization または Enterprise で使用できます。 GitHub は、urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
バインディングを使います。
Enterprise Managed Users を使用する場合は、エンタープライズ レベルでのみ SAML SSO を有効にすることができます。
組織
エンタープライズ内の個々の組織向けの SAML SSO を構成できます。 また、GitHub Enterprise Cloud で個々の organization を使い、Enterprise アカウントを使わない場合は、organization 向けの SAML SSO を構成できます。 詳しくは、「Organization で SAML シングルサインオンを管理する」をご覧ください。
GitHub 上の Organization の SP メタデータは https://github.com/orgs/ORGANIZATION/saml/metadata
で入手できます。ここで、ORGANIZATION は、GitHub 上でご使用の Organization の名前です。
値 | その他の名前 | 説明 | 例 |
---|---|---|---|
SP エンティティ ID | SP URL、対象ユーザー制限 | GitHub.com上の組織の最上位の URL | https:/ |
SP アサーションコンシューマーサービス (ACS) URL | 応答、受信者、または宛先 URL | IdP が SAML レスポンスを送信する URL | https:/ |
SP シングルサインオン (SSO) URL | |||
IdP が SSO を開始する URL | https:/ |
Enterprise
ご利用の環境に応じて、GitHub Enterprise Cloud 上のエンタープライズの SP メタデータは、次のいずれかで入手できます。
https://github.com/enterprises/ENTERPRISE/saml/metadata
(ENTERPRISE はエンタープライズの名前)https://SUBDOMAIN.ghe.com/enterprises/SUBDOMAIN/saml/metadata
(SUBDOMAIN はエンタープライズのサブドメインの名前)
値 | その他の名前 | 説明 | 例 |
---|---|---|---|
SP エンティティ ID | SP URL、対象ユーザー制限 | GitHub.com上の エンタープライズの最上位の URL | https:/ |
SP アサーションコンシューマーサービス (ACS) URL | 応答、受信者、または宛先 URL | IdP が SAML レスポンスを送信する URL | https:/ |
SP シングルサインオン (SSO) URL | |||
IdP が SSO を開始する URL | https:/ |
SAMLの属性
GitHub では、次の SAML 属性を使用できます。
名前 | 必須 | 説明 |
---|---|---|
NameID | 永続ユーザ識別子。 任意の名前識別子の形式を使用できます。 Enterprise Managed Users で Enterprise を使っている場合、代替アサーションのいずれかが指定されていない限り、GitHub によって NameID 要素が正規化され、ユーザー名として使われます。 詳しくは、「外部認証のユーザー名に関する考慮事項」をご覧ください。> [!NOTE] 人間が判読できる永続的識別子を使うことが重要です。 urn:oasis:names:tc:SAML:2.0:nameid-format:transient のような一時的な識別子の形式を使うと、サインインするたびにアカウントが再リンクされます。これは認可管理に悪影響を与える可能性があります。 | |
Session | 関連付けられたセッションが GitHub によって無効化される日付。 無効になった後、企業のリソースにアクセスするには、ユーザーはもう一度認証を行う必要があります。 詳細については、「セッションの継続時間とタイムアウト」を参照してください。 | |
full_name | Enterprise 向けの SAML SSO を構成し、Enterprise Managed Users を使用する場合、ユーザーのプロファイル ページに表示するユーザーのフル ネーム。 | |
emails | ユーザーのメール アドレス。GitHub Enterprise Server と GitHub Enterprise Cloud 間でライセンス使用状況を同期する場合、複数の製品にまたがって一意のユーザーを識別するために、GitHub Connect は emails を使います。 詳しくは、「GitHub Enterprise ServerとGitHub Enterprise Cloudとのライセンス利用状況の同期」をご覧ください。 | |
public_keys | Enterprise 向けの SAML SSO を構成し、Enterprise Managed Users を使用する場合、ユーザーのパブリック SSH キー。 複数のキーを指定できます。 | |
gpg_keys | Enterprise 向けの SAML SSO を構成し、Enterprise Managed Users を使用する場合、ユーザーの GPG キー。 複数のキーを指定できます。 |
属性に複数の値を指定するには、複数の <saml2:AttributeValue>
要素を使用します。
<saml2:Attribute FriendlyName="public_keys" Name="urn:oid:1.2.840.113549.1.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue>ssh-rsa LONG KEY</saml2:AttributeValue>
<saml2:AttributeValue>ssh-rsa LONG KEY 2</saml2:AttributeValue>
</saml2:Attribute>
SAML 応答の要件
GitHub では、IdP からの応答メッセージが次の要件を満たしている必要があります。
-
IdP では、ルート応答ドキュメントで
<Destination>
要素を指定し、ルート応答ドキュメントが署名されている場合にのみ ACS URL と一致する必要があります。 IdP によってアサーションに署名されている場合、GitHub ではアサーションが無視されます。 -
IdP では常に、
<AudienceRestriction>
要素の一部として<Audience>
要素を指定する必要があります。 値は GitHub のEntityId
と一致している必要があります。- 組織の SAML を構成する場合、この値は
https://github.com/orgs/ORGANIZATION
です。 - Enterprise の SAML を構成する場合、この URL は
https://github.com/enterprises/ENTERPRISE
またはhttps://SUBDOMAIN.ghe.com/enterprises/SUBDOMAIN
です。
- 組織の SAML を構成する場合、この値は
-
IdP は、応答でデジタル署名付きの 1 つのアサーションを提供する必要があります。 これを行うには、
<Assertion>
要素に署名するか、<Response>
要素に署名します。 -
IdP では、
<Subject>
要素の一部として<NameID>
要素を指定する必要があります。 任意の永続的な名前識別子の形式を使用できます。 -
IdP には
Recipient
属性を含める必要があり、これは ACS URL に設定される必要があります。 次の例は、属性を示しています。<samlp:Response ...> <saml:Assertion ...> <saml:Subject> <saml:NameID ...>...</saml:NameID> <saml:SubjectConfirmation ...> <saml:SubjectConfirmationData Recipient="https://github.com/enterprises/ENTERPRISE/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>
セッションの継続期間とタイムアウト
ユーザーの IdP で他のユーザーが認証を行い、無期限に認可される状態を防ぐため、 Enterprise のリソース に対してアクセス権を持つ各ユーザー アカウントのセッションは、GitHub によって定期的に無効にされます。 無効になると、ユーザーは IdP でもう一度認証を行う必要があります。
既定では、IdP が SessionNotOnOrAfter
属性の値をアサートしない場合、IdP による認証に成功してから 24 時間後に、GitHub によってセッションが無効にされます。
GitHub でカスタマイズしたセッション期間がサポートされるのは、IdP が SessionNotOnOrAfter
属性と値を構成するオプションを提供している場合です。。
カスタマイズされたセッション継続時間の値を 24 時間未満に定義すると、GitHub がリダイレクトを開始するたびに、GitHub からユーザーに対して認証が求められる場合があります。
認証エラーを防ぐため、最短セッション期間を 4 時間にすることをお勧めします。 詳しくは、「SAML認証」をご覧ください。
Note
Microsoft Entra ID (旧称 Azure AD) の場合、SAML トークンの構成可能な有効期間ポリシーによって、GitHub のセッション タイムアウトは制御されません。