Single Page App / Multi-Domain Session Management - Many Applications have multiple domains - at least one for the front-end user experience and the other for receiving API requests (e.g., app.example.com and api.example.com). This created a problem because the front-end service could no longer communicate with the API as they did not share a session, leading to Access blocking the requests. Previously, different custom approaches were required to issue or share the Access JWT between different hostnames.
Multi-Domain Applications allow teams to protect multiple subdomains with a single Access app, simplifying the process and reducing the need for multiple apps. Access also takes care of JWT cookie issuance across all hostnames associated with a given application (for up to 5 domains). This means that a front-end and API service on two different domains can communicate securely without any additional configuration.
Unified Policy Management - Previously, admins had to configure an Access Application per unique domain, even if the policies were identical. This often led to inconsistencies between different applications even though they should have an identical policy.
That’s a great change, but how to configure it though?
I have an application consisting of frontend running on uat.example.com and backend running on api.uat.example.com, but when I set up both urls inside one application in Zero Trust, it still blocks all the requests going to api.uat.example.com so the applicaiton is unusable.
Multi-Domain Applications allow teams to protect multiple subdomains with a single Access app, simplifying the process and reducing the need for multiple apps. Access also takes care of JWT cookie issuance across all hostnames associated with a given application (for up to 5 domains). This means that a front-end and API service on two different domains can communicate securely without any additional configuration.
I’ve contacted the Zero Trust support, but they weren’t able to tell me what’s the issue either.
For now we’re just going to force frontend to send CF-Authorization cookie to backend.
Hey @Maciej do you have the ticket # handy? I can take a look.
We should be setting the cookie across the api and frontend domains on initial user auth. If you are not seeing the cookie get set on the backend domain, we can definitely take a look.
Ok, I reviewed that ticket, thank you. You’re right that a bypass is not the right approach (I’ve opened an internal thread to correct that guidance given in the future).
You should be able to accomplish this using the multi-domain application feature we launched. Example:
Once you’ve added multiple domains, at the time of user authenticate the same Access JWT/Cookie will be issued to each of those domain through a redirect loop. They will have the same AUD tag. Which should allow for seamless communication back to the API service from the front end.
If you’re still having issues after that, we can take a look in a support ticket and then add our findings back here if we figure out something conclusive for the rest of the folks watching here.
@kjohnson1 I’ve been trying to do it this way since the day I found the option to add more than one domain into one application and still the result is as follows:
Any way to put more than 5 domains on a single application?
I have 6 servers with 6 tunnels so when I tried setting up an SSH application, I actually had to split them between two applications, meaning I had to use two different CA files for the short-lived certificates feature
I found a document implying that more than 5 domains is possible:
