統合SSOを持つアプリケーション

過去数年間、多くの組織が真実の情報源としてのアイデンティティの重要性を認識し、内部アプリケーションと直接統合されたSSOプロバイダーを導入しました。SSOプロバイダーは、アプリケーションが存在する内部ドメイン（構成されたACS URLを介して）を認識しているだけであり、ユーザーはアプリケーションにアクセスするためにローカルネットワークに接続している必要があります。このセキュリティアーキテクチャは、従来のネットワーク境界に対しては理にかなっていますが、ゼロトラストの採用には課題をもたらします。ZTWAモデルでは、ユーザーのデバイスは内部の企業ネットワークの概念を持たず、アクセスできる特定のスコープを持つアプリケーションのみを認識します。問題は以下の図に要約されています：

flowchart LR
accTitle: 統合SSOを持つ認可フロー
A("ユーザーが
app.public.comにアクセス")-->B("Cloudflare Tunnelが
パブリックホスト名（app.public.com）を
内部ドメイン（app.internal.com）にルーティング")-->C("app.internal.comが
統合SSOにリダイレクト")-->D("SSO ACS URLが
app.internal.comを返す")-->E("404エラー
デバイスが
app.internal.comを解決できません")

潜在的な解決策

アプリケーションが統合SSOを使用している場合、Cloudflare Accessにアプリケーションをオンボードするためのさまざまな方法があります。

解決策	必要なステップ	利点	欠点
アプリケーションをCloudflareドメインのみに表示	SSO ACS URLをCloudflare Tunnelのパブリックホスト名に変更	セキュリティ姿勢の向上 アプリケーションコードの変更なし 内部DNS設計の変更なし	ACS URLが内部から外部ドメインに変更される際のハードカットオーバーイベント
既存の内部ドメインにアプリケーションを表示し、Cloudflareに委任された同一の外部ドメインを持つ	内部ドメインに一致するドメインをCloudflareに追加	SSO ACS URLの変更なし エンドユーザーに変更なし	内部および外部ドメインの慎重な管理が必要 内部DNS設計の変更が必要
内部アプリケーションでCloudflare JWTを使用する	統合SSOを削除 アプリケーションを更新してユーザー認証のためにCloudflare JWTを受け入れる	エンドユーザーの認証負担の軽減 内部DNS設計の変更なし 直接的なSSO統合なしでアプリケーションを即座に保護	アプリケーションコードの変更が必要 アプリケーションの更新時のハードカットオーバーイベント
Cloudflareを直接のSSO統合として使用し、選択したIdP（Okta、OneLoginなど）を呼び出す	既存のSSOプロバイダーをAccess for SaaSに置き換える	IdPの変更に対する柔軟性の向上 複数のIdPを同時に使用する能力	IdP変更時のハードカットオーバーイベント アプリケーションのSCIMプロビジョニングなし

推奨解決策

SSOプロバイダーを構成できる場合は、すべての内部WebサービスをCloudflareドメインのみに表示することをお勧めします。これは、Cloudflareが内部でWebアプリケーションアクセスのために採用しているモデルであり、このシナリオでの顧客にとって最も一般的な解決方法です。

このアプローチでは、既存のDNSインフラストラクチャに変更を加える必要はありません。ネットワーク内のCloudflare Tunnelが、外部（Cloudflareパブリック）DNSから内部DNSへの翻訳を管理します。これは、システムが機能するように設計されています。SSOプロバイダーのACS URLをCloudflareのパブリックホスト名に更新すると、結果は次のようになります：

flowchart LR
accTitle: 更新されたSSO ACS URLを持つ認可フロー
A("ユーザーが
app.public.comにアクセス")-->B("Cloudflare Tunnelが
パブリックホスト名（app.public.com）を
内部ドメイン（app.internal.com）にルーティング")-->C("app.internal.comが
統合SSOにリダイレクト")-->D("SSO ACS URLが
app.public.comを返す")-->E("ブラウザがapp.public.comを表示")

すべてのユーザー - オフィスにいる場合、リモートである場合、VPNクライアントを使用している場合でも使用していない場合でも - 常にapp.public.comでCloudflare Access認証フローを経由してプライベートアプリケーションにアクセスします。これにより、ポリシーの適用とセキュリティ監査のための単一の制御プレーンが提供され、追加のユーザートレーニングは必要ありません。