Support for SAML (WebAuth)

[bgironx15]

Hello again,

In my testing, I also noticed that when using a Client Profile (.ovpn file) from an User that uses SAML as an Authentication Method, nothing happens

In my Ubuntu Desktop Machine, I can use OpenVPN3 via CLI and start a VPN Connection with this Profile. So, then the OpenVPN3 will redirect this SAML Request to an External Browser in my Ubuntu Desktop Machine to the Login Page of my IdP and continue the SAML Authentication and then connected to the VPN

Would be really helpful to use "openvpn-3-indicator" so that when we initiate a VPN Connection, this automatically performs this same redirect of the SAML Request to an External Browser

Thanks

[dsommers]

Can you verify the output of openvpn3 session-auth ?

@grzegorz-gutowski The web authentications are caught a little bit different, and the OpenVPN session works a bit different too. In this case, you will see a StatusChange signal on the session with StatusMajor.SESSION + StatusMinor.SESS_AUTH_URL. The URL to open is provided in the "message".

You can see an example here: https://gist.github.com/dsommers/d4447dba169b1278bcab4b7ebd235761#file-openvpn3-session-patcher-py-L188

All you need to do is to ensure this URL is opened up. Then the connection gets fully connected if the web authentication passed, or it willl disconnet on auth failures.

You can also retrieve the URL for more uses via the GetStatus() - which should be the same status as described above.

[bgironx15]

This is the result of the "openvpn3 session-auth" command:

[grzegorz-gutowski]

I tried to mimic the behavior of openvpn3 CLI: https://github.com/OpenVPN/openvpn3-indicator/blob/43742cad484eae9c32f620163b55001ae96bb3e7/openvpn3-indicator#L826 https://github.com/OpenVPN/openvpn3-indicator/blob/43742cad484eae9c32f620163b55001ae96bb3e7/openvpn3-indicator#L863 but it seems that I did something wrong.

@bgironx15 : Could you please run openvpn3-indicator --debug and provide the output (I hope there are no secrets in the log, but I can't guarantee that, so please check it before posting)

@dsommers : Do you have a set of common (and less common) configs that I could test against? In particular, I don't want to build fancy server configs with different kinds of authentication - maybe there are some already running, which I could use for testing?

[bgironx15]

@grzegorz-gutowski This is the result of the "openvpn3-indicator --debug" command:

But I got that same result all the time, so not sure if this is related to the SAML VPN Attempt, or an error of the command or something else

[grzegorz-gutowski]

@bgironx15 : This looks serious. I'm not sure if the application is operational after failed initialization of secretstorage. I can see that you are running indicator as root - this might cause some problems with access to Gnome Keyring. I'll try to patch indicator app so that it handles Secret Storage failures better.

[bgironx15]

@grzegorz-gutowski is this unrelated to the SAML issue? Meaning a new issue that needs to be fixed? or related to the SAML issue somehow?

[grzegorz-gutowski]

@bgironx15 I hopefully implemented secret storage as an optional feature. Can you please check again with the new version? This could possibly be the root cause of #3

[bgironx15]

@grzegorz-gutowski let me test and will get back with the results here after that

[dsommers]

@grzegorz-gutowski To test web authentication; sign up for a free Cloud Connexa account. It gives you 3 simultaneous connection and requires web-auth for authentication.

Maybe @bgironx15 can help you towards the right guide where to click in that web admin portal ....

[bgironx15]

@grzegorz-gutowski the error with "openvpn3-indicator --debug" is not anymore but AutoLogin Profiles don't work yet

This is the results from the "openvpn3-indicator --debug" while attempting the VPN Connection with AutoLogin Profiles:

When I connect to the VPN with this AutoLogin Profile, I see this "SEE_CREATED" like, but the VPN doesn't connect

When attempting with a SAML Profile, the results are almost the same:

When I connect with the User-Locked Profile (Username + Password), I see the same output but this one works:

[grzegorz-gutowski]

I was having trouble with understanding the correct order of commands / events that start up such sessions.

For password authorization I do as follows:

1. I (or someone else) do NewTunnel
2. I receive "Session Created" from Session Manager
3. I receive "CONNECTION : CFG_REQUIRE_USER" from Session Status Change
4. I do FetchUserInputSlots, ProvideInput
5. I do Ready and Connect
6. I receive "CONNECTION : CFG_OK"
7. I receive "CONNECTION : CONN_CONNECTING"
8. I receive "CONNECTION : CONN_CONNECTED"

It seems, that for Connexa / Key+Cert I have to do as follows:

1. I (or someone else) do NewTunnel
2. I receive "Session Created" from Session Manager
3. I receive "CONNECTION : CFG_OK"
4. I do Ready and Connect
5. I receive "CONNECTION : CONN_CONNECTING"
6. I receive "CONNECTION : CONN_CONNECTED"

The problem was that Ready/Connect either must go before CFG_OK (password auth), or must go after CFG_OK (key & url auth). It would be much cleaner if OpenVPN3 would generate CFG_OK after all necessary ProvideInput are called.

Second problem is that calling Connect twice is not a safe operation (it usually kills the sessions in my tests). So I have to be very carefull about calling Connect. And I expect that it will cause problems when multiple agents try to handle the same session. It would be much cleaner if OpenVPN3 would accept and quietly discard multiple Connect operations on session that have already been commanded to connect (either by the same, or other agents)

Now, that I have sorted it out, I expect to provide patches for #3 and #4 later.

[dsommers]

You're absolutely right this should be done different. What you probably don't receive is a CFG_OKbefore the CFG_REQUIRE_USER. It might actually happen too fast or that D-Bus daemon drops the first one.

The end-user UI implementations I've done will do these steps:

1. Call NewTunnel
2. Call Ready
3. If error, check error message for "Missing user credentials" 3.1 FetchUserInputSlots + ProvideInput 3.2 Jump to 2
4. Call Connect

That said, checking for CFG_REQUIRE_USER is not a bad idea. So that could probably be used instead of the error message check in step 3.

An example from the tests directory: https://codeberg.org/OpenVPN/openvpn3-linux/src/commit/32d646c29d31b5a04c715878b4af5ec043518ed9/src/tests/python/ovpncli.py#L58

In regards to calling Connect more times, yes, that might have issues in v21 and older. I know I poked a bit at that for the v22_dev work (https://github.com/OpenVPN/openvpn3-linux/issues/171); we have development snapshots available in for Fedora 38+ and Ubuntu 23.04+. Might be worth testing against that version.

[grzegorz-gutowski]

I have pushed new code that works in all three scenarios: keys, password, saml. I have also pushed my vagrant testing environment and a sample usage video. Can you please check the result in your environment?

[bgironx15]

Hey @grzegorz-gutowski, I will give it a try and let you know

[bgironx15]

@grzegorz-gutowski installed the new image:

But this is not working yet (Certificate Authentication only and SAML)

Is there something else I can check?

[bgironx15]

@grzegorz-gutowski wait. It looks like I have to "quit" the program and start it once again. Testing now

[bgironx15]

@grzegorz-gutowski @dsommers I can confirm both are working like a charm on my Ubuntu 22.04 LTS Desktop and my OpenVPN Access Server v2.13.1 (Latest version)

• SAML Authentication:

• AutoLogin Profile (Certificate Authentication):

Good Job!!