RADIUSセッション永続化のベストプラクティス

セッション永続化

Okta RADIUS Serverエージェントとロードバランサーをデプロイする場合、Oktaでは、セッション永続性またはスティッキーセッションを使用することを推奨しています。要素チャレンジのユーザー入力が非同期に処理される状況では、セッション永続化が重要です。非同期の多要素チャレンジでは、複数のリクエストまたは重複するリクエストが生成されます（たとえば、プッシュ通知でOkta Verifyを使用する場合など）。

Okta RADIUS Serverエージェントは、発信元のRADIUSクライアントからの複数のリクエストを処理します。ただし、セッション永続性がないためにリクエストが複数のエージェントに分散している場合、それらのリクエストはOktaサービス側でのみ処理されます。これにより、RADIUS ServerエージェントとOktaサービスの両方に不要な負荷がかかります。この余分な負荷は、Oktaサービスのレート制限に対しても不利に働きます。

パフォーマンスを最適化するには、エンドユーザーのVPNクライアントまたはIPアドレスに基づきセッション永続化を設定します。セッション永続化の推奨構成は、Calling-Station-IDをFramed-IP値と組み合わせて使用することです。通常、ほとんどのVPNでは、Calling-Station-IDは発信元クライアントのIPアドレスです。

別のRADIUS属性を使用してクライアントのIPアドレスを保存する場合、その属性を使用するようにロードバランサーを構成します。

欠点と制限

Oktaは、高可用性と水平スケーリングを提供するためにロードバランサーを推奨していますが、セッション永続化なしのロードバランサーの背後にRADIUS Serverエージェントをデプロイすることもできます。セッション永続化なしで負荷分散を使用すると、Okta RADIUS Serverエージェントが提供する、リクエストの重複を減らすという利点が失われます。

RADIUSはコネクションレス型のUDPプロトコルを使用します。ほとんどのクライアントは、RADIUS Serverエージェントから応答を受信するまで、リクエストを一定間隔で自動的に再送信します。これらの再試行が別のRADIUS Serverエージェントに送信された場合、各エージェントはリクエストを同時に試行します。Oktaからの応答を最初に受信したエージェントがクライアントに応答し、他のエージェントは通常のタスク処理のみを実行します。

通常、新しいリクエストを最初に受信したRADIUS Serverエージェントが最初に応答します。これは、クライアントが再試行リクエストを発行する前に、そのエージェントが呼び出しを行い、応答を受信するためです。ただし、Okta Verifyとプッシュ通知要素を使用する場合、リクエストを受信するRADIUS Serverエージェントは、ユーザーがリクエストを確認または拒否するまで、Oktaをポーリングします。この間、RADIUSクライアントは同じリクエストの再試行を送信する可能性があります。このシナリオで、再試行が同じRADIUS Serverエージェントに送信された場合、そのエージェントはそれらを重複と認識し、ドロップします。

ただし、再試行が別のRADIUS Serverエージェントにルーティングされた場合、そのエージェントはそのリクエストを新規リクエストとして処理し、再びプッシュ通知を開始します。この動作の影響を最小限に抑えるため、セッション永続性なしの負荷分散環境にデプロイする場合には、RADIUSクライアントの再試行間隔を30秒以上に設定することをお勧めします。このアプローチにより、RADIUSクライアントが再試行を開始する前に、エンドユーザーが通知を受信して応答する時間を確保できます。ロードバランサーにセッション永続性がない場合、RADIUS Serverエージェントにリクエストのキューが大量に溜まる可能性があります。これにより、競合状態が発生する可能性があります。

十分なエージェントワーカースレッドが構成されていない場合、または実行時間の長いリクエストによってすべてのスレッドが消費された場合にも、競合状態が発生する可能性があります。実行時間が長いリクエストの送信元は、Oktaサービスからの応答が遅いためにプッシュ通知操作が待機状態となっているOkta Verifyである可能性があります。Oktaサービスは、ユーザーを認証するためにオンプレミスのActive Directoryエージェントにアクセスする必要があります。この場合も、再試行が問題になります。これは、再試行が他のエージェントに負荷分散された場合、それらの再試行は、リクエストを最初に処理するエージェントによって処理されるためです。これは一般的に安全なシナリオですが、どのエージェントが結果を返しても、このような競合状態によってシステムのデバッグが困難になります。