フェデレーション VPN ログインのブラウザステップで起きること

「接続」を押すと、パスワード欄の代わりに VPN クライアントがブラウザを開く。この受け渡しは、トンネルが自分で認証すると期待する人を戸惑わせる。ブラウザは回り道ではない。ID プロバイダーが実際に本人を認証するのはそこであり、クライアントは結果を待つだけだ。

一つのサインインを最初から最後まで追うと、それぞれの失敗がどのステップに属するかが見える。多くのランブックが飛ばしているのはまさにこの部分だ。

ゲートウェイの設定ではなくクライアントから始める

クライアントは要求を組み立て、サービスプロバイダー識別子と戻り先を付けてブラウザを ID プロバイダーへ送る。次に組織の IdP が設定された処理を実行する。パスワード、MFA、デバイス検査、条件付きアクセスだ。ブラウザにすでに有効なセッションがあれば、見える部分は一、二秒で終わることもある。その短さはセッションの再利用であり、検査を飛ばしたのではない。

何よりも先に、クライアントのフェデレーション設定で二つの値を読む。信頼する IdP のメタデータか URL、そして期待するコールバックアドレスだ。そこが食い違うと、パスワードを入力する前に失敗する。

ID プロバイダーが返さなければならないもの

IdP は署名された SAML 応答で答える。そこにはアサーションが含まれる。誰が主体か、誰が発行したか、誰向けか、いつまで有効か。これらの項目が契約だ。発行者、オーディエンス、受信者、有効期間はすべてサービスの期待と一致しなければならない。

正しい IdP が署名していても、別のオーディエンス宛ての応答は無効のままだ。ラボから本番へメタデータをコピーするときに飛ばされがちな検査がこれだ。

VPN サービスが信頼する前に検証すること

サービスは信頼する証明書で署名を検証し、発行者、オーディエンス、受信者を確認してから、時間の条件を評価する。その後にようやくアサーションをユーザーやグループに対応づけ、VPN の認可ポリシーを適用する。ここでは認証と認可は別のステップであり、対応するグループのない有効なアサーションでは、接続はできても何にも届かないセッションになる。

アサーションは認証の材料であり、パスワードではない。別のクライアントに貼り付けたり、後の再接続のために取っておいたりするのは、サポートされたログインではない。

別々に終わる二つの寿命

IdP のブラウザセッションとゲートウェイの VPN セッションは別々の時計で切れる。IdP からサインアウトしても確立済みのトンネルが必ず切れるわけではなく、トンネルを切断してもブラウザからサインアウトされるわけではない。

AWS Client VPN は、そのフェデレーションフローが SAML のシングルログアウトに対応しないと文書化している。この隙間の具体的な例だ。対称性を前提にせず、自分のサービスを確認してほしい。

だから再接続は 09:00 と 15:00 で挙動が違う。IdP セッションを黙って再利用することも、MFA を再度求めることも、エンドポイントのセッション期間が切れたのにブラウザセッションが残っているために失敗することもある。AWS のフェデレーションワークフローは自らのクライアントと応答の要件を説明しており、他のサービスは別の受け渡しを使う。

ブラウザステップが失敗したら、この順に確認する

ブラウザから外側へ進める。エラーメッセージは通常、最初ではなく最後のホップを示すからだ。

ページがまったく読み込まれないなら、クライアントの IdP URL かそこへの経路が間違っている。IdP が要求を拒否するなら、サービスプロバイダー識別子かコールバックが設定と合っていない。ブラウザが成功を示すのにクライアントが失敗するなら、応答が誤った場所に届いたか、オーディエンスと時間の検証に失敗している。トンネルが上がってもアクセスできないなら、アサーションは受け入れられたがグループ対応づけがされていない。

期待するページ、コールバック、グループ対応づけを一つの文書にまとめておく。そうすれば VPN ログインが壊れたと報告するユーザーは、この四つのどれを見たかを言え、答えはすでに半分書けている。