APMポータルアクセス：アプリケーションのセッションは誰のものか

BIG-IP APM Portal Access でイントラネットのアプリケーションを公開するのは、仮想サーバーをコピーする話ではなく、セッションの話である。ポータルはユーザーを受け入れ、書き換えプロファイルは選ばれたリクエストをゲートウェイの経路上に保ち、アプリケーションは依然として独自のセッションを持つ。五つの確認が、予測どおりに動く設計と、ヘルプデスクがタイムアウトを一人ずつ知ることになる設計とを分ける。順番に実施し、最初に当てはまらない確認で止める。

確認 1：リソースは公開されているか、単にリンクされているだけか

webtop のブックマークは、ユーザーがエントリを見られることを示す。アプリケーションが公開されていることは示さない。アクセスプロファイル、書き換えプロファイル、それらを組み合わせる仮想サーバーを確認し、リソースの割り当てが想定したアプリケーションを指していることを確かめる。三つのうちどれかが欠けているか矛盾していれば、残りの一覧は意味をなさない。

半分だけ公開された状態は、入口では健全に見える。仮想サーバーがアクセスプロファイルを持つ一方で、書き換えプロファイルが別のリソース URI に限定されているため、webtop のエントリは表示され最初のページは読み込まれるが、その後サブパスのリクエストはゲートウェイの経路を離れてバックエンドに直接届く。逆の姿は、誤ったアプリケーションに割り当てられたリソースである。ブックマークは開き、誰も承認していないものを開く。

確認 2：バックエンドのセッションは別の状態である

APM がユーザーをサインイン済みと見なしていても、バックエンドが独自の認証を要求することがある。対応する SSO 連携はその関係を構築するが、ポータルのログインを受け入れたからといって、すべてのアプリケーションが同じ資格情報や同じセッション Cookie を受け入れるわけではない。リソースに SSO が設定されていなければ、アプリケーションはすでに認証済みのポータルの中で独自のログインを求める。

表示されるプロンプトを変えるために SSO を無効にするのは、よくある悪い近道である。プロンプトを生んだライフサイクルに触れずに認証の設計を変えてしまう。代わりに、バックエンドのログインをそもそも表示すべきかを決め、表示すべきなら公開フローの明示的な一部にする。

確認 3：時計は二つあり、同じ時計ではない

APM のアクセスプロファイルは無操作タイムアウトと最大セッション寿命を持つ。アプリケーションは独自のアイドルタイマーと Cookie の有効期限を持つ。ポータルのタイマーを延ばしてもアプリケーションのセッションは延びず、アプリケーションのセッションを縮めてもユーザーはポータルからログアウトしない。

定番のサポート電話は、かみ合わない組み合わせから生じる。ポータルはまだ有効で、アプリケーションのセッションは切れており、ユーザーにはポータルと矛盾するように見えるログインフォームが表示される。これは故障ではなく正しい動作であり、解決策はこのアプリケーションでどちらの時計を先に切らすかを選ぶことである。

確認 4：ログアウトには定義された範囲がある

アプリケーションのサインアウトボタンが何を終わらせるべきかを書き出す。そのアプリケーションだけか、APM セッション全体か、それとも ID プロバイダーのより広いセッションか。アクセスプロファイルは任意の遅延付きログアウト URI リストをサポートしており、要件がそれならアプリケーションのログアウトでポータルのセッションを終わらせられる。それがなければ、アプリケーションのログアウトはポータルを生かしたままにし、次のリクエストがユーザーを静かに再びサインインさせることがある。

同じポータル内の他のリソースへの影響を見積もる。一つのアプリケーションからのログアウトが他六つのセッションを終わらせるなら、その動作を事前にアプリケーションの所有者と合意していない限り、ユーザーは不具合と呼ぶ。タブを閉じて webtop に戻ることは、何かが終わった証拠ではない。

確認 5：アプリケーションは書き換えを生き延びる

Portal Access は選ばれた Web コンテンツを書き換えるが、書き換えには限界がある。現代のクライアント側機能、バックグラウンドワーカー、アップロードの流れ、フェデレーションログインは、特定のリリースが扱う範囲の外に出ることがある。F5 のバージョン別の互換性マトリックスは、コミットする前に読むべき文書である。制限はリリースごとに異なるからだ。

ランディングページではなく重要な流れを試す。サインインし、必要な機能をたどり、アップロードするならアップロードし、想定したセッションを失効させ、すべてのログアウト経路をたどる。一度描画されたページは、アプリケーションが動く証拠ではない。

必要な流れを書き換えられない場合は、文書化されたフェデレーション、リバースプロキシ、ネットワークアクセスの設計に移る。一般的なトンネルのように振る舞うことを求められたブラウザポータルは、デモは通っても監査で落ちる。