VPN SSO は社内アプリへのサインインを自動で行いますか？

ID プロバイダー経由で認証する VPN ゲートウェイが証明するのは 一つだけです。プロバイダーが利用者をゲートウェイに対して保証した、ということです。それはその利用者に、イントラネットの Wiki、監視ダッシュボード、ビルドサーバー用の資格情報を渡すものではありません。これらのサービスは独自のフェデレーションで人をサインインさせ、独自の認可を適用します。トンネルはどのパケットがそこへ届くかだけを決めます。

三つのセッション、三つの別々の判断

状態は分けて保ちます。それぞれが独自のスケジュールで失効するからです。VPN セッションは、ゲートウェイが ID を受け入れたことと、付与したネットワークアクセスです。ID プロバイダーのブラウザーセッションは、ブラウザーがそのプロバイダーに対して保持しているもので、ポリシーに従って再利用できます。アプリケーションセッションは、自分宛ての応答を検証した 一つのサービスに属します。

これらの状態を混同すると、問いがずれます。ふつうは「なぜトンネルはあらゆる場所でサインインさせないのか」という形になります。言い換えてください。どのアプリにフェデレーションの登録がないのか、どれが利用者を拒否するのか、どれにルートがないのか。イントラネットのアプリを開く 一回のサインイン要求でも、プロバイダーへ戻ることがあります。二回目のリダイレクトは別のオーディエンス向けの新しい認可要求だからです。

ゲートウェイを独自のアプリとして接続する

VPN をプロバイダーの承認済みアプリとして登録し、独自の識別子、リダイレクト URI、利用者の割り当てを持たせます。次に、そのサインインがどのネットワーク認可を与えるかを決めます。これはプロバイダーの機能ではなく VPN のポリシーです。監視サブネットだけに届くべき利用者には別のゲートウェイポリシーを与え、別のパスワードを与えてはいけません。

トンネルの認証応答は再利用できる資格情報ではありません。OIDC の ID トークンは、どのクライアント向けに発行されたかを示すオーディエンス要求を含み、SAML のベアラーアサーションはオーディエンスを受け取るサービスプロバイダーに限定します。最初のサービスの応答を受け入れる 二つ目のサービスは設定ミスであり、トークンを別のアプリへコピーすることは統合ではありません。

社内アプリを 一つずつ登録し、ブラウザーのコンテキストを整える

各サービスには対応する SAML または OIDC の値が必要です。発行者、クライアント識別子、コールバックまたはアサーションコンシューマーの URL、必要なクレーム、割り当てです。到達性はその上に乗ります。ID の確認がルートや DNS の応答を与えることは決してないからです。

1. アプリの登録を作成し、エンティティ ID またはクライアント ID がアプリの送るものと一致することを確認します。
2. スキームとポートを含む正確なコールバック URL を登録します。わずかな違いでも、利用者の認証後に失敗します。
3. 利用者またはグループを割り当て、必要なクレームが発行されることを確認します。
4. プライベートアプリだけでなく ID プロバイダーのエンドポイントも許可します。そうしないとリダイレクトが完了しません。

ブラウザーのコンテキストが、既存のプロバイダーセッションを再利用するかを決めます。システムブラウザーを開くネイティブクライアントはその状態を共有できますが、独自の Cookie ジャーを持つ埋め込み表示は通常できません。新しいブラウザー、プライベートウィンドウ、二つ目のプロファイルはゼロから始まります。これは想定内で、SSO の設定が壊れているわけではありません。

フローを実行し、どこで止まるかを読む

ブラウザーのネットワークパネルで再現し、リダイレクトの連鎖を観察します。役立つ手順は 一ホップずつ追うことです。ゲートウェイからプロバイダーへ、プロバイダーからコードまたはアサーションとともにアプリへ、アプリからプロバイダーのトークンエンドポイントへ、アプリのセッションが発行される。連鎖が止まるホップが、直すべきコンポーネントを示します。

コマンドラインの 二つの確認でよくある疑問は片付きます。どちらも管理ホストから実行して安全です。

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

メタデータに、登録したことのないエンドポイントが並んでいれば、アプリは別のテナントや発行者を指しています。アプリへの最初の要求が予期しないホストへ 302 を返すなら、見るべきはアプリのフェデレーション設定であり、VPN プロファイルではありません。

誰が要求したかを見つけてプロンプトを直す

二回目のパスワード要求は自動的に欠陥ではありません。アプリがより高い保証レベルを求めているか、プロバイダーがセッションの最長期間と新たなチャレンジを強制している可能性があります。フローを静かにするためにこれらの要件を外すと、意図的な統制が弱まります。ポリシーを変える前に、どのコンポーネントが要求したかを確かめてください。

次に何を改善するかを決めます。プロンプトがアプリ由来なら、そのフェデレーション登録を直します。ポリシーによりプロバイダー由来なら、要件を文書化します。サインインに成功した後でアプリに届かないなら、疑わしいのはトンネルのルーティングです。なぜならID とパケットの配送は別の場所で失敗するからで、利用者の席からは同じに見えます。