add an option to use gateway hostname as server

[bugfood]

For some gateways, we get a message from gp-saml-gui: IMPORTANT: During the SAML auth, you were redirected from [...]

gp-saml-gui uses the target of the redirect, but this is not always correct. Add an option to direct gp-saml-gui to ignore the redirect.

[bugfood]

To describe the use case a bit more, I currently need to instruct our users to:

1. Run ./gp_saml_gui.py -g <gateway>
2. Copy/paste the command printed.
3. Edit the last argument to be <gateway>.
4. Run the command.

With the change, I can instruct our users to run only:
./gp_saml_gui.py -gGS <gateway>

[dlenski]

How about just name this --ignore-redirects?

[bugfood]

Yes, I can do that, if you think that is a better name.

[bugfood]

I updated the pr to use p.add_argument('-i', '--ignore-redirects',.

[dlenski]

I'm aware of this issue, but I really wish we could "autodetect" the correct solution rather than requiring users to figure it out and specify yet another configuration option.

For some gateways, we get a message from gp-saml-gui: IMPORTANT: During the SAML auth, you were redirected from [...]

For some but not all of your gateways? (If so, sounds like they're misconfigured 🤔)

[pboushy]

For some gateways, we get a message from gp-saml-gui: IMPORTANT: During the SAML auth, you were redirected from [...]

When do you run into this?
I'm trying to reproduce it and haven't been able to with our gateways.

I'm wondering if there's some sort of load balancer in play with something incorrectly configured.

[bugfood]

I'm aware of this issue, but I really wish we could "autodetect" the correct solution rather than requiring users to figure it out and specify yet another configuration option.

I agree, but I don't know how to go about autodetecting it. If there's any information I can provide that could help, let me know. I don't know much about the globalprotect gateways; I'm a VPN user, but I can relay questions to our network engineer.

For some gateways, we get a message from gp-saml-gui: IMPORTANT: During the SAML auth, you were redirected from [...]

For some but not all of your gateways? (If so, sounds like they're misconfigured 🤔)

I think I meant "we" as in "users of gp-saml-gui in general". I probably could have phrased that better. The behavior is consistent for the gateways in use at my company.

[bugfood]

For some gateways, we get a message from gp-saml-gui: IMPORTANT: During the SAML auth, you were redirected from [...]

When do you run into this? I'm trying to reproduce it and haven't been able to with our gateways.

My rough could-be-wrong understanding is that global protect provides two kinds of entities:

• A portal, which provides an entry-point to clients and supplies a list of one or more gateways. Users of the official globalprotect client connect to this and then choose which gateway to use.
• One or more gateways, to which VPN clients connect for auth and for creating the tunnel. Users of openconnect connect directly to whichever gateway is desired.

https://docs.paloaltonetworks.com/globalprotect/9-1/globalprotect-admin/globalprotect-overview/about-the-globalprotect-components

I think in our case, the gateway is providing a redirect to a portal.

[bugfood]

gp-saml-gui can auth to the portal via the --portal option, but then connecting to the portal via openconnect gives a message like:

2 gateway servers available:
  example-gateway1 (gateway1.example.com)
  example-gateway2 (gateway2.example.com)
Please select GlobalProtect gateway.
GATEWAY: [example-gateway1|example-gateway2]

The user can then type in which gateway to use, then use gp-saml-gui again to auth to the gateway this time, then paste in the prelogin-cookie for the gateway. Openconnect will proceed to use the gateway.

Unless there's some much better way to do this, I think it's easier to have gp-saml-gui auth directly to the desired gateway from the start. I really don't know this very well, though.

[pboushy]

If we're going to add an argument, shouldn't it align with OpenConnect's implementation:

• --usergroup gateway
• or tack on /gateway to the end of the serverhost?

https://gitlab.com/openconnect/openconnect/-/issues/151#note_353162354

[wtcline-intc]

gp-saml-gui can auth to the portal via the --portal option, but then connecting to the portal via openconnect gives a message like:

2 gateway servers available:
  example-gateway1 (gateway1.example.com)
  example-gateway2 (gateway2.example.com)
Please select GlobalProtect gateway.
GATEWAY: [example-gateway1|example-gateway2]

The user can then type in which gateway to use, then use gp-saml-gui again to auth to the gateway this time, then paste in the prelogin-cookie for the gateway. Openconnect will proceed to use the gateway.

Unless there's some much better way to do this, I think it's easier to have gp-saml-gui auth directly to the desired gateway from the start. I really don't know this very well, though.

If the portal and gateway are on separate servers, then it seems weird that you could authenticate directly to a gateway as that would presumably defeat the purpose of having the portal separate from the gateway. I could see it being useful to have something like --default-gateway=example-gateway2 so you can authenticate against the portal and automatically select your preferred gateway.

[bugfood]

If we're going to add an argument, shouldn't it align with OpenConnect's implementation:

* `--usergroup gateway`
* or tack on `/gateway` to the end of the serverhost?

https://gitlab.com/openconnect/openconnect/-/issues/151#note_353162354

I'm not sure; I could go with whatever, as long as there is some sort of option.

-Corey

[bugfood]

If the portal and gateway are on separate servers, then it seems weird that you could authenticate directly to a gateway as that would presumably defeat the purpose of having the portal separate from the gateway. I could see it being useful to have something like --default-gateway=example-gateway2 so you can authenticate against the portal and automatically select your preferred gateway.

I can see your point, I think. That sort of option does seem a bit more aligned with what I think users of the official globalprotect client do, albeit with being able to specify a default on the command-line. The option you describe could be better for users who know the portal FQDN and the gateway name, but not the gateway FQDN.

I don't know the globalprotect side of things very well, but as a user exploring the behavior client-side, I think that would be more difficult to implement. If we auth to the portal, then we still need to auth to whatever the gateway we choose afterward. I think gp-saml-gui would need to:

1. Auth to the portal; cache the SAML credentials (or token or whatever SAML does).
2. Parse the portal's provided list of gateways; look up the desired gateway FQDN.
3. Using cached SAML credentials, auth to the gateway FQDN.
4. Print an openconnect command line (or invoke openconnect).

Maybe support for much of this already exists, though, and I could be off in my understanding.

[bugfood]

@dlenski can you please provide some guidance on this? I understand that an automatic solution would be ideal, but unless any of us see a way to implement that, I think think that a simple option as implemented in this PR should be acceptable.

Thanks,
Corey

[bugfood]

I rebased and fixed a typo in the notification message.

@dlenski when you have time, can you please check this? As I mention above, I am advocating that this simple solution be provided, unless and until we have a means to do the proper thing automatically.

Thanks,
Corey

[bugfood]

Nice, thank you!