Saml external browser

[filippor]

add parameter --ext-browser-saml[=]

• start listening on listen port (default)
• print an address to manually open in a browser
• ( the gateway server will send browser a javascrip to call localhost:8020/?id=<auth-id> )
• receive the http request and extract the auth-d
• use auth-id to autenticate on address /remote/saml/auth_id?id=

there is also parameter --auth-id= if retrieved externally

NEED HELP to review printed messages and update man pages

the ext-browser-saml can be configured configuration file but in this case the port is required es

host = vpn.sample.com
port = 10443
ext-browser-saml = 8020

[LorenzISR]

as i've mentioned in #867, imo this is not a good idea. external programms such as https://github.com/gm-vm/openfortivpn-webview are a cleaner approach to handling this -- maby look into packaging it for your distro instead?

[filippor]

LorenzISR

Can you be more explicit this pr use a different method than openfortivpn-webview

[LorenzISR]

i know that, i've read your code.

you are adding a bunch of code for functionality that openfortipvn-webview can already do, but better. if it gets packaged for distros that is actually a much nicer user experience than having to manually run an external browser. that is why i've said that you should look into packaging it instead.

[filippor]

The advantage is that this solution could use the default browser that keep the session and if it is valid doesn't need to reautenticate. And i think it is easy to integrate in external gui or NetworkManager and can be executed with xdg-open https://<gateway>:<port>/remote/saml/start?redirect=1 &sudo openfortivpn <gateway>:<port> --ext-browser-saml

[exzombie]

I hope to be able to test this in the coming weeks.

I'm a regular user of code from an unfinished MR in NetworkManager-fortisslvpn which uses the same approach as openfortipvn-webview, with the benefits of NetworkManager integration. While it's a life saver in my situation, I have to say that the approach taken in this PR would be preferable. The VPN is not very stable, and I am often on a flaky uplink, necessitating many reconnections. Typing the password and dealing with 2FA can be quite annoying.

We can debate whether this functionality belongs into openfortivpn itself instead of an external tool. I think having it in openfortivpn has the benefit of making it available to all users. For comparison, having openfortivpn-webview available doesn't do much for those of us who need NetworkManager, and while the Gnome version of the NM user interface now has an unfinished reimplementation of what openfortivpn-webview offers, other interfaces (like KDE Plasma) don't have it. In other words, everybody would need to integrate a webview, which is not trivial. On the other hand, if openfortivpn can handle this by itself, adding SAML to NM interfaces is one new checkbox away.

The way I see it, this is just another way for openfortivpn to get the cookie, complementing the stdin method. Authentication is delegated to an external tool (i.e., the default browser), same as always.

[robdevops]

Working well on Ubuntu. I do strongly prefer this method because it is a much simpler command that does not require additional packages, nor the awkward pipe into sudo, nor re-authentication because it uses my existing browser session.

This is how convoluted my launch command needs to be with openfortivpn-webview: $ sudo whoami # cache sudo credentials because you can't (easily) type your password into a pipe $ ~/openfortivpn-webview-1.2.0.AppImage --trusted-cert='sha256/+NbF2hzIunRbOynladSfCD9gj9HEKYHc4Y7h9dlGqQg=' vpn.example.com:10443 | sudo ./openfortivpn --cookie-on-stdin --trusted-cert f8d6c5da1cc8ba755b3b29e569d49f082f608fd1c42981dce18ee1f5d946a908 vpn.example.com:10443

Vs this branch: $ sudo ./openfortivpn --ext-browser-saml vpn.example.com:10443 --trusted-cert f8d6c5da1cc8ba755b3b29e569d49f082f608fd1c42981dce18ee1f5d946a908

It is better in every way: quicker to install, easier to use, and saves a good 40 secs by using existing session.

[robdevops]

Hi @LorenzISR

a bunch of code for functionality that openfortipvn-webview can already do, but better. if it gets packaged for distros that is actually a much nicer user experience

Expanding on my previous comment, the user experience is superior with this PR for the following reasons:

• Even if openfortipvn-webview were packaged, in order to continue supporting non-GUI systems, it can never be pulled in as a dependency of the openfortipvn package, so on any system with a working browser, the openfortipvn-webview method will always be more complex to install.
• The openfortipvn-webview launch command is convoluted with openfortipvn-webview, requiring shell tricks like pipes or stdin redirects, so it will always be harder to use, especially when combined with sudo and password input.
• Both methods use an external browser. With this PR, it is guaranteed the user will have browser package options that have an active maintainer, as long as they are on a supported OS.
• This PR supports hardware auth methods like YubiKey, FIDO/U2F, smart cards, and Passkeys. It is a more universal solution.
• The reuse of existing browser session cookies can significantly reduce the number of user interactions and average time to connect.

I think the last two items in particular are high value for user experience. I respectfully request you reconsider use cases where this PR adds real value.

[LorenzISR]

