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

SAML 構成の問題のトラブルシューティングについて説明します。

トラブルシューティングを行う際は、構成を理解しておくことが重要です。

• Auth0 は SAML Service Provider (SP) 、SAML IDプロバイダー (IdP) 、それともその両方として機能していますか？

  SP は、認証のためにユーザーを別の場所へリダイレクトします。IdP は、ユーザーにログインを求め、入力された情報を検証して認証します。アプリケーションが SAML を介した認証のためにユーザーを Auth0 にリダイレクトする場合、Auth0 は IdP です。Auth0 が SAML を介してユーザーを接続経由でリモート IdP にリダイレクトする場合、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 とクッキーが有効になっているか確認します。
• Caps Lock キーがオフになっていることを確認します。
• ユーザーがモバイルデバイスを使用している場合は、認証および/または認可に影響する可能性のあるソフトウェア要因がないか確認します (たとえば、必要な種類のソフトウェアが実行されていない場合など) 。
• ユーザーが、IdP の シングルサインオン (SSO) URL など、アプリの主要な URL の一部にアクセスできるか確認します (ネットワーク接続の問題を示唆) 。

サービスプロバイダーとしてのAuth0のトラブルシューティング

よくあるエラー

以下は、Auth0 がサービスプロバイダーとして機能する場合に発生しやすい一般的なエラーと、その解決手順です。

エラー: 接続が無効になっています

このメッセージは、アプリケーションに関連付けられた有効な接続がないことを示しています。

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

1. Auth0 Dashboard > Authentication > Enterprise に移動し、接続タイプを選択します。
2. 接続の名前を選択します。
3. Applications ビューを選択します。
4. 少なくとも 1 つのアプリケーションを有効にします (一覧に何も表示されない場合は、先にアプリケーションを作成する必要があります) 。

エラー: IdP-Initiated ログインが有効になっていません

このエラーは通常、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 ビューを選択します。
4. IdP-Initiated SSO Behavior を見つけて、Accept Requests を選択し、IdP 開始ログインを有効にします。
5. Default Application と、そのアプリケーションで使用される Response Protocol を選択し、必要に応じてアプリケーションに渡す追加のパラメーターを指定します。

エラー: InResponseTo 属性が AuthNRequest の ID と一致しない

このエラーは、SAML レスポンス内の InResponseTo 属性を Auth0 テナントが認識できない場合に発生します。このエラーの原因として、次のことが考えられます。

• cookie がブロックされている
• 直近の SAML リクエストの ID が一致していない
• ドメインの使い方に一貫性がない

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

しかし、IDプロバイダーは、正規のドメインにある ACS URL に SAML レスポンスを返すよう設定されています。

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

SAML レスポンスの InResponseTo 属性で ID が別のドメインに返されると、Auth0 テナントにはその記録が存在しないため、上記のエラーが返されます。

この問題を修正するには、次のようにします。

ログインフロー全体で同じドメインを使用してください。最初の /authorize リクエストのドメイン、または IDプロバイダー側の ACS URL のいずれかを変更します。

エラー: IdP-Initiated の Default App が設定されていません

このエラーは通常、IdP-Initiated フローを有効にしているものの、そのフローの実行に必要な情報が指定されていない場合に発生します。

"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-initiated フローの使用時にこのエラーが表示される場合は、次のいずれかが欠落しているか、空になっています。

• RelayState パラメーター
• SAML レスポンス内の InResponseTo 属性

これらが欠落しているか空の場合、Auth0 はそのログインを IdP-Initiated として扱います。このエラーは、両方のフィールドに適切な値が設定され、正しく返されるように構成を確認することで解消できます。

この問題を修正するには、次の手順を実行します。

1. Auth0 Dashboard > Authentication > Enterprise に移動し、接続タイプを選択します。
2. 接続の名前を選択します。
3. IdP-Initiated SSO ビューを選択します。
4. Default Application と、そのアプリケーションで使用される Response Protocol を選択し、必要に応じてアプリケーションに渡す追加のパラメーターを指定します。

エラー: RelayState がありません

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

IDプロバイダー側で、RelayState パラメーターが返されるようにしてください。

