SUMMARY The applet does not show the browser window to insert the access credentials to the VPN network in double authentication. STEPS TO REPRODUCE - Create a new Cisco Anyconnect VPN network (OpenConnect) - Insert the gateway - Save the configuration OBSERVED RESULT - Try access to the VPN network (NetworkManager widget: click on "Connect") - The log show: "No SSO Handler" EXPECTED RESULT - that appears the browser window to enter the access credentials ADDITIONAL INFORMATION POST https://xxxxxxx/ Attempting to connect to server xxx.xxx.xxx.xxx:443 Connected to xxx.xxx.xxx.xxx:443 SSL negotiation with xxxxxxx Connected to HTTPS on xxxxxxx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM) Got HTTP response: HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Transfer-Encoding: chunked Cache-Control: no-store Pragma: no-cache Connection: Keep-Alive Date: Sun, 09 Jan 2022 07:34:44 GMT X-Frame-Options: SAMEORIGIN Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff X-XSS-Protection: 1 Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self' X-Aggregate-Auth: 1 HTTP body chunked (-2) POST XML abilitato No SSO handler From GNOME interface, instead, everything works fine. Thank you, Antonio SOFTWARE/OS VERSIONS KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2
For what its worth, I took a crack at implementing support for this using QtWebEngineView (loosely based on the nm-openconnect code for the same) and was not able to get it working. I won't pretend to be a Qt expert, but I was able to get plasma-nm to pop the window at an appropriate time but got stuck at a repeated SIGTRAP in the underlying Chromium code in Qt 5.15. The latest OpenConnect API has support for launching a desktop browser, but I did not try using that yet. That might be a better solution going forward, so that the authentication support is not tied to whatever version of Chromium Qt picked for a given release.
That said, external browser use is a tough edge case. One has to have: 1) The latest OpenConnect, built against a recent version of OpenSSL/GnuTLS 2) A recent version of the AnyConnect server 3) The *server* has to be setup to allow/force external browsers 4) The applet has to be built with the callback added I can't work on that since my company does not have #3.
*** This bug has been confirmed by popular vote. ***
(In reply to Ehren Bendler from comment #2) > That said, external browser use is a tough edge case. > > One has to have: > 1) The latest OpenConnect, built against a recent version of OpenSSL/GnuTLS > 2) A recent version of the AnyConnect server > 3) The *server* has to be setup to allow/force external browsers > 4) The applet has to be built with the callback added > > I can't work on that since my company does not have #3. I happen to have a company with one of these VPNs so I may take a stab at learning some new things. Do you still have this experimental code around for me to look at and possibly use as a starting point?
I also work at a company with forced SSO. I can test any experimental code.
https://invent.kde.org/plasma/plasma-nm/-/merge_requests/208
I backported Rahul's patches the following patches to v5.26.5 on my system, and I can confirm that this fixes the issue: * 408cca64: Add support for openconnect_set_external_browser_callback introduced in openconnect v9.0 (libopenconnect 5.8) using QDesktopServices * 4654501e: Remove UB parameter passing to va_list argument in OpenconnectAuthWorkerThread::openUri * f7bb3a1f: Add support for SAML based authentication when using OpenConnect VPN * 7e7690db: Clean up braceless single line conditionals in openconnectauthworkerthread.cpp
Note that the Rahul's other patch to OpenConnect is also required to successfully connect to the VPN. * 0e82c937: Do not add 'single-sign-on' to the capabilities list for AnyConnect auth requests
Fixed in Plasma 6 by Rahul Rameshbabu with https://invent.kde.org/plasma/plasma-nm/-/commit/6ef64be8645ac32fc0b42df2cee5d9ff3b57e485!
What chance does this have of making it back to stable 5? Currently only GNOME´s applet works with AnyConnect MFA and seeing as more and more companies and organizations are moving towards a stricter security policy a large number of people are going to affected by this sooner than Plasma 6 hits any mainline distros (at least I am ;)) SOFTWARE/OS VERSIONS OS: openSUSE Leap 15.5 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8
(In reply to Karli Sjöberg from comment #10) > What chance does this have of making it back to stable 5? Currently only > GNOME´s applet works with AnyConnect MFA and seeing as more and more > companies and organizations are moving towards a stricter security policy a > large number of people are going to affected by this sooner than Plasma 6 > hits any mainline distros (at least I am ;)) I believe that the Qt 5.15 WebEngine is the problem for advanced auth, so very low. You should engage your IT to enable "ext-browser" on the server side, which does work in Plasma 5.27 after you update openconnect.