I have a question about auth0 in connection with Palo Alto Clientless VPN.
This is my first time with Oauth and auth0, please forgive me if I did something wrong here.
The goal is the following:
Login to the palo alto firewall via auth0 (global protect portal)
Opening an app (hosted locally behind the firewall) via Clientless VPN
The app redirects to auth0 again for SSO → access to app without second login
This is what i did:
I have created an application at auth0 (Regular Web Application)
This is my Clientless VPN app
Under “Addons” I then activated the SAML2 WEB APP
This is the firewall login for the GlobalProtect Portal (where i can open my app via Clientless VPN)
For the configuration, I followed the instructions for Okta with Palo Alto → Link
Everything seems to work so far, I can log in to my app and the firewall with my created users.
SLO also works via the Palo Alto GlobalProtect Portal page.
However, I am prompted to log in again as soon as I access the app via Clientless VPN.
It seems the SSO cookie is not recognized.
Possibly because of the proxy through the firewall.
But how else do you do that? Unfortunately I’m running out of ideas…
I may have misconfigured or forgotten something.
If anyone has any idea what could be causing this, I would really appreciate your help!
Yes, I found an answer.
Palo Alto support said it would only be possible with multiple logins, which is not true.
It’s exactly as I suspected.
The problem is the domain for which the cookie is stored in the browser.
Here as an example with auth0:
When you log in for the first time you will be redirected directly to the auth0 login page: https://your-tenant-domain.auth0.com → domain auth0.com
But the second time you log in, the redirection already takes place through the firewall’s proxy https://your-firewall-ip/https/your-tenant-domain.auth0.com → domain your-firewall-ip
which is why the cookie for this domain has to be saved again and the other one cannot be recognized.
The solution is very simple:
Add the domain *.auth0.com to the Clientless-VPN “Rewrite Exclude Domain List” so that the second redirection takes place directly.
(your-tenant-domain.auth0.com should also work.)
Hi boon, so much thanks for the reply this is brilliant and thanks for letting me know… this might help us… but can I check?
Our issue is that we have a palo ssl clientless vpn port (lets call is portal.blah.com) and behind it is an internal application lets call it guco.blah.com.
Both systems use Microsoft saml, but with their own Entra Microsoft SAML applications (not sure that makes any difference)
The users would normally already have a Microsoft saml cookie (from the initial windows and MS login) and can then sso into the vpn portal… the issue is then logging into the application behind the ssl vpn (guco.blah.com) they get thrown another prompt as the url is then portal.blah.com/https/guco.blah.com… backs up your reason about no cookie for that domain.
So am I adding the guco.blah.com to the clientless rewrite exclude domain list? (we didn’t want to expose the guco.blah.com to the internet directly)?.. or is it the micrsoft sso SAML domain we should be adding into the re-write list!?
You don’t need to expose your app to the internet. Simply add the domain to the list that the user will be redirected to for authentication (authorization/login endpoint from your IdP).
I have no experience with these Microsoft services, so I don’t know the domain.
I suspect it’s *.microsoftonline.com or login.microsoftonline.com.
Hi Boon, yes you are right! so we added the login.microsoft etc etc domain… It kinda of worked… It opens a new tab and puts it through saml with no logon… perfect!.. but then it does not hide the app behind the clientless ssl vpn anymore eg: portal.blah.com/https/guco.blah.com it just sent the browser to guco.blah.com which isn’t exposed externally so then failed. We’re not sure why but at least this is progress.
this is because you need to change your callback URL from guco.blah.com/your-callback-route to https://portal.blah.com/https/guco.blah.com/your-callback-route