エラー: Audience が無効です

このエラーは、IDプロバイダーの SAML レスポンス内の audience 要素の値が、Auth0 が期待する値と一致しない場合に発生します。Auth0 では、この値が接続のエンティティ ID であることを想定しています。

接続のエンティティ ID は、次の手順で確認できます。

1. Auth0 Dashboard > Authentication > Enterprise に移動し、接続タイプを選択します。
2. 接続の名前を選択します。
3. Setup ビューを開き、Common Settings セクションを確認します。Entity ID は 2 番目のパラメーターです。

IDプロバイダーが、SAML レスポンスで正しい audience 値を送信していることを確認してください。

誤ったプロトコルが指定されている

よくあるエラーの 1 つは、IdP-Initiated タブで誤った応答プロトコルを指定してしまうことです。応答プロトコルは、リモート IDプロバイダーではなく、Auth0 とアプリケーションの間で使用されるプロトコルを指します。たとえば、アプリケーションが OpenID Connect または WS-Fed を想定しているのに、この値を SAML に設定すると、設定が正しくないためエラーが発生します。

1. Auth0 Dashboard > Authentication > Enterprise に移動し、接続タイプを選択します。
2. 接続の名前を選択します。
3. IdP-Initiated SSO ビューを選択し、Response Protocol を見つけて値を確認します。

ユーザーが IdP からログアウトされない

ADFS が SAML IdP として構成されている場合、ADFS の Relying Party Trust で Name ID 属性がマッピングされていないと、ログアウトフローは失敗します。たとえば、federated パラメーター v2/logout?federated&... を使用すると、ユーザーは ADFS の SAML ログアウトエンドポイントにリダイレクトされず、代わりにアプリケーションの callback URL に直接リダイレクトされます。その結果、この場合、ユーザーは IdP からログアウトされません。

SAML Relying Party Trust に Rule として Name ID 属性を追加します。

SAML ログインの問題

SAML ログインをトラブルシューティングする際は、主に 4 つの段階を確認します。

• ステージ 1: ユーザーが IDプロバイダー (IdP) に正常にリダイレクトされ、ログインできる。
• ステージ 2: IdP でのログイン後、ユーザーが Auth0 に戻り、ログイン成功イベントが記録される。
• ステージ 3: Auth0 でログイン成功イベントが記録された後、Auth0 のユーザープロフィールが正しい。
• ステージ 4: ユーザーがアプリケーションに正常にリダイレクトされ、アプリケーションにアクセスできる。

以下のセクションでは、各段階の確認方法と、特定の段階に問題があるかどうかを特定する方法について説明します。

IdP のログインページが表示されない

1. Auth0 Dashboard > Authentication > Enterprise に移動し、SAML を選択します。

2. 対象の接続を見つけて Try (三角形の再生アイコン) を選択し、Auth0 とリモート IdP 間の連携をテストします。接続が機能しない場合は、このセクションの手順に進んでください。機能する場合は、次のセクションに進みます。

3. SAML 接続の横にある Settings (歯車アイコン) をクリックします。

   

4. 次の項目を IdP 管理者に確認してください。

   1. Sign In URL が正しいシングルサインオン (SSO) URL であること。これは、Auth0 が認証のためにユーザーをリダイレクトする URL です。
   2. IdP が HTTP-POST バインディングと HTTP-Redirect バインディングのどちらを想定しているか。デフォルトのバインディングは Settings タブで切り替えられます。
   3. 認証リクエストへの署名が必要かどうか。必要な場合は、IdP がどの署名アルゴリズムを想定しているか。 (認証リクエストに署名するケースは一般的ではない点に注意してください。) 署名付きリクエストを送信する場合は、接続設定の Sign Request トグルを有効にし、Signing Algorithm の値が IdP の想定と一致していることを確認してください。
   4. 問題に関する情報が得られる可能性のあるログエントリを確認するよう、IdP 管理者に依頼してください。

Logs にログイン成功イベントが表示されない

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

