topic Re: PaloAlto 3rd party captive portal integration in General Topics

PaloAlto 3rd party captive portal integration

fenriquez — Thu, 13 Dec 2018 20:19:41 GMT

Hi! First of all sorry if this question is explained anywhere else; I've dedicated a few hours to browse docs and posts but I cannot find a proper answer. I work for a company that deploys hotspot solutions over premises using different hardware solutions. It turns out to be that we need to integrate Paloalto appliance in our solution. Our approach is basically this:

Firewall intercepts traffic for non authenticatrd users
User is redirected via a 302 http redirect to our portal (it can be placed on the wan zone so it can be reached by the Paloalto firewall)
Web form is presented so the user validates himself. If credentials are valid (they are internally located on a Radius server) then control must be returned to Paloalto firewall
Paloalto firewall should try to authenticate now the user with the credentials provided before in point (3) via Radius
Radius replies with an Access-Accept so a Session-Start should be send from Paloalto to the Radius server (accounting starts)

So here there are my questions:

Is this approach feasible? I understand that points (1) and (2) are easily configurable as a Redirect Captive Portal with web form authentication....
How must our captive portal inform to Paloalto that credentials are valid so Paloalto starts with Radius authentication? Some manufacturers implement a special login URL, other ones use a propietary protocol, but I cannot find detailed information about the whole workflow.

Thanks a lot in advanced for your help.

Kind Regards

Fernando E.

Re: PaloAlto 3rd party captive portal integration

Remo — Thu, 13 Dec 2018 20:51:42 GMT

Hi @fenriquez

This is possible with 2 different ways, but not with point 3 of your list:

@fenriquez wrote:
Paloalto firewall should try to authenticate now the user with the credentials provided before in point (3) via Radius

The authentication needs to be done on your portal only, otherwise if the firewall has to authenticate the user also, he needs to log in again on the captive portal of the firewall which is not really possible as you redirect the user first to your portal.

But thats not a problem. The ways it will work are the following:

Syslog: your captive portal server sends syslog messages containing the source IP and the username to the firewall. The firewall then parses these messages and adds these ip-user mappings to the local usertable.
API: as soon as a user successfully logged in your captive portal server adds the ip-user-mapping over an API call to the firewall.

For both ways, your captive portal needs to be placed in the internal network or at least before any NAT is applied because otherwise your captive portal cannot send the actual client IP to the firewall and the whole situation will not work. In addition when the syslog is sent or the API call is made, you need to check if there is a small delay required before your captive portal redirects the user to the actual URL that the user tried to open.

Regards,

Remo

PS: Sorry for this question, but if this works like that and in the background the authentication is done with RADIUS, why should a paloalto customer pay for your solution when the firewall already has this capability out of the box?

Re: PaloAlto 3rd party captive portal integration

fenriquez — Fri, 14 Dec 2018 04:50:11 GMT

ok, I see the picture, once you send the syslog trace then the PaloAlto firewall allows the user to access the Internet.

Regarding why using our solution instead of the integrated portal: the picture I depicted it's a simplified one. Our client wants a "complicated" authorization mechanism which involves sending an email to someone that must allow another one with an SMS.

Thanks a lot for your help.

Re: PaloAlto 3rd party captive portal integration

Remo — Fri, 14 Dec 2018 05:56:34 GMT

@fenriquez wrote:
Regarding why using our solution instead of the integrated portal: the picture I depicted it's a simplified one. Our client wants a "complicated" authorization mechanism which involves sending an email to someone that must allow another one with an SMS.

Now I understand 😉