Open bugfood opened 7 months ago
To describe the use case a bit more, I currently need to instruct our users to:
./gp_saml_gui.py -g <gateway>
<gateway>
.With the change, I can instruct our users to run only:
./gp_saml_gui.py -gGS <gateway>
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 :thinking:)
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.
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.
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:
I think in our case, the gateway is providing a redirect to a portal.
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 we're going to add an argument, shouldn't it align with OpenConnect's implementation:
--usergroup gateway
/gateway
to the end of the serverhost?https://gitlab.com/openconnect/openconnect/-/issues/151#note_353162354
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.
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
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:
Maybe support for much of this already exists, though, and I could be off in my understanding.
@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
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.