AWS Client VPN SAML と Google Workspace：コールバックの空白

app_not_configured_for_user のページは Google Workspace から返され、トンネルのパケットが一つもネゴシエートされる前に表示されます。この順序が診断のすべてです。クライアントの再インストール、プロファイルの編集、ルートの確認では、VPN エンドポイントがまだ見ていないページを消すことはできません。失敗しているのは、ID プロバイダーと利用者自身のマシン上のリスナーとの間のブラウザーでの受け渡しであり、その受け渡しで確認する価値があるのはちょうど三つです。

そのページを ID プロバイダーの表明として読む

Google は、サインインしたアカウントに対して SAML アプリケーションが有効になっていないときにこれを返します。アプリが無効になっている、利用者が割り当てられた組織部門やグループの外にいる、あるいはサービスプロバイダーの設定が要求と一致していない、という可能性があります。

どれも証明書、ルート、トンネルの問題ではありません。利用者が気づいたのが VPN クライアントの中だったとしてもです。

クライアントが受け付ける二つの値

AWS Client VPN はサービスプロバイダー起点の SAML 交換を行うため、クライアントがブラウザーを開き、利用者が認証し、プロバイダーが署名済みアサーションを Assertion Consumer Service の URL に返します。AWS が提供するデスクトップクライアントではその URL は loopback 上のリスナーで、通常はポート 35001 であり、期待されるオーディエンスは AWS コンソールのサインインエンティティではなく Client VPN SAML アプリケーションのエンティティ識別子です。

どちらの値もクライアントの期待と一致しなければなりません。アサーションをどこに送るか、誰宛てにするか、という二点です。コンソールの SSO アプリケーションからコピーした設定は十分に筋が通って見えても、間違った組み合わせを指していることがあります。

両方の値は Client VPN SAML の要件から取り、AWS の一般的なシングルサインオンの手引きから取らないでください。コンソールの SSO エンティティは魅力的に見えるほど似ています。別のアプリケーションでありオーディエンスも違い、クライアントは説明もなくアサーションを拒否します。組み合わせは一度だけコピーし、プロファイルのそばに保管してください。

Google は平文 HTTP のコールバックを受け付けない

管理コンソールは HTTPS の ACS URL を要求しますが、クライアントのコールバックは loopback 上の平文 HTTP です。その値は Workspace のアプリ設定にそもそも入力できません。だからこそ一部のチームは TLS を終端してローカルのリスナーへ転送するリバースプロキシを試します。しかし不一致は直りません。ブラウザーが見るオリジンとクライアントが告知するオリジンが違い、返される応答が誤った宛先に届くことがあります。

機能するのはブローカー型の ID プロバイダーです。ブローカー側の SAML アプリケーションが loopback のコールバックと AWS のオーディエンスを受け取り、ブローカーが Workspace アカウントを上流でフェデレーションします。Google の HTTPS 要件は満たされたままで、クライアントに届くアサーションは期待するアドレスとオーディエンスを依然として示します。

そのブローカーは、誰かが所有し、監視し、退職処理にも含めなければならない運用上の依存です。障害がログイン失敗に変わる二つ目の場所でもあります。設計を約束する前にコストを見積もってください。誰も所有しないなら、AWS クライアントは Workspace を唯一の ID プロバイダーにはできない、というのが正直な答えです。

割り当てと二段階認証

何かを設計し直す前に、アプリが正しい組織部門やグループに対して有効になっていること、サードパーティの SAML アプリには Google 側のアプリ一覧とは別の独自の割り当て制御があることを確認してください。

アカウントで二段階認証が有効かどうかも確認してください。Google は SAML アプリが利用者に使えるようになる前にそれを要求することがあり、元のスレッドの一つの回答はまさにその方法で解決しました。除外するのに最も安く、最後に発見すると最も厄介な項目です。

きれいなセッションで検証する

変更の後は、新しいブラウザープロファイルとクリーンなクライアント設定でテストしてください。キャッシュされたアサーションや再利用されたセッションは、修正が効いたかどうかを隠します。

次に二つの記録を並べて比較します。ID プロバイダーの監査イベントとクライアントのログです。トンネルなしのサインイン成功はコールバックかオーディエンスを指します。接続はできるがリソースに到達できないトンネルはルーティングか認可の問題で、まったく別の場所に属します。

変えてはいけないもの

ページを通過するためにプロファイルから auth-federate を外したり、証明書の確認を無効にしたりしないでください。どちらも失敗しているコールバックではなく認証の設計を変えるもので、どちらも次のクライアント更新で壊れがちです。

代わりに受け渡しを直し、ブローカー、オーディエンス、loopback のポートを記したメモを残してください。次にこのページを見る人には三つとも必要です。