Cloudflare Docs
Learning Paths
Cloudflare Docs
Deploy Zero Trust Web Access (Learning Path)
GitHub icon
Edit this page on GitHub
Set theme to dark (⇧+D)
  1. Learning Paths
  2. Deploy Zero Trust Web Access
  3. Migrate applications
  4. Applications with integrated SSO

Applications with integrated SSO

  3 min read

Many organizations in the past few years have recognized the importance of source-of-truth identity and have directly integrated their SSO provider with their internal applications. The SSO provider is only aware of the internal domain on which the application exists (via the configured ACS URL), which means the user must be connected to the local network in order to access the application. This security architecture makes sense for a traditional network perimeter, but it presents challenges for Zero Trust adoption. In the ZTWA model, the user’s device has no concept of an internal corporate network, only the specific, scoped applications to which they have access. The problem is summarized in the following diagram:

​​ Potential solutions

If your applications use integrated SSO, there are a number of different paths you can take to onboard your applications to Cloudflare Access.

SolutionSteps requiredPros
Cons
Present applications exclusively on Cloudflare domainsChange SSO ACS URL to the Cloudflare Tunnel public hostname
  • Increased security posture
  • No changes to application code
  • No changes to internal DNS design
    		• Hard cutover event when ACS URL changes from internal to external domain
    Present applications on existing internal domains with identical external domains delegated to CloudflareAdd domains to Cloudflare that match internal domains
  • No changes to SSO ACS URL
  • No change for end users
  • Requires careful management of internal and external domains
  • Requires changing internal DNS design
    • Consume the Cloudflare JWT in internal applications
  • Remove integrated SSO
  • Update application to accept the Cloudflare JWT for user authorization
  • Reduced authentication burden for end users
  • No changes to internal DNS design
  • Instantly secure applications without direct SSO integration
  • Requires changing application code
  • Hard cutover event when application updates
    • Use Cloudflare as the direct SSO integration, which then calls your IdP of choice (Okta, OneLogin, etc.)Swap existing SSO provider for Access for SaaS
  • Increased flexibility for changing IdPs
  • Ability to use multiple IdPs simultaneously
  • Hard cutover event for IdP changes
  • No SCIM provisioning for application

    • If you are able to configure your SSO provider, we recommend presenting all internal web services exclusively on Cloudflare domains. This is the model that Cloudflare takes for web application access internally and the most common method of resolution for customers in this scenario.

    With this approach, you do not need to make any changes to your existing DNS infrastructure. Cloudflare Tunnel in your network will manage the translation from external (Cloudflare public) DNS to internal DNS, which is how the system is designed to function. After you update the ACS URL in your SSO provider to the Cloudflare public hostname, the outcome will look like this:

    All users - whether in the office, remote, using or not using the VPN client - will always route through the Cloudflare Access authentication flow at app.public.com to access a private application. This provides a single control plane for policy application and security audits, and no additional user training is necessary.




    Next