pipes are not "tricks", they are normal features of a shell, and they have always been. you will need sudo anyways, regardless if you use webview or not. i am not using sudo but doas instead but using pipes works perfectly fine for me. openfortivpn-webview can safe the credentials (i think?), you'll just have to click the button for your SSO provider to safe them. i don't understand why openfortivpn-webview would not work with hardware auth methods?

that said, i am not a maintainer but just a random person on the internet who's worked on this problem before and this is just my opinion.

[robdevops]

pipes are not "tricks", they are normal features of a shell, and they have always been. you will need sudo anyways, regardless if you use webview or not. i am not using sudo but doas instead but using pipes works perfectly fine for me.

I'll clarify. If sudo is at the beginning of the command, it can cleanly prompt for keyboard input before openfortivpn is executed. In the openfortivpn-webview case where sudo is after a pipe, you have sudo writing to stdout, openfortivpn-webview also writing to stdout, sudo reading from stdin, and finally openfortivpn reading from stdin. The output of sudo and openfortivpn-webview gets mixed together and the sudo password prompt is buried above line feeds from openfortivpn-webview, with openfortivpn-webview printing to the part of the screen where the users password input indicator is supposed to be printed. It's clunky. There are ways to make this smoother, but my point is it's an inferior user experience out of the box. If further steps are required to make this smoother, then the existence of those steps themselves make for a more complicated user experience.

i don't understand why openfortivpn-webview would not work with hardware auth methods?

I thought I read on another discussion that it didn't. Apologies if I am wrong.

openfortivpn-webview can safe the credentials (i think?), you'll just have to click the button for your SSO provider to safe them. i don't understand why openfortivpn-webview would not work with hardware auth methods?

openfortivpn-webview does cache, but you may be overlooking that SAML is commonly used for single sign-on, where web apps can use the VPN initiated cookie or vice versa. That is, the browser may already be signed in before the VPN is ever used, and likewise, signing into the VPN may also sign into various web apps. Using openfortivpn-webview segregates the cache of the VPN from the cache of web apps, breaking the single sign-on model by resulting in more consecutive sign on interactions.

[LorenzISR]

sudo does not read the password from stdin.

i'd argue that re-using the sign-in from the browser might even be a security risk for some and not desired; having to sign in once for your VPN is fine imo and this is also how it works on windows.

[gm-vm]

This seems to do what it is described here.

That's neat, I don't remember having this option in my official client (and I no longer have access to the VPN to check it now), but this definitely removes the need of using a custom made browser.

@LorenzISR this seems to be a feature of the gateway that lets clients use any browser for the authentication. It is different from launching the browser from within openfortivpn.

[robdevops]

@gm-vm that's correct. I use this option in the official mac client.

[filippor]

If needed I can split this PR 1 for adding the authentication method with ID and another to listen for id on port. But I think the changes are not so big.

[herpus-derpus]

I am of the opinion this PR would vastly improve all linux user experience for everyone I work with.

My default browser session requires me to SAML auth with a second factor each day. Currently I have to do this twice each morning since openfortivpn-webview requires it separately.

If the openfortivpn client could make use of my already authenticated session in my default browser, this would significantly improve the SSO experience for myself and all other linux desktop users where I work. They would be over the moon. I don't see a decrease in security for us, since we need to SAML auth daily anyway as policy means our session expire each day.

[herpus-derpus]

Presumably I could build openfortivpn from this filippor:saml-external-take2 branch ? Is that easy ?

[filippor]

Presumably I could build openfortivpn from this filippor:saml-external-take2 branch ? Is that easy ? It is not complicated to compile the instruction is in the readme on this repository

or to retrieve the token you could use this project https://github.com/filippor/XdgOpenSaml/tree/main it also use the external browser a binary that not require javacompiled for linux-x86-64 is here

[dsl400]

Without knowing this even existed and driven only by the need of a specific feature I written a solution that kinda solves the same problem, there are few extra features like specifying routes, dns entries and domain prefixes in the config file to override the configuration coming from the server. In my case the server uses microsoft services with 2FA. While I do undertand the need for a SAML sign in method on systems without gui I am not really sure that openfortivpn-webview is a good idea and here are some reasons:

• bloat
• security

• overcomplicated

  I really would not push a "home made browser" over a mainstream browser.

and ....

that said, i am not a maintainer but just a random person on the internet who's worked on this problem before and this is just my opinion.

[itss0076]

Rather than trying to put the browser spawning and web server listening bits into the (run as root) openfortivpn process, why not use the privilege-separated interface already provided for openfortvpn-webview?

Make a new process (run unprivileged) that does the SAML dance with the VPN appliance, by shelling out to the user's browser and listening for a response on port 8020, and then outputs the "SVPNCOOKIE=..." string for piping into "sudo openfortivpn --cookie-on-stdin ...".

[filippor]

The implementation as external program already exist at this repo https://github.com/filippor/XdgOpenSaml. The idea of this pr is to integrate all the process in this software.