SAML構成のトラブルシューティング

トラブルシューティングでは、構成を理解することが大切です。

• Auth0はSAMLサービスプロバイダー（SP）ですか、SAML IDプロバイダー（IdP）ですか、それともその両方ですか？

  SPは認証のためにユーザーをどこかにリダイレクトします。IdPは、ユーザーにログインを求め、入力された情報を検証して、ユーザーを認証します。アプリケーションがSAMLで認証するためにユーザーをAuth0にリダイレクトするのであれば、Auth0はIdPです。Auth0がリモートIdPへの接続を使ってユーザーをSAMLでリダイレクトするのであれば、Auth0はリモートIdPに対するSPです。Auth0はSP、IdPまたはその両方の役割を果たすことができます。

• 認証フローが使用するのは、SP起点のモデルですか、IdP起点のモデルですか、それともその両方ですか？

  SP起点の認証フローは、ユーザーがSPのアプリケーションに移動して、ログインのためにIdPにリダイレクトされることから始まります。IdP起点のフローでは、ユーザーがIdPに移動してログインすると、SPのアプリケーションにリダイレクトされます。

  エンタープライズの設定内では、IdP起点のフローが最も汎用されます。

• ユーザープロファイルにあるどの属性がIdP（ログイン時）や各アプリケーション内でユーザーの識別に使用されますか？

  命名属性がIdPとアプリケーション間で異なる場合には、正しいユーザープロファイル属性がアプリケーションに送信されるように、Auth0内で適切なマッピングを構成する必要があります。

  • これまでの事例から判断すると、メールアドレスを一意の識別子として使うのが最も簡単な反面、プライバシーに関して問題が懸念されます。

  • 一般的に、エンタープライズ組織ではIdPについて何らかの内部IDが使用されますが、これらは外部のSaaSアプリケーションにとって有意な別の属性にマッピングする必要があります。

• 認証要求は署名されていますか？

• 認証アサーションは暗号化されていますか？

トラブルシューティングでは、情報を集めて、以下の質問に答えられるようにすることをお勧めします。

1. どのくらいのユーザーに問題が発生していますか？1人ですか？すべてのユーザーですか？

2. これはセットアップの問題ですか、それとも既存の統合が動作しなくなったのですか？

3. どのくらいのアプリケーションが問題の影響を受けていますか？

4. どのような動作が期待されているのですか？どのような動作が起きているのですか？

5. ユーザーはログインシーケンスのどこまで進むことができていますか？

• ユーザーのプロファイルやブラウザー、問題が起きているデバイスを確認します。

• 影響を受けているユーザーについて、すべてのブラウザーで問題が起きている（データの問題を示唆している）のか、特定のブラウザーだけで問題が起きている（ブラウザー特有の問題を示唆している）のかを確認します。

• ブラウザーでJavaScriptとクッキーが有効化されているかを確認します。

• CapsLockキーが解除されていることを確認します。

• ユーザーがモバイルデバイスを使用している場合には、認証や認可に影響を与えるソフトウェアがあるか（何らかの必須ソフトウェアが実行されていないなど）を確認します。

• IdPのシングルサインオン（SSO）URLなど、アプリの主要なURLにユーザーがアクセスできる（ネットワーク接続の問題を示唆している）かを確認します。

以下は、Auth0がサービスプロバイダーの場合に起きがちなエラーとその対処方法です。

このメッセージは、アプリケーションにアクティブな接続が関係付けられていないことを示しています。

"error": "invalid_request", "error_description": "the connection was disabled"

1. ［Auth0 Dashboard］>［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動し、接続タイプを選択します。

2. 接続の名前を選択します。

3. ［Applications（アプリケーション）］ビューを選択します。

4. 少なくとも1つのアプリケーションを有効にします（リストが空の場合には、処理を進める前に、アプリケーションを作成する必要があります）。

このエラーは一般的に、IdPで構成されているACS URLがデフォルトのAuth0テナントドメインを使用しているのに対し、認証トランザクションがカスタムドメインの/authorizeエンドポイントを呼び出して開始されたときに発生します。

"invalid_request": "IdP-Initiated login is not enabled for connection 'CONNECTION_NAME'."

SP起点のフローでこのエラーが表示される場合、次のいずれかが欠けているか、空である可能性があります。

