Openconnect support with CAS and SAML?

[retpolanne]

Hello there,

Our company uses CAS for authentication and we are using SAML for it. I've seen the issues about SAML but they are related to Okta, but I'm not sure if that is the same flow. Does anyone have experience using it with the same setup?

[dlenski]

Our company uses CAS for authentication and we are using SAML for it.

CAS = https://en.wikipedia.org/wiki/Central_Authentication_Service…?

I am the main developer of the GlobalProtect support, but have no access to a GP VPN that uses SAML myself.

1. Start by pulling https://$SERVER/global-protect/prelogin.esp (portal) and https://$SERVER/ssl-vpn/prelogin.esp (gateway) and see what they tell you about the SAML entry point.
2. Follow the SAML authentication flow until you get some kind of cookie (portal-userauthcookie… or prelogin-cookie most likely).
3. Extract the cookie, and then follow my instructions in this comment to use test-globalprotect-login.py, which will allow you to quickly test logging into the portal/gateway with various combinations of username, password, cookie.

[retpolanne]

Hmm, weird.

This cookie does not show up on the auth flow, at least not when I try to login from the browser (only PHPSESSID shows up). It should show up on the SAML responses? Or in the request headers?

I tried to intercept the requests on my GP client but I can't use mitmproxy certificate with it.

[dlenski]

This cookie does not show up on the auth flow, at least not when I try to login from the browser (only PHPSESSID shows up). It should show up on the SAML responses? Or in the request headers?

Ignore the PHPSESSID junk. I don't have access to a VPN with SAML, so my knowledge is extremely limited. Maybe it will show up as a "real" HTTP cookie, maybe something else.

I tried to intercept the requests on my GP client but I can't use mitmproxy certificate with it.

See #120 for some tips on getting GP to accept MITMproxy'ed certs.

[retpolanne]

@dlenski nice, I got to intercept it by only using the --ssl-insecure flag :P

I finally understand where the cookie is – when I make a request to /SAML20/SP/ACS.

Imitating @arthepsy, I made a Python script (a very ugly one, sorry) for that.

Thanks for the help @dlenski

[dlenski]

@dlenski nice, I got to intercept it by only using the --ssl-insecure flag :P

Ah, yes… mitmproxy itself has to be coaxed into making insecure requests.

I finally understand where the cookie is – when I make a request to /SAML20/SP/ACS.

Imitating @arthepsy, I made a Python script (a very ugly one, sorry) for that.

Very nice. And once you're done, you can simply connect with echo $PRELOGIN_COOKIE | openconnect --usergroup gateway:prelogin-cookie $GATEWAY -u $USER --passwd? That all works?

It'd be awesome to have you SAML users join forces and create one script that handles all the posisble use cases and outputs an openconnect --authen-style result:

HOST='10.2.3.4/gateway:prelogin-cookie'
FINGERPRINT='sha1:deadbeefdeadbeefdeadbeef012345678'
SECRET='blahblahblahblahblahblah'

Then everyone can just do eval $(saml-script); echo $SECRET | openconnect $HOST --servercert $FINGERPRINT --passwd-on-stdin --prot=gp.

———

Please test the new 👉 prelogin 👈 branch, which more slavishly emulates the official client's requests. It should print out the SAML redirect URL, assuming your /global-protect/prelogin.esp looks something like:

$ openconnect --prot=gp fakeserver
SAML login is required: http://lolcats.com/login/vpn

OH HAI I CAN HAZ CRUDENSHULS?
Usernomnomnom: nobody
Paßwört: ******

<prelogin-response>
<status>Success</status>
<ccusername/>
<autosubmit>false</autosubmit>
<msg/>
<newmsg/>
<authentication-message>OH HAI I CAN HAZ CRUDENSHULS?</authentication-message>
<username-label>Usernomnomnom</username-label>
<password-label>Paßwört</password-label>
<panos-version>1</panos-version>
<saml-auth-method>REDIRECT</saml-auth-method>
<saml-request>aHR0cDovL2xvbGNhdHMuY29tL2xvZ2luL3Zwbgo=</saml-request>
<region>US</region>
</prelogin-response>

[retpolanne]

Please test the new 👉 prelogin 👈 branch, which more slavishly emulates the official client's requests. It should print out the SAML redirect URL, assuming your /global-protect/prelogin.esp looks something like

Hah, mine actually got me in a 512 loop :/

It'd be awesome to have you SAML users join forces and create one script that handles all the posisble use cases and outputs an openconnect --authen-style result:

It would be great. I was thinking about how gcloud manages authentication: it runs some kind of server on your side and asks you to open a link on your browser. The callback is probably registered to this server. Maybe if we do that we won't have to worry about the IdP side.

Edit: I'll see if I can imitate this

I tried doing it with selenium and browsermob-proxy but the result was a frankenstein 😂

Very nice. And once you're done, you can simply connect with echo $PRELOGIN_COOKIE | openconnect --usergroup gateway:prelogin-cookie $GATEWAY -u $USER --passwd? That all works?

Hmm, got that fgets (stdin): Inappropriate ioctl for device error mentioned in #116 .

[retpolanne]

It'd be awesome to have you SAML users join forces and create one script that handles all the posisble use cases and outputs an openconnect --authen-style result

It's probably not the best, but I just finished a script that makes the SAML login flow on your browser and gets the prelogin cookie. It tampers the SAML request to point to your localhost. (It might be a security issue though, since you have to authorize your localhost on CAS)

Here it is.

I can get the prelogin-cookie just fine, but I keep getting a 512 (I'll try to understand it later though)

Maybe it might work with Okta (@arthepsy, could you see if that helps you too?) since it opens the IdP part on your browser and it only worries about the GlobalProtect.