多くのお客様は、性質の異なるプライベートアプリケーションを抱えています。自社開発、社内のマネージドサービス、SSO 連携が使えるもの、HTML など別の認証に依存するものが混在します。そのため、アプリケーションごとに 導入方法 を組み合わせることを推奨します。次の表のとおり、実装のしやすさと組織全体への影響を基準に、アプリケーションを優先度付きのカテゴリに分類できます。
| アプリケーションの種類 | 推奨 | 結果 |
|---|---|---|
| 統合 SSO がないプライベート Web アプリ | アプリケーションを Cloudflare ドメイン上でのみ公開する | ユーザーは Cloudflare に委任した新しいドメインでアプリケーションにアクセスし、Cloudflare 連携を通じてすぐに SSO を適用します。 |
| 統合 SSO があるプライベート Web アプリ | SSO を設定できる場合: アプリケーションを Cloudflare ドメイン上でのみ公開する SSO を設定できない場合: 既存の内部ドメインでアプリケーションを公開し、同一の外部ドメインを Cloudflare に委任する |
ユーザーは、同じドメインまたは新しいドメインで、Cloudflare 経由の内部 Web サービスにアクセスします。設定済みの場合、SSO プロバイダーは内部ドメインから Cloudflare が権威を持つ外部ドメインへ、透過的にユーザーをリダイレクトします。 |
| 開発中の重要な新規内部アプリケーション | アプリケーションを Cloudflare ドメイン上でのみ公開する | 開発者は、SAML または OIDC 連携のリダイレクト先として、Cloudflare 上の新しい公開ホスト名をプログラムで生成する（または付与される）ことができます。 |
| 開発中の新規マイクロサービス | アプリケーションを Cloudflare ドメイン上でのみ公開する 任意で、内部アプリケーションの認証として Access JWT を利用 する。 |
開発者は、アプリケーションのコードベースに JWT 認可の仕組みを直接組み込み、Terraform を使って Cloudflare のホスト名とポリシーを自動作成できます。 |
| 内部 API エンドポイント（外部 / 内部 API に依存する内部アプリケーションを含む） | 内部 API を Cloudflare ドメイン上で公開し、ユーザー向けポリシーに加えて サービストークン を受け入れる Access ポリシーを作成する。 | 自動化システムは リクエストヘッダーのサービストークン で認証でき、エンドユーザーはこれまでどおり IdP でログインします。 |