• RelayStateパラメーター

• SAML応答に含まれるInResponseTo属性

これらが欠けている場合、Auth0はログインをIdP起点として扱います。エラーを解消するには、構成をチェックして、両方のフィールドが適切に入力されていることを確認してください。

これを解決するには以下を行います。

1. ［Auth0 Dashboard］>［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動し、接続タイプを選択します。

2. 接続の名前を選択します。

3. ［IdP-Initiated SSO（IdP起点のSSO）］ビューを選択します。

4. ［IdP-Initiated SSO Behavior（IdP起点のSSOの動作）］で［Accept Requests（要求を許可する）］を選択して、IdP起点のログインを有効にします。

5. ［Default Application（デフォルトのアプリケーション）］とそのアプリケーションが使用する［Response Protocol（応答プロトコル）］を選択し、（任意で）アプリケーションに渡したい追加のパラメーターを指定します。

このエラーは、SAML応答のInResponseTo属性がAuth0に認識されない場合に発生します。可能性のある原因には以下が含まれます。

• クッキーがブロックされている

• 最も最近のSAML要求とIDが一致しない

• ドメインの使用が合致しない

テナントがカスタムドメインを使用している場合、ログインフローがカスタムドメインで開始し、正規ドメインで完了すると不一致が発生します。たとえば、ユーザーが次のカスタムドメインで始めたとします：

https://auth.{yourDomain}.com/authorize?client_id=abc123&redirect_uri=https://jwt.io&response_type=code&scope=openid&audience=https://example.com&connection=mysamlconnection

ところが、IDプロバイダーは次の正規ドメインを使って、ACS URLにSAML応答を返すように構成されています：

https://{yourTenant}.auth0.com/login/callback

IDがSAML応答のInResponseTo属性で別のドメインに返されると、そのレコードを持たないAuth0テナントが上記のエラーを返します。

これを解決するには以下を行います。

ログインフローでは一環して同じドメインを使用します。当初の/authorize要求に含めるドメインを変更するか、IDプロバイダーに使用するACS URLを変更します。

このエラーは一般的に、IdP起点のフローが有効化されているのに、フローの実行に必要な情報が指定されていない場合に発生します。

"invalid_request": "Default App for IdP-Initiated is not configured.Make sure to configure that from connection settings or include client_id in RelayState parameter."

ACS URLには、当初の認証要求と同じドメインを使う必要があります。カスタムドメインを使用する場合には、必ず、カスタムドメインのコールバックURLを使用します。

SP起点のフローでこのエラーが表示される場合、次のいずれかが欠けているか、空である可能性があります。

• RelayStateパラメーター

• SAML応答に含まれるInResponseTo属性

これらが欠けている場合、Auth0はログインをIdP起点として扱います。エラーを解消するには、構成をチェックして、両方のフィールドが適切に入力されていることを確認してください。

これを解決するには以下を行います。

1. ［Auth0 Dashboard］>［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動し、接続タイプを選択します。

2. 接続の名前を選択します。

3. ［IdP-Initiated SSO（IdP起点のSSO）］ビューを選択します。

4. ［Default Application（デフォルトのアプリケーション）］とそのアプリケーションが使用する［Response Protocol（応答プロトコル）］を選択し、（任意で）アプリケーションに渡したい追加のパラメーターを指定します。

このエラーは、IDプロバイダーが応答でRelayStateパラメーターを返さない場合に発生します。

IDプロバイダーに問い合わせて、RelayStateパラメーターが必ず返されるようにしてください。

このエラーは、IDプロバイダーのSAML応答にあるaudience値がAuth0で予期する値と一致しない場合に発生します。この値に、Auth0は接続のエンティティIDを期待します。

接続のエンティティIDを確認するには、以下を行います。

1. ［Auth0 Dashboard］>［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動し、接続タイプを選択します。

2. 接続の名前を選択します。

3. ［Setup（セットアップ）］ビューを選択して、［Common Settings（共通設定）］セクションを見つけます。2番目のパラメーターがエンティティIDです。

IDプロバイダーがSAML応答で正しいaudience値を送信することを確認します。

よくある間違いの1つに、IdP起点のタブで不正な応答プロトコルを指定するというものがあります。この応答プロトコルは、Auth0とアプリケーション（リモートIDプロバイダーではない）の間で使用されます。たとえば、この値をSAMLに設定して、アプリケーションがOpenID ConnectまたはWS-Fedを期待する場合には、不正な構成のためにエラーが発生します。

