handle SMS factor, and either REDIRECT or POST as <saml-auth-method>

[dlenski]

• handle either REDIRECT or POST as <saml-auth-method>
• quick-and-dirty support for SMS factor

[dlenski]

I've pulled the SMS bit -- that works fine for me. I did modify the change slightly: AFAICT you're not supposed to include factorId in the POST body -- that's part of the URL and is already included in the ['verify']['href'].

Aha, thanks. I based that off the usage in pan-globalprotect-okta (https://github.com/arthepsy/pan-globalprotect-okta/blob/master/gp-okta.py#L331,L342). The implementation over there is, hrmm, a lot messier than yours… so it's hard for me to determine whether including this field is/was found to be necessary in any case.

I also added an assert to check the status is MFA_CHALLENGE after the first POST.

:+1:

I'm unsure about the POST/REDIRECT change. The code looks broken in the case where saml-auth-method is REDIRECT (saml_req_data is not set at all)?

I don't have access to a “live” VPN that uses the REDIRECT method, but here's my understanding of how it works (based on this comment https://github.com/dlenski/openconnect/pull/97#issuecomment-377899908):

• Prelogin response contains:

<saml-auth-method>REDIRECT</saml-auth-method>
<saml-request>aHR0cDovL3NhbWwuYXV0aC5lbmRwb2ludC5jb21wYW55LmNvbS9ibGFoL2JsYWg/YWNjZXNzPUtK
RldFUklVRVJCU0RMU1BJV0VSS0pTREZKSFNLREdOQ0tTSkRGU0ZECg==</saml-request>

• Instead of using the <saml-request> contents as the source of a form to be POSTed by the client in order to start the SAML authentication process, the contents simply contain a URL which the client should GET in order to start the process.
• No saml_req_data is needed because it's presumably already encoded into the URL.

Also only the first request to saml_req_url is actually changed to POST in the POST case. The second request (the one that actually returns the SAML response) is still a redirect from sessionCookieRedirect.

Right.

I'm not really sure what the right thing to do here is. For me, saml-auth-method is POST but doing GETs works fine and IIRC is what the official client was doing. Slightly off-topic: it's not really clear why the first GET is necessary at all. I know that it sets a DT cookie (which I guess is some kind of tracking cookie), and that without this the sessionCookieRedirect just doesn't seem to work. But none of this is mentioned in the Okta docs (edit: I guess this is GP-specific so it wouldn't be).

I share your understanding, and also your uncertainty about what some of these things mean.

Basically, the difference between POST and REDIRECT is a relatively superficial one: the former says "POST this form to start the SAML auth", while the latter says "GET this URL to start the SAML auth.