ベストプラクティス

ほとんどの顧客は異種混合のプライベートアプリケーションポートフォリオを持っています。一部は自社開発、一部は内部管理サービス、一部はSSO統合が利用可能であり、一部はHTMLやその他の認証形式に依存しています。これを考慮して、各アプリケーションのニーズに合わせてオンボーディングソリューションを組み合わせることをお勧めします。以下の表に示すように、アプリケーションを実装の容易さと組織全体への影響を優先する一連のスタックランクカテゴリに分類できます。

アプリケーションタイプ	推奨事項	結果
統合SSOのないプライベートウェブアプリ	アプリケーションをCloudflareドメインのみに表示します。	ユーザーはCloudflareに委任された新しいドメインでアプリケーションにアクセスし、Cloudflare統合を通じてSSOを即座に適用します。
統合SSOのあるプライベートウェブアプリ	SSO構成が可能な場合: アプリケーションをCloudflareドメインのみに表示します。 SSO構成が不可能な場合: 既存の内部ドメインにアプリケーションを表示し、Cloudflareに委任された同一の外部ドメインを使用します。	ユーザーはCloudflareの同じまたは新しいドメインから内部ウェブサービスにアクセスします。構成されている場合、SSOプロバイダーは内部ドメインからCloudflareの権威ある外部ドメインにユーザーを透過的にリダイレクトします。
新たに開発中の重要な内部アプリケーション	アプリケーションをCloudflareドメインのみに表示します。	開発者は、SAMLまたはOIDC統合のためにアプリケーションのリダイレクトを表す新しいパブリックホスト名をCloudflare上でプログラム的に生成（または付与）できます。
新たに開発中のマイクロサービス	アプリケーションをCloudflareドメインのみに表示します。 オプションとして、内部アプリケーションでの認証としてAccess JWTを使用します。	開発者は、アプリケーションのコードベースにJWT認証メカニズムを直接組み込み、Terraformを使用してアプリケーションのためにCloudflareのホスト名とポリシーを自動的に構築できます。
内部APIエンドポイント（外部/内部APIに依存する内部アプリケーションを含む）	Cloudflareドメイン上で内部APIを表示し、サービストークンを受け入れるAccessポリシーを構築します。	自動化されたシステムはリクエストヘッダー内のサービストークンを介して認証でき、エンドユーザーは引き続き自分のIdPを通じてログインします。