1. ［Auth0 Dashboard］>［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動し、接続タイプを選択します。

2. 接続の名前を選択します。

3. ［IdP-Initiated SSO（IdP起点のSSO）］ビューを選択し、［Response Protocol（応答プロトコル）］の値を確認します。

ADFSがSAML IdPとして構成されている場合、ADFSの証明書利用者信頼のName ID属性がマッピングされていないと、ログアウトフローが失敗します。たとえば、フェデレーションパラメーターのv2/logout?federated&...では、ユーザーはADFS SAMLログアウトエンドポイントにリダイレクトされずに、アプリケーションのコールバックURLに直接リダイレクトで戻されます。この場合、結果的に、ユーザーはIdPからログアウトされません。

Name ID属性を［SAML Relaying Party Trust（証明書利用者信頼）］のルールとして追加します。

SAMLログインのトラブルシューティングでは、主に4つの確認するべき段階があります。

• 段階1：ユーザーがIDプロバイダー（IdP）に正常にリダイレクトされ、ログインできている

• 段階2：IdPにログインした後、ユーザーが正常なログインイベントレコードと共にAuth0に戻されている

• 段階3：Auth0での正常なログインイベントの後、正しいユーザープロファイルがAuth0に存在している

• 段階4：ユーザーがアプリケーションへ正常にリダイレクトで戻され、アプリケーションにアクセスできている

以下のセクションでは、それぞれの段階を確認する方法と、該当する段階で問題があるかを判断する方法について説明します。

1. ［Auth0 Dashboard］>［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動し、［SAML］を選択します。

2. 接続の［Try（試す）］（正三角形の再生）アイコンをクリックして、Auth0とリモートIdPとのやり取りをテストします。接続が動作しない場合には、このセクションに記載の手順を行います。動作する場合には、スキップして、次のセクションに進んでください。

3. SAML接続の横にある［Settings（設定）］（歯車）アイコンをクリックします。

   

4. 以下をIdPの管理者に問い合わせて確認します。

   1. サインインURLが正しいシングルサインオン（SSO）URLである。このURLは、Auth0が認証のためににユーザーを送るリダイレクト先です。

   2. IdPがHTTP-POSTまたはHTTP-リダイレクトのバインディングを期待しているかどうか。デフォルトのバインディングは［Settings（設定）］タブで切り替えることができます。

   3. 認証要求に署名が必要かどうか。必要な場合には、IdPがどの署名アルゴリズムを期待しているのか（認証要求は一般的には署名されません）。署名付きの要求を送信する場合には、接続設定で［Sign Request（要求を署名する）］トグルを有効化し、［Signing Algorithm（署名アルゴリズム）］の値をIdPに合わせて設定します。

   4. IdPの管理者にログエントリを確認してもらってください。問題に関する情報があるかもしれません。

この場合、ユーザーはIDプロバイダーに正常にログインしていますが、Auth0ログにはログイン成功のイベントが表示されていません。

1. Auth0 Dashboardの［Logs（ログ）］ページと［Users（ユーザー）］ページを使って、Auth0にログイン成功のイベントが表示されるかを確認します。Auth0のログにログイン成功のイベントが表示されない場合には、IdPから返されたSAML認証アサーションに問題があるか、Auth0がアサーションを使用できていません。

2. ログインシーケンスのHTTPトレースをキャプチャして分析し、Auth0がアプリケーションに送信する情報を確認します。

   HARファイルを（Auth0を含む）誰かと共有するときは、必ず事前に以下を含むすべての機密データを削除または難読化してください。

   • ユーザーの機密情報

   • 個人を特定できる情報（PII）

   • アプリケーションの機密情報

   詳細については、Auth0コミュニティの以下の記事をお読みください。

   • HTTPトレースのサニタイズ

   • HTTPトレースファイルを自動的にサニタイズする方法

   • 機密情報を手動で編集する方法

   • HARファイルが大きすぎてサポートケースにアップロードできない場合

