BIG-IPのForward Proxy構成におけるBASIC認証のタイムアウト関連の情報を整理します。
前提情報
BASIC認証用のAccess Profiles (Per-Session Policy)は作成済みの想定とします。まだ作成していない場合は、下記の記事を参考にしてください。
バージョン情報
本記事は下記のバージョンで検証を行っております。
- F5 BIG-IP Virtual Edition Version 17.0.0
BIG-IPのモジュールは、LTM, APMを有効化しております。なお、SSLOのモジュールを有効化していましたが、機能的にはSSLOには依存していません。
BASIC認証の設定方法
メニュー:
Access> Profiles / Policies > Access Profiles (Per-Session Policies)を開きます。
メニュー: Access> Profiles / Policies > Access Profiles (Per-Session Policies) 予め作成していたBASIC認証のAccess Profile (Per-Session Policy)の設定を開きます。(Access Profile Nameのリンクを押下します。)
BASIC認証のAccess Profile (Per-Session Policy)の設定 Access Profile (Per-Session Policy)の下記の設定項目を適宜調整します。
設定項目 動作の説明 Inactivity Timeout 指定秒数の無通信の時間が発生してタイムアウトすると認証セッションが切断されます。 Maximum Session Timeout 認証セッションの最大秒数を指定します。無通信の時間が発生していなくても最大時間に到達してタイムアウトすると認証セッションが切断されます。 
認証タイムアウトの設定項目 設定の変更後は、画面の左上より
Apply Access Policyボタンを押下します。
Apply Access Policy
BASIC認証の認証セッションの確認方法
メニュー:
Access > Overview > Active Sessionsから認証セッションの確認ができます。
メニュー: Access > Overview > Active Sessions 認証タイムアウトの設定を確認するには、該当セッションの
Variables列からViewのリンクをクリックします。
Variables 列の View リンク 下記の変数の値を確認すると、認証セッションのタイムアウトが反映されているかを確認できます。
変数名 説明 <SessionID>.session.inactivity_timeout Inactivity Timeout に対応します。 <SessionID>.session.max_session_timeout Maximum Session Timeout に対応します。 
認証セッションのタイムアウトの変数
BASIC認証が実質的にタイムアウトしないパターン
BASIC認証が実質的にタイムアウトしないパターンを紹介します。
まず前提情報として、BASIC認証はHTTP Headerに認証情報が載ります。
下記は curl コマンドでBASIC認証で使用される Proxy-Authorization のRequest Headerを確認した際の出力例です。
$ curl --proxy 198.51.100.123:8080 --proxy-user 'testuser:PASSWORD' http://www.example.com --verbose * Expire in 0 ms for 6 (transfer 0x7fffc8c4cfb0) * Trying 198.51.100.123... * TCP_NODELAY set * Expire in 200 ms for 4 (transfer 0x7fffc8c4cfb0) * Connected to 198.51.100.123 (198.51.100.123) port 8080 (#0) * Proxy auth using Basic with user 'testuser' > GET http://www.example.com/ HTTP/1.1 > Host: www.example.com > Proxy-Authorization: Basic dGVzdHVzZXI6UEFTU1dPUkQ= > User-Agent: curl/7.64.0 > Accept: */* > Proxy-Connection: Keep-Alive (snip)
Proxy-Authorization: Basic dGVzdHVzZXI6UEFTU1dPUkQ= の出力の部分がBASIC認証に関係があります。資格情報はBase64でエンコードされています。
下記はBase64の資格情報をデコードした例です。
$ echo -n 'dGVzdHVzZXI6UEFTU1dPUkQ=' | base64 --decode testuser:PASSWORD
ちなみに、--proxy-user による資格情報の指定を無しにすると HTTP 407 のRsponse Codeが返ってきて認証を要求されます。
$ curl --proxy 198.51.100.123:8080 http://www.example.com --verbose * Expire in 0 ms for 6 (transfer 0x7ffff3fb8fb0) * Trying 198.51.100.123... * TCP_NODELAY set * Expire in 200 ms for 4 (transfer 0x7ffff3fb8fb0) * Connected to 198.51.100.123 (198.51.100.123) port 8080 (#0) > GET http://www.example.com/ HTTP/1.1 > Host: www.example.com > User-Agent: curl/7.64.0 > Accept: */* > Proxy-Connection: Keep-Alive > < HTTP/1.1 407 Proxy Authentication Required < Date: Wed, 25 May 2022 11:45:04 GMT < Server: BigIP < Content-Length: 292 < Connection: close < Content-Type: text/html; charset=utf-8 < X-Frame-Options: DENY < Pragma: no-cache < Cache-Control: no-cache, must-revalidate < Proxy-Authenticate: Basic realm="" (snip)
ここで重要な要素になるのは、HTTP HeaderにBASIC認証の正しい資格情報を常に載せていると、HTTP 407の認証要求が返ってこない点です。
表現を変えると、前回の認証セッションが既にタイムアウトしていたとしても、BASIC認証の正しい資格情報がHTTP Headerに載っていれば即時的に再認証がかかります。
そのため、実質的に認証セッションのタイムアウトが意味を成さないパターンが想定されます。 具体例としては、Web BrowserでBASIC認証の資格情報がキャッシュされていて、Web Browserを終了するまで資格情報が消えないパターンが想定されます。
かと言って、上述のパターンを想定してタイムアウトの値を短くしすぎると問題が出る可能性もあります。
例えば、Web BrowserでBASIC認証を行って認証セッションを開始したものの、タイムアウトの値が短すぎて認証セッションが短い間隔で切れてしまうと、バックグラウンドで行われているシステム系の通信などは再認証がかかるまで通信できなくなるかもしれません。
またその回避策として特定の宛先への通信をBASIC認証の対象から除外する場合は、BIG-IP Forward Proxyの標準機能では宛先指定の認証除外に対応していないため、iRulesによるコード拡張での対応が必要になります。
関連ドキュメント
BASIC認証のHTTP Headerに関連するドキュメントのリンクを掲載します。
