エラー: "Current time is earlier than NotBefore condition" (現在の時刻は NotBefore 条件より前です)
このエラーは、IdP と GitHub Enterprise Cloud の間の時間差が大きすぎる場合に発生することがあります。これはセルフホステッド IdP でよく発生します。
このエラーが発生した場合は、IdP の時刻が NTP サーバーと適切に同期していることを確認します。
IdP の立場で ADFS を使っている場合は、GitHub のために ADFS の NotBeforeSkew も 1 分に設定します。 NotBeforeSkew を 0 に設定すると、ミリ秒などの非常に短い時間差でも認証の問題が発生する可能性があります。
ユーザーが繰り返し認証するようにリダイレクトされる
ユーザーが繰り返し SAML 認証プロンプトにリダイレクトされるループに陥る場合は、必要に応じて IdP 設定で SAML セッション期間を長くします。
SAML 応答で送信される SessionNotOnOrAfter 値によって、ユーザーが認証のために IdP にリダイレクトされるタイミングが決まります。 SAML セッション期間を 2 時間以下に構成した場合、期限切れの 5 分前に SAML セッションは GitHub.com によって更新されます。 セッション期間を 5 分以下に構成した場合、ユーザーは SAML 認証ループから抜け出せなくなる可能性があります。
この問題を解決するには、最短 SAML セッション期間を 4 時間に構成することをお勧めします。 詳しくは、「SAML 構成リファレンス」を参照してください。
プロビジョニングされていない、あるいはSCIMによってプロビジョニング解除されたユーザがいる
ユーザのプロビジョニングの問題が生じた場合、ユーザがSCIMのメタデータを欠いているかどうかをチェックすることをおすすめします。
SCIM プロビジョニングが組織に実装されている場合、ユーザーの組織メンバーシップに対する変更は ID プロバイダーが始める必要があります。 ユーザーが既存の SCIM 統合ではなく、手動で組織に招待された場合、ユーザー アカウントが SCIM ID に適切にリンクされない可能性があります。 これにより、将来、ユーザー アカウントが SCIM 経由でプロビジョニング解除されるのを防ぐことができます。 既存の SCIM 統合ではなくユーザーが手動で削除された場合、古いリンク ID が残り、ユーザーが組織に再参加する必要がある場合に問題が発生する可能性があります。
OrganizationのメンバーがSCIMのメタデータを欠いている場合は、IdPを通じてそのユーザに対し、手作業でSCIMをプロビジョニングし直すことができます。
SCIMメタデータを欠いたユーザの監査
期待どおりにプロビジョニングされていない、あるいはプロビジョニング解除されたユーザがいると考えられる、あるいはいることに気づいた場合は、Organizationのすべてのユーザを監査することをおすすめします。
ユーザがSCIMアイデンティティ（SCIMメタデータ）を外部アイデンティティに持っているかをチェックするには、GitHub上で一人ずつOrganizationメンバーのSCIMメタデータをレビューするか、GitHub APIを使ってプログラムですべてのOrganizationメンバーをチェックできます。
IdP が GitHub SCIM API にプロビジョニング呼び出しを送信する場合、その API 呼び出しの SCIM userName は、Organization 内のユーザーのリンクされた SAML ID に格納されている SAML nameID と一致する必要があります。 これら 2 つの値が一致しない場合、SCIM メタデータは設定されず、SCIM ID は正常にリンクされません。 これらの値が一致するかどうかを確認するには、GitHub API を使用します。
GitHub上のOrganizationメンバーの監査
Organization の所有者として、1 人の Organization メンバーに SCIM メタデータがあることを確認するには、次の URL にアクセスし、<organization> と <username> を置き換えます。
https://github.com/orgs/<organization>/people/<username>/sso
ユーザの外部アイデンティティにSCIMメタデータが含まれているなら、そのページにはSCIMアイデンティティセクションが表示されるはずです。 外部アイデンティティにSCIMメタデータが含まれていないなら、SCIMアイデンティティセクションは存在しません。
GitHub APIを通じたOrganizationメンバーの監査
Organizationオーナーは、SCIM REST APIあるいはGraphQLでクエリを行い、SCIMでプロビジョニングされたOrganizationのすべてのアイデンティティをリストできます。
REST API を使用して
SCIM REST APIは、外部アイデンティティの下でSCIMメタデータが展開されているユーザのデータだけを返します。 Organizationの全メンバーのリストと、SCIMでプロビジョニングされているアイデンティティのリストを比較することをおすすめします。
詳細については、次を参照してください。
GraphQLを利用する
この GraphQL クエリを実行すると、Organization 内の各ユーザーの SAML NameId、SCIM UserName、GitHub ユーザー名 (login) が表示されます。 このクエリを使用するには、ORG を実際の Organization 名に置き換えます。
{
organization(login: "ORG") {
samlIdentityProvider {
ssoUrl
externalIdentities(first: 100) {
edges {
node {
samlIdentity {
nameId
}
scimIdentity {
username
}
user {
login
}
}
}
}
}
}
}
curl -X POST -H "Authorization: Bearer YOUR_TOKEN" -H "Content-Type: application/json" -d '{ "query": "{ organization(login: \"ORG\") { samlIdentityProvider { externalIdentities(first: 100) { pageInfo { endCursor startCursor hasNextPage } edges { cursor node { samlIdentity { nameId } scimIdentity {username} user { login } } } } } } }" }' https://api.github.com/graphql
GraphQL APIの利用に関する詳しい情報については、以下を参照してください。
アイデンティティプロバイダを介したユーザのSCIM再プロビジョニング
IdPを介して、ユーザのSCIMを手動で再プロビジョニングできます。 たとえば、Oktaのプロビジョニングのエラーを解決するために、Oktaの管理ポータルで、GitHubアプリケーションに対してユーザの割り当てを解除してから割り当て直すことができます。 これにより、Oktaはそれらのユーザに対するSCIMメタデータをGitHubに展開するAPIコールを発行します。 詳細については、Okta ドキュメントの「Unassign users from applications」 (アプリケーションからのユーザーの割り当て解除) または「Assign users to applications」 (アプリケーションへのユーザーの割り当て) を参照してください。
ユーザのSCIMアイデンティティが作成されたことを確認するには、SCIMの外部アイデンティティを持っていないことが確認された一人のOrganizationメンバーで、このプロセスをテストすることをおすすめします。 手動でIdP内のユーザを更新したら、ユーザのSCIMアイデンティティが作成されたかをGitHub の SCIM APIを使ってチェックできます。 詳しくは、「SCIM メタデータを欠いたユーザーの監査」または REST API エンドポイントの「SCIM」をご覧ください。
ユーザのSCIMの再プロビジョニングでもうまくいかない場合は、GitHubサポートにお問い合わせください。