3. HTTPトレースは、GoogleのHAR AnalyzerなどのHARファイルアナライザーを使用して表示することができます。

   1. HTTPトレースを使って、発生したURLシーケンスを調べます。

      1. 最初のいくつかはアプリケーションのURLです。

      2. それから、Auth0のURL（{yourDomain}など）へのリダイレクトが発生します。

   2. その後に1つ以上のURLが介在してから、Auth0へのPOST応答でユーザー情報を含むSAMLアサーションが返されます。このURLはAuth0のACS（Assertion Consumer Service）用でなければなりません。ACSはアサーションを使って必要な情報を抽出します。

   3. HARアナライザー内でPOST呼び出しの行をクリックします。

   4. POSTデータタブに切り替えて、SAML応答を見つけます。

   5. SAML応答をコピーして、SAMLデバッガー内に貼り付けます。

   6. 先頭の「SAML response」を削除し、末尾近くにある「&RelayState=」で始まるすべてのものも削除します。

4. SAMLメッセージを取得してデコードしたら、以下のフィールドを確認します。

   フィールド	説明
   Destination（送信先）	SAML応答の送信先が正しいAuth0テナントと接続（https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}）であることを確認します。Status Field（ステータスフィールド）

この場合、ユーザーはIDプロバイダーに正常にログインし、Auth0ログにログイン成功のイベントが表示されますが、ユーザーのプロファイル属性が正しくありません。

以下を行って、ユーザーのAuth0プロファイルが正しく入力されているかを確認します。

1. ［Dashboard］>［User Management（ユーザー管理）］>［Users（ユーザー）］に移動します。

2. 目的のユーザーを見つけてクリックし、プロファイルを開きます。そのユーザーに複数の行がある場合には、SAML接続に関係付けられているレコードを開いてください。

3. ユーザープロファイルの詳細を表示するには、2通りの方法があります。［Details（詳細）］タブまたは［Raw JSON（生のJSON）］タブを使用することができます。このタブには、Auth0がIDプロバイダーから受け取った属性が表示されます。

4. 属性がない場合には、アサーションに属性が含まれていたかを確認します。これは、SAMLアサーションをデコードするか、接続にデバッグを有効化すると確認できます。

   1. 接続にデバッグを有効化するには、［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動します。

   2. SAMLのIdP接続リストを開いて、［Settings（設定）］をクリックし、［Debug Mode（デバッグモード）］を有効にします。

      

   3. ［Debug Mode（デバッグモード）］を有効にすると、Dashboard内の［Warning During Login（ログイン時の警告）］ログエントリにoriginal_profileプロパティが表示され、IDプロバイダーがSAMLアサーションに含めたすべての属性がリストされます。このリストを使用すると、IdPが送信している情報を確認して、マッピングの作成に役立てることができます。欠けている属性がアサーションに全く存在していない場合には、IdPに問い合わせて、それを含めるようにしてもらってください。

5. 属性がAuth0のユーザーのプロファイルには存在するのに、正しい属性にマッピングされていない場合には、接続のマッピング機能を使って修正することができます。

   1. これを行うには、［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動します。

   2. SAMLのIdP接続リストを開いて、［Mappings（マッピング）］タブに移動します。

      

   3. 提供しているエディター内のJSONのスニペットは、編集してマッピングの構成に使用することができます。左側の名前はAuth0のユーザープロファイル属性で、これらにアサーションの値がマッピングされます。右側の値はSAMLアサーションに含まれる識別子で、これらから属性にマッピングされます。Auth0がマッピングされていないSAML属性をユーザープロファイルに取り入れるときには、属性識別子に含まれるドット（.）がセミコロン（:）に変更されます。マッピングを構成するときには、必ず、提供する識別子をSAMLアサーションに含まれるものと一致させてください。

この場合、ユーザーはIDプロバイダーに正常にログインし、Auth0ログにログイン成功のイベントが表示され、正しいユーザープロファイル属性ですが、ユーザーがアプリケーションにアクセスできません。

1. アプリケーションのログファイルで、ユーザーがアプリケーションにアクセスできない理由を示すエラーメッセージがないか確認します。この問題では以下の2つが最もよくある原因です。

   1. ユーザープロファイル情報がない

   2. 認可情報が不正か、存在しない

