[Access Control] シングルサインオンにおけるトラブルシューティング

SAML SSO の設定を完了したにもかかわらず、SSO の接続確認でエラーが発生する場合の切り分け手順です。

1. 接続設定に起因する場合
以下を Access Control 側・SP 側の両方で確認してください。

Access Control 側

［サービスプロバイダー設定］で、対象 SP の設定が有効になっているかを確認します。
参考：[Access Control] サービスプロバイダー設定の編集

• SP にアクセスする Access Control ユーザーに対して、SP へのアクセス許可設定が行われているか確認します。
  参考：[Access Control] アクセスポリシーグループの作成 / 編集
• ACS URL、SP Issuer（Entity ID）に設定されている値が、SP 側から取得した値と完全に一致しているか・不要なスペースや記号が含まれていないか確認します。
• 属性のマッピングで、SP が要求する属性（NameID）が正しく設定されているか確認します。通常は、SP 側のログイン ID に対応する Access Control の属性を設定します。
• NameID フォーマットの設定値（email/unspecified/persistent）が、SP 側の要件に基づいた設定値となっているかを確認します。
• 属性の設定に必要な追加属性が正しく設定されているかを確認します。
  ※SP によっては IdP 側で属性の追加を必要とする場合があります。この場合は、必要に応じて「属性」および「値」に SP 側で指定された値を設定してください。

SP 側

• Access Control のメタデータ（エンドポイント URL・証明書）が正しく登録されているか確認します。
  ※Access Control のメタデータは、Access Control 側のサービスプロバイダー設定の編集画面右上［メタデータ］より確認できます。
• SP 側の SSO 設定が「有効」になっているか確認します。

2. ネットワーク・環境に起因する場合

ファイアウォールやプロキシ環境では、Access Control、SP、ユーザー端末間の通信がブロックされることがあります。

• Access Control や SP への通信が許可されているか確認します。
  ※Access Control への通信を許可するために必要な情報は後述の「HENNGE One 動作環境」のヘルプ記事内［ネットワーク］－［サービスの FQDN（URL）］の表内「Access Control」を参照してください。
• SP へアクセス時に使用するブラウザの同じウィンドウ上で既に別の Access Control ユーザーでログインしていないか確認します。
  ※例として、SSO 接続設定のために Access Control 管理者アカウントでログイン中のウィンドウ上で SSO 接続テストを試みた場合、SSO 接続テストを行う SP 側のアカウントに紐づく Access Control ユーザーと競合し、エラーとなる場合があります。
• ネットワークを変更して事象が再現するか確認します。
• ブラウザのキャッシュ・Cookie をクリアして再試行します。

参考：
HENNGE One 動作環境
ブラウザのキャッシュクリアの方法およびノンキャッシュモードでの利用方法について

利用端末の OS により SSO の挙動が変わる場合、以下を確認してください。

• SP が対象の環境からの SSO に対応しているか
• ID・パスワードでのログインは可能か
  ※Android 端末や各 OS の Chrome/Safari ブラウザにおける証明書サポート状況は、OS バージョンやブラウザのアップデートにより変わることがあります。

参考：
HENNGE One 動作環境
[Device Certificate] iOS / iPad OS でデバイス証明書を利用する場合の制約事項

以下を確認してください。

1. Access Control 管理画面で、ユーザーのステータスが「有効」になっているか確認します。

2. 対象ユーザーが正しいアクセスポリシーグループに割り当てられているか確認します。

3. SP 側でも対象ユーザーのアカウントが有効になっているか確認します。

4. Access Control のユーザー ID と SP 側のユーザー ID が一致しているか確認します（大文字・小文字の差異も確認します）。

以下を確認してください。

原因 1：対象サービスが IdP Initiated に対応していない

一部のサービスでは、IdP Initiated によるログイン方式に対応していない場合があります。この場合、Access Control のユーザーポータルやブックマーク URL から対象サービスへアクセスすると、認証後に正しい画面へ遷移しない、または SSO に失敗することがあります。

確認事項

対象サービスが IdP Initiated に対応しているか、サービス側の仕様を確認します。対象サービスが SP Initiated のみ対応している場合は、サービス側のログイン URL から SSO を開始します。

原因 2：RelayState が SP に返却されていない

SSO 方式によって、RelayState の動作は以下のとおりです。

確認事項

1. Access Control 管理画面のサービスプロバイダー設定で、RelayState を確認します。

2. Access Control で RelayState が空欄にもかかわらず SP 側で意図した画面へ遷移しない場合は、SP 側の設定または仕様を確認してください。

以前は正常に動作していた SSO が突然できなくなった場合、以下を確認してください。

1. 連携先サービスの仕様変更による ACS URL・SP Issuer の変更

連携先サービス（SP）のアップデートや UI 変更に伴い、ACS URL や SP Issuer（Entity ID）の値が変更されている場合があります。連携先サービスの最新の SSO 設定手順を確認し、Access Control 側のサービスプロバイダー設定を更新してください。

• Access Control 管理画面の［サービスプロバイダー設定］で、ACS URL および SP Issuer（Entity ID）が連携先サービスの現在の値と一致しているか確認します。
• 連携先サービス側に登録している Access Control のメタデータ（エンドポイント URL・証明書）が最新の状態になっているか確認します。

2. ユーザー情報やアクセスポリシーグループの設定が意図せず変更されている

ユーザー情報やアクセスポリシーグループの設定が意図せず変更されていないか確認してください。

詳細は［特定ユーザーだけ SSO ができない］のトラブルシューティング手順を参照してください。