1. Auth0 Dashboard の Logs ページと Users ページを確認し、Auth0 にログイン成功イベントが記録されているか確認します。Auth0 のログにログイン成功イベントが表示されない場合は、IdP から返された SAML 認証アサーションに問題があるか、Auth0 がそのアサーションを処理できていない可能性があります。

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

   HAR ファイルを第三者 (Auth0 を含む) と共有する前に、次のような機密データをすべて削除または難読化してください。

   • 機密性の高いユーザー情報
   • 個人を特定できる情報 (PII)
   • 機密性の高いアプリケーション情報

   詳細については、Auth0 Community の以下の記事を参照してください。

   • HTTP トレースのサニタイズ
   • HTTP トレースファイルを自動的にサニタイズする方法
   • 機密情報を手動でマスキングする方法
   • HAR ファイルが大きすぎてサポートケースにアップロードできない

3. Google の HAR Analyzer などの HAR ファイルアナライザーで HTTP トレースを確認できます。

   1. HTTP トレースで呼び出されている URL の流れを確認します。

      1. 最初のいくつかはアプリケーションの URL です。
      2. その後、Auth0 の URL ({yourDomain} など) へのリダイレクトがあります。

   2. その間に 1 つ以上の URL を挟んだ後、ユーザー情報を含む SAML アサーションを含んだ Auth0 への POST が行われます。この URL は、アサーションを処理して必要な情報を抽出する Auth0 の Assertion Consumer Service (ACS) の URL である必要があります。

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

   4. POST Data タブに切り替え、SAML レスポンスを探します。

   5. SAML レスポンスをコピーして、SAML debugger に貼り付けます。

   6. 先頭の “SAML response” と、末尾の &RelayState= で始まる部分をすべて削除します。

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

フィールド	説明

ユーザープロフィールの属性が正しくありません

この場合、ユーザーは IdP でのログインには成功しており、Auth0 のログにもログイン成功イベントが表示されますが、ユーザーのユーザープロフィール属性が正しくありません。

ユーザーの Auth0 ユーザープロフィールが正しく設定されているか確認してください。

1. Dashboard > User Management > Users に移動します。

2. 対象のユーザーを見つけてクリックし、プロフィールを開きます。特定のユーザーについて複数の行がある場合は、必ず SAML 接続に関連付けられているレコードを開いてください。