2. ログインシーケンスのHTTPトレースをキャプチャして分析し、Auth0がアプリケーションに送信する情報を確認します。HTTPトレースは、GoogleのHAR AnalyzerなどのHARファイルアナライザーを使用して表示することができます。

   HARファイルを（Auth0を含む）誰かと共有するときは、必ず事前に以下を含むすべての機密データを削除または難読化してください。

   • ユーザーの機密情報

   • 個人を特定できる情報（PII）

   • アプリケーションの機密情報

   詳細については、Auth0コミュニティの以下の記事をお読みください。

   • HTTPトレースのサニタイズ

   • HTTPトレースファイルを自動的にサニタイズする方法

   • 機密情報を手動で編集する方法

   • HARファイルが大きすぎてサポートケースにアップロードできない場合

   1. HTTPトレースを使って、発生したURLシーケンスを調べます。

      1. 最初のいくつかはアプリケーションのURLです。

      2. それから、Auth0のURL（{yourDomain}など）へのリダイレクトが発生します。

   2. その後に1つ以上のURLが介在してから、Auth0へのPOST応答でユーザー情報を含むSAMLアサーションが返されます。このURLはAuth0のACS（Assertion Consumer Service）用でなければなりません。ACSはアサーションを使って必要な情報を抽出します。

   3. HARアナライザー内でPOST呼び出しの行をクリックします。

   4. POSTデータタブに切り替えて、SAML応答を見つけます。

   5. SAML応答をコピーして、SAMLデバッガー内に貼り付けます。

   6. 先頭の「SAML response」を削除し、末尾近くにある「&RelayState=」で始まるすべてのものも削除します。

3. SAMLメッセージを取得してデコードしたら、以下のフィールドを確認します。

   フィールド	説明
   Destination（送信先）	SAML応答の送信先が正しいAuth0テナントと接続（https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}）であることを確認します。Status Field（ステータスフィールド）

4. 認可フローがOIDC準拠のプロトコルを使用している場合には、HARトレースをキャプチャして、GoogleのHAR Analyzerで表示することができます。

   1. HTTPトレースを使って、発生したURLシーケンスを調べて、以下を見つけます。

      1. 最初のいくつかはアプリケーションのURLです。

      2. それから、Auth0のURL（{yourDomain}など）へのリダイレクトが発生します。

   2. ずっと先へ進むと、アプリケーションのコールバックURLがあります。それが正しいことを確認します。

   3. この呼び出しからIDトークンを取得して、JWTデコーダーに貼り付けます。アプリケーションに必要な情報がトークン内のクレームに含まれていることを確認します。

5. IdP起点のフロー（ポータルアプリケーションでユーザーがIDプロバイダーから始めるなど）を使用している場合には、以下を行います。

   1. IDプロバイダーのACS（Assertion Consumer Service）URLに接続名が含まれている（例：https://{yourDomain}/login/callback?connection=CONNECTION_NAME）ことを確認します。

   2. 接続について、IdP起点の構成タブに以下を含む情報が正しく入力されていることを確認します。

      1. IdP起点のSSOの動作設定に［Accept Requests（要求を許可する）］が指定されている

      2. ユーザーが送られるアプリケーション

      3. アプリケーションとAuth0間のプロトコル（接続などは必ずしもSAMLではありませんが、恐らく確実にOpenID Connectです）

      4. クエリ文字列に含めるプロトコル特有の値（scope、response_type、redirect_uri、audienceなど）。SP起点のフローを使用する場合、これらの値はアプリケーションが期待するものと一致しなければなりません。

   3. ルールを一時的に無効にして、ログインプロセスを妨げているものがないことを確認します。

   4. 多要素認証（MFA）を有効化している場合には、一時的に無効にして、ログインプロセスを妨げていないことを確認します。

   5. SP起点のフローで［Try（試す）］を使って接続をテストし、SAML接続が動作することを確認します。

エラーは次のように表示されることがあります。

<samlp:Status> <samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:Responder" /> </samlp:Status>

1. Auth0接続の署名アルゴリズムがADFS側と同じ（rsa-sha256またはrsa-sha1）であることを確認します。

2. または、ADFSの管理者に問い合わせて、期待されている署名方法を確認するか、ログにエラーの原因について詳細があるかを確認してもらってください。

SAMLログインのトラブルシューティングでは、主に4つの確認するべき段階があります。

• 段階1：ユーザーがIdPに正常にリダイレクトされ、ログインできている

