Auth0 is the Identity Provider (IdP) and Cloudflare Access is the primary Service Provider (SP). If possible, SSO applications should be added to the App Launcher in Cloudflare Access.
When an application is added to App Launcher, for the purposes of documentation Cloudflare Access is the IdP and the application being added is the SP. Regardless, when login is initiated from App Launcher or the application's login page, Auth0 is still the "real" IdP and will handle user credentials.
- Auth0 (free)
- Cloudflare Access (free)
- Terraform CLI
- HCP Terraform (free)
- SaaS application(s) supporting SSO
Caution
Deployment from zero without modification will almost certainly fail since many SP's need to be manually configured. That said, the "foundational" parts are the auth0 and cloudflare-access modules, which should "just work" from zero. Once those are setup, additional SaaS apps can be layered on.
Important
Anywhere you have to provision a user account manually, the username and email must be the same, and it needs to match the user information in Auth0.
When connecting Cloudflare Access with a SP, it may be necessary to create the application in Cloudflare Access with blank fields first so that the correct information can be generated for adding to the SP. Once the SP setup is complete, the application config in Cloudflare Access can be updated with the correct information.
Perform the following manual tasks:
- Create a Machine to Machine application for Terraform and permit access to the Auth0 Management API. We need the client secret for authenticating Terraform with Auth0.
- Create a user account. Username and email must be the same. This will be the SSO user that is created in the SP application.
No manual tasks.
The following API token permissions are required for terraform:
- Zero Trust:Edit
- Access: Organizations, Identity Providers, and Groups:Edit
- Access: Apps and Policies:Edit
- All zones - DNS:Edit
If you're struggling to find reference ID's for Cloudflare objects to import, sometimes the information can be found by inspecting the page using the "Network" tab in your browser's development tools. Filter by "XHR/Fetch" (Safari) and you should find a corresponding item that contains the relevant ID. You may need to navigate to different pages for the correct info to show up though.
The v4.x provider is preferred for the moment since 5.x has a lot of problems.
The settings in AWS IAM Identity Center need to be manually configured. The hashicorp/aws provider does not (yet) support this operation (AWS SSO).
The settings in HCP need to be manually configured. The hashicorp/hcp provider does not (yet) support this operation. Once SSO is enabled, users can no longer be invited to the organization and should instead be provisioned in the IdP (Auth0).
- Invalid request: IdP initiated login is not enabled
- Cloudflare SAML SSO in HCP configuration
- Invite Users
The settings in HCP Terraform need to be manually configured. The hashicorp/tfe provider does not (yet) support this operation.
If you need to migrate to an OIDC IdP, open a support request (bottom of the page) and provide the following information:
- Type of request: Identity provider configuration or change
- Domain name you will use to login to Tailscale (Webfinger needs to be configured to respond on this domain).
- Change SSO identity provider
- Old and new providers
- Client ID from Cloudflare Access
- Client Secret from Cloudflare Access
- Prompts (leave default)
- SSO Custom OIDC: Identity Provider Setup
- Auth using auth0 identity
- Using Auth0 with Headscale and Tailscale
No real action is needed here, a Bookmark simply creates a shortcut in the App Launcher to a website. One thing to note is that Bookmarks cannot have policies applied, so if you plan to share this App Launcher dashboard with others, they will also be able to see and access your Bookmarks.
Instead of versioning each child module individually, the required-providers module handles provider versions for the entire deployment. Inspired by Martin Atkins' comment.