3. ユーザーのユーザープロフィールでは、2 つの方法で詳細を確認できます。Details タブまたは Raw 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 ユーザープロフィールに属性値は存在しているものの、正しい属性にマッピングされていない場合は、接続の Mapping 機能で修正できます。

   1. これを行うには、Authentication > Enterprise に移動します。

   2. SAML IdP 接続の一覧を開き、Mappings タブに移動します。

      

   3. 表示されるエディターには、マッピングを設定するために編集可能な JSON スニペットがあります。左側の名前は、アサーションの値のマッピング先となる Auth0 ユーザープロフィール属性です。右側の値は、その属性の取得元となる SAML アサーション内の識別子です。Auth0 がマッピングされていない SAML 属性をユーザープロフィールに取り込む際、ドット . を含む属性識別子はコロン : に置き換えられます。マッピングを設定する際は、指定する識別子が SAML アサーション内のものと一致していることを確認してください.```

ユーザーがアプリケーションにアクセスできない

この場合、ユーザーは IdP でのログインには成功し、Auth0 のログにもログイン成功イベントが記録され、ユーザーのユーザープロフィール属性も正しいにもかかわらず、アプリケーションにアクセスできません。

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

   1. ユーザープロフィール情報の不足。
   2. 認可情報が誤っている、または不足している。

2. ログインシーケンスの HTTP トレースを取得して解析し、Auth0 がアプリケーションに送信している情報を確認します。HTTP トレースは、Google’s HAR Analyzer などの HAR ファイルアナライザーで確認できます。

   HAR ファイルを他者 (Auth0 を含む) と共有する前に、次のようなすべての機密データを削除または難読化していることを確認してください。

   • 機密のユーザー情報
   • 個人を特定できる情報 (PII)
   • 機密のアプリケーション情報

   詳しくは、Auth0 Community の次の記事を参照してください。

   • HTTP トレースのサニタイズ
   • HTTP トレースファイルを自動的にサニタイズする方法
   • 機密情報を手動でマスキングする方法
   • HAR ファイルが大きすぎてサポートケースにアップロードできない

   1. HTTP トレースで呼び出される URL の流れを確認します。

      1. 最初のいくつかは、アプリケーションの URL です。
      2. その後、Auth0 の URL ({yourDomain} など) へのリダイレクトがあります。

   2. さらに 1 つ以上の URL を経た後、ユーザー情報を含む SAML アサーションを含んだ Auth0 への POST が行われます。URL は、アサーションを受け取り、必要な情報を抽出する Auth0 の Assertion Consumer Service (ACS) 向けである必要があります。

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

   4. POST Data タブに切り替え、SAML レスポンスを探します。

   5. SAML レスポンスをコピーして、SAML debugger に貼り付けます。

   6. 先頭の SAML レスポンスと、末尾の &RelayState= で始まる部分を削除します。

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

フィールド	説明

4. 認可フローで OIDC 準拠プロトコルを使用している場合は、HAR トレースを取得し、Google の HAR Analyzer で確認できます。

   1. トレース内の URL の並びを確認し、次の点を探します。

      1. 最初の数件はアプリケーションの URL です。
      2. その後に、Auth0 の URL ({yourDomain} など) へのリダイレクトがあります。

   2. さらに下のほうにアプリケーションの callback URL があるので、それが正しいことを確認します。

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

5. IdP 開始フローを使用している場合 (たとえば、ユーザーがポータルアプリケーション内の IDプロバイダー から開始する場合) は、次の点を確認してください。

   1. IDプロバイダー 側の Assertion Consumer Service (ACS) 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. ログインプロセスに干渉しているものがないことを確認するため、Rules を一時的に無効にしてください。

   4. 多要素認証 (MFA) を有効にしている場合は、ログインプロセスに干渉していないことを確認するため、一時的に無効にしてください。

   5. Try を使用して 接続 テストを実行し、SAML 接続 が SP 開始フローで動作することを確認してください。

SAML レスポンダーまたは SAML authority 側のエラーにより、リクエストを実行できませんでした

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

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

1. Auth0 の接続で使用している署名アルゴリズムが、ADFS 側の設定と一致していることを確認してください。rsa-sha256 または rsa-sha1 のいずれかです。
2. または、想定される署名方式を確認するか、エラーの原因に関する追加情報がログに記録されていないか確認するために、ADFS 管理者に問い合わせてください。

IDプロバイダーとしての Auth0 のトラブルシューティング

SAML ログインのトラブルシューティングでは、主に次の 4 つの段階を確認します。

• ステージ 1: ユーザーが正常に IDP にリダイレクトされ、ログインできます。
• ステージ 2: IDP でログインした後、ユーザーが Auth0 に戻り、ログイン成功イベントが記録されます。
• ステージ 3: Auth0 でログイン成功イベントが記録された後、Auth0 のユーザープロフィールが正しい状態になっています。
• ステージ 4: ユーザーが正常にアプリケーションにリダイレクトされ、アプリケーションにアクセスできます。

ログイン成功イベントがログに表示されない

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

1. Auth0 データベース接続を使用している場合:

   1. ユーザーが存在し、入力したパスワードが正しいことを確認します。
   2. ログイン処理を妨げているものがないことを確認するため、Rules を一時的に無効にします。
   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 タブを使用します。ここでは、Auth0 が IDプロバイダー (IdP) から受け取った属性を確認できます。属性が不足している場合は、IDプロバイダー (IdP) にその属性が存在し、Auth0 に返されていることを確認してください。

ユーザーがアプリケーションにアクセスできない

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

1. ユーザーの Auth0 上のユーザープロフィールが正しく設定されているか確認します。

   1. Dashboard > User Management > Users に移動します。
   2. 対象のユーザーを見つけてクリックし、プロフィールを開きます。1 人のユーザーに対して複数の行が表示される場合は、必ず SAML 接続に関連付けられたレコードを開いてください。
   3. ユーザーのユーザープロフィールで、Details タブまたは Raw JSON タブのいずれかを使って詳細を確認します。ここでは、Auth0 が IDプロバイダーから受け取った属性を確認できます。プロフィールに、アプリケーションで必要な情報がすべて含まれていることを確認してください。ユーザーの属性が不足している場合は、その属性が IDプロバイダーに存在し、Auth0 に返されていることを確認してください。

2. アプリケーションのログファイルを確認し、ユーザーがアプリケーションにアクセスできない理由を示すエラーメッセージがないか調べます。この問題の最も一般的な原因は、ユーザープロフィール情報の不足、または認可情報の誤りや不足です。

3. ログインシーケンスの HTTP トレースを取得して分析し、Auth0 がアプリケーションに送信している情報を確認します。HTTP トレースは、Google’s HAR Analyzer などの HAR ファイルアナライザーで確認できます。

   HAR ファイルを誰かと共有する前に (Auth0 を含む) 、次のような機密データをすべて削除または難読化してください。

   • 機密性の高いユーザー情報
   • 個人を特定できる情報 (PII)
   • 機密性の高いアプリケーション情報

   詳細については、Auth0 Community の以下の記事を参照してください。

   • Sanitizing HTTP Traces
   • How to Sanitize an HTTP Trace File Automatically
   • How to Manually Redact Sensitive Information
   • HAR File is Too Large to Upload to the Support Case

   1. HTTP トレースで呼び出される URL の流れを確認します。

      1. 最初のいくつかは、アプリケーションの URL です。
      2. その後、Auth0 の URL ({yourDomain} など) へのリダイレクトがあります。

   2. さらに 1 つ以上の URL を経由した後、ユーザー情報を含む SAML アサーションを含んだ POST が Auth0 に返されます。この URL は、アサーションを処理して必要な情報を抽出する Auth0 の Assertion Consumer Service (ACS) の URL である必要があります。

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

   4. POST Data タブに切り替え、SAML レスポンスを探します。

   5. SAML レスポンスをコピーして、SAML debugger に貼り付けます。

   6. 先頭の SAML レスポンスと、末尾の &RelayState= で始まる部分をすべて削除します。

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

フィールド	説明

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

   1. Auth0 からアプリケーションに送信するアサーションを変更する必要がある場合は、Rules を使用して属性を追加またはマッピングできます。

      1. Auth0 にログインし、Rules に移動します。

      2. Create Rule をクリックし、次のページで Change your SAML configuration テンプレートを選択します。

      3. Rules エディターで、使用する行のコメントを解除します。必要に応じて属性をマッピングするには、テンプレートの 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"    
             // };
         

LogoutRequest エラーに一致するアクティブなセッションが見つからない

SAML ログアウトリクエスト内の SessionIndex と NameID の値は、元の SAML アサーションでサービスプロバイダーが受信した値と一致している必要があります。

サポートへのお問い合わせ

上記のトラブルシューティング手順で問題が解決しない場合は、Support Center でチケットを作成して Auth0 にサポートを依頼してください。次の情報を必ず含めてください。

1. この問題が発生しているユーザー数。1 人ですか？それとも全員ですか？

2. この問題が新規セットアップに関するものか、既存の統合が突然動作しなくなったものか

3. 影響を受けているアプリケーションの数

4. 期待される動作と現在の動作

5. ユーザーがログインシーケンスのどこまで進めるか

6. Auth0 に登録されているアプリケーションの名前と、使用しているアイデンティティプロトコル

7. 関係する接続の名前

8. Auth0 Lock ウィジェットを使用しているかどうか (使用している場合はバージョン)

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

10. .har ファイルの SSO インタラクションの HTTP トレース

    HAR ファイルを他者 (Auth0 を含む) と共有する前に、次のような機密データをすべて削除するか、難読化してください。

    • 機密性の高いユーザー情報
    • 個人を特定できる情報 (PII)
    • 機密性の高いアプリケーション情報

    詳細については、Auth0 Community の以下の記事を参照してください。

    • HTTP トレースのサニタイズ
    • HTTP トレースファイルを自動的にサニタイズする方法
    • 機密情報を手動でマスクする方法
    • HAR ファイルが大きすぎてサポートケースにアップロードできない

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

12. 関係するサードパーティアプリケーション (Sharepoint など) の認証ログファイル

詳細情報

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