• 段階2：IdPにログインした後、ユーザーが正常なログインイベントレコードと共にAuth0に戻されている

• 段階3：Auth0での正常なログインイベントの後、正しいユーザープロファイルがAuth0に存在している

• 段階4：ユーザーがアプリケーションへ正常にリダイレクトで戻され、アプリケーションにアクセスできている

この場合、ユーザーはIdPに正常にログインしていますが、Auth0ログにはログイン成功のイベントが表示されていません。

1. Auth0のデータベース接続を使用している場合には、以下を行います。

   1. ユーザーが存在し、正しいパスワードが入力されていることを確認します。

   2. ルールを一時的に無効にして、ログインプロセスを妨げているものがないことを確認します。

   3. 多要素認証（MFA）を有効化している場合には、一時的に無効にして、ログインプロセスを妨げていないことを確認します。

2. Auth0のデータベース接続またはリモートSAML接続を使用している場合には、［Try（試す）］を使って接続をテストし、SAML接続が動作することを確認します。

この場合、ユーザーはIdPに正常にログインし、Auth0ログにログイン成功のイベントが表示されますが、ユーザーのプロファイル属性が正しくありません。ユーザーについて以下が該当するかを確認します

• ユーザーが正常にログインしているように見える

• Auth0 Dashboardの［Logs（ログ）］ページと［Users（ユーザー）］ページにログイン成功のイベントが表示されている

これらが該当する場合には、ユーザーのプロファイルに必要なユーザープロファイル属性が含まれていることを確認します。

1. ［Dashboard］>［User Management（ユーザー管理）］>［Users（ユーザー）］に移動します。

2. 目的のユーザーを見つけてクリックし、プロファイルを開きます。そのユーザーに複数の行がある場合には、SAML接続に関係付けられているレコードを開いてください。

3. ユーザープロファイルの詳細を表示するには、2通りの方法があります。［Details（詳細）］タブまたは［Raw JSON（生のJSON）］タブを使用することができます。このタブには、Auth0がIDプロバイダーから受け取った属性が表示されます。属性がない場合には、IDプロバイダーに問い合わせて、属性が存在し、その属性がAuth0に返されていることを確認します。

この場合、ユーザーはIdPに正常にログインし、Auth0ログにログイン成功のイベントが表示され、正しいユーザープロファイル属性ですが、ユーザーがアプリケーションにアクセスできません。

1. 以下を行って、ユーザーのAuth0プロファイルが正しく入力されているかを確認します。

   1. ［Dashboard］>［User Management（ユーザー管理）］>［Users（ユーザー）］に移動します。

   2. 目的のユーザーを見つけてクリックし、プロファイルを開きます。そのユーザーに複数の行がある場合には、SAML接続に関係付けられているレコードを開いてください。

   3. ユーザープロファイルの詳細を表示するには、2通りの方法があります。［Details（詳細）］タブまたは［Raw JSON（生のJSON）］タブを使用することができます。このタブには、Auth0がIDプロバイダーから受け取った属性が表示されます。アプリケーションに必要なすべての詳細がプロファイルに含まれていることを確認します。ユーザー属性がない場合には、IDプロバイダーに問い合わせて、属性が存在し、その属性がAuth0に返されていることを確認します。

2. アプリケーションのログファイルで、ユーザーがアプリケーションにアクセスできない理由を示すエラーメッセージがないか確認します。この問題で最もよくある原因の2つとして、ユーザープロファイルが存在しないか、認可情報が不正または存在しないことが挙げられます。

3. ログインシーケンスのHTTPトレースをキャプチャして分析し、Auth0がアプリケーションに送信する情報を確認します。HTTPトレースは、GoogleのHAR AnalyzerなどのHARファイルアナライザーを使用して表示することができます。

   HARファイルを（Auth0を含む）誰かと共有するときは、必ず事前に以下を含むすべての機密データを削除または難読化してください。

   • ユーザーの機密情報

   • 個人を特定できる情報（PII）

   • アプリケーションの機密情報

   詳細については、Auth0コミュニティの以下の記事をお読みください。

   • HTTPトレースのサニタイズ

   • HTTPトレースファイルを自動的にサニタイズする方法

   • 機密情報を手動で編集する方法

   • HARファイルが大きすぎてサポートケースにアップロードできない場合

   1. HTTPトレースを使って、発生したURLシーケンスを調べます。

      1. 最初のいくつかはアプリケーションのURLです。

      2. それから、Auth0のURL（{yourDomain}など）へのリダイレクトが発生します。

   2. その後に1つ以上のURLが介在してから、Auth0へのPOST応答でユーザー情報を含むSAMLアサーションが返されます。このURLはAuth0のACS（Assertion Consumer Service）用でなければなりません。ACSはアサーションを使って必要な情報を抽出します。

   3. HARアナライザー内でPOST呼び出しの行をクリックします。

   4. POSTデータタブに切り替えて、SAML応答を見つけます。

   5. SAML応答をコピーして、SAMLデバッガー内に貼り付けます。

   6. 先頭の「SAML response」を削除し、末尾近くにある「&RelayState=」で始まるすべてのものも削除します。

4. SAMLメッセージを取得してデコードしたら、以下のフィールドを確認します。

   フィールド	説明
   Destination（送信先）	SAML応答の送信先が正しいAuth0テナントと接続（https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}）であることを確認します。Status Field（ステータスフィールド）

5. アプリケーションに必要な追加情報がSAMLアサーションに含まれ、アプリケーションが期待している属性内にその情報が存在することを確認します。

   1. Auth0からアプリケーションに送信するアサーションを修正しなければならない場合には、ルールを使って属性を追加またはマッピングします。

      1. Auth0にログインして［Rules（ルール）］に移動します。

      2. ［Create Rule（ルールの作成）］をクリックし、開いたページで［Change your SAML configuration（SAML構成を変更する）］テンプレートを選択します。

      3. ルールエディターで、使用したい行のコメント記号を削除します。属性のマッピングが必要な場合には、テンプレートにある行の9～17を使用します。行を追加して、マッピングを実装することもできます。各行の左側に、アサーションに含まれる属性の識別子を指定します。各行の右側ではAuth0のユーザープロファイル属性を参照します。これらの値は、アプリケーションに送信するアサーションに含めるときに使用されます。

         //context.samlConfiguration.mappings = {    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier":      "user_id",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress":        "email",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name":                "name",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname":           "given_name",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname":             "family_name",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":                 "upn",    
             // "http://schemas.xmlsoap.org/claims/Group":                                   "groups"    
             // };

         Was this helpful?

         Yes /No

SAMLログアウト要求に含まれるSessionIndexとNameIDの値は、サービスプロバイダーがオリジナルのSAMLアサーションで受け取る値と一致しなければなりません。

上記のトラブルシューティングの手順で問題が解消されない場合には、Auth0のサポートセンターでチケットを作成し、サポートをリクエストしてください。その際には、以下の情報を提供してください。

1. どのくらいのユーザーに問題が発生しているのか。1人ですか？全員ですか？

2. 新しいセットアップで起きている問題なのか、それとも既存の統合が動作しなくなったのか

3. どのくらいのアプリケーションが問題の影響を受けているのか

4. どのような動作が期待されていて、どのような動作が起きているのか

5. ユーザーがログインシーケンスのどこまで進むことができているのか

6. Auth0に登録済のアプリケーションの名前とそれが使用するIDプロトコル

7. 問題に関わっている接続の名前

8. Auth0 Lockウィジェットを使用しているのか（使用している場合、バージョンは何か）

9. Lockのカスタマイズしたバージョンを使用しているのか

10. SSO統合のHTTPトレースの.harファイル

    HARファイルを（Auth0を含む）誰かと共有するときは、必ず事前に以下を含むすべての機密データを削除または難読化してください。

    • ユーザーの機密情報

    • 個人を特定できる情報（PII）

    • アプリケーションの機密情報

    詳細については、Auth0コミュニティの以下の記事をお読みください。

    • HTTPトレースのサニタイズ

    • HTTPトレースファイルを自動的にサニタイズする方法

    • 機密情報を手動で編集する方法

    • HARファイルが大きすぎてサポートケースにアップロードできない場合

11. 失敗した認証に関するAuth0ログエントリ

12. 問題に関わっているサードパーティーアプリケーション（Sharepointなど）の認証ログファイル

• SAMLシングルサインオン統合
• Auth0をサービス プロバイダーおよびIDプロバイダーとして使用したSAML SSOのテスト