We know of the deficiency, but thanks for filing.
At present nmcli doesn't handle secrets. However, we plan to implement a secret agent API in nmcli so that nmcli could provide NetworkManager with passwords.

still no updates here after 2 years? ;)

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

*** Bug 1200621 has been marked as a duplicate of this bug. ***

I have implemented VPN secrets handling in clients secret agent. It means that nmcli and nmtui can now ask for VPN passwords, and thus they can activate VPN connections even without other secret agent running (such as nm-applet).

See branch jk/clients-vpn-secrets-rh975185

I have made a test build for Fedora 23:
http://koji.fedoraproject.org/koji/taskinfo?taskID=11994604

Is this expected to work for the OpenConnect case? See https://bugzilla.redhat.com/show_bug.cgi?id=1200621#c3 for why I ask...

(In reply to Jirka Klimes from comment #6)
> See branch jk/clients-vpn-secrets-rh975185

+   /* If hints are given, then always ask for what the hints require */
+   if (request->hints && g_strv_length (request->hints)) {
+           for (iter = request->hints; iter && *iter; iter++) {

It looks like the outer if is not necessary.

Otherwise LGTM.

(In reply to David Woodhouse from comment #8)
> Is this expected to work for the OpenConnect case? See
> https://bugzilla.redhat.com/show_bug.cgi?id=1200621#c3 for why I ask...

In most VPNs it is clear what property is/might be a secret, so we can simply ask for those. For OpenConnect, if a cookie from the server has to be sent back, this won't probably work.

However NetworkManager can also find out what secrets are required from plugin and send these as hints to secret agent [1] and agent asks for them. So OpenConnect plugin might implement connect_interactive [2] (as it is done for openvpn [3]) and deliver secrets hints through NetworkManager to secret agent and clients could use that.

[1] https://developer.gnome.org/NetworkManager
/1.0/spec.html#org.freedesktop.NetworkManager.SecretAgent
[2] https://developer.gnome.org/NetworkManager/1.0/spec.html#org.freedesktop.NetworkManager.VPN.Plugin
[3] https://git.gnome.org/browse/network-manager-openvpn/tree/src/nm-openvpn-service.c#n532

As far as NM is concerned, you only need three secrets to connect to OpenConnect.

You need the final hostname (after all HTTP redirects), the hash of its certificate (after the user might have manually accepted it), and you need the 'webvpn' HTTP cookie which was granted on a successful authentication.

The actual process of talking to the server is handled by libopenconnect, which gives you those three things on a successful authentication. The NM auth-dialog links against libopenconnect, and uses it to produce those three required secrets. As does the KDE secret-agent implementation.

If you just make it possible to provide the secrets in advance when invoking nmcli, that should work.

The command-line openconnect tool already has a '--authenticate' option which makes it just handle the interactive authentication, then spit out the three secrets which are required to actually make the connection:

COOKIE='lalala'
HOST='[2001:770:15f::2]'
FINGERPRINT='sha1:dbfb45c7958d56ae72f248fc7e0841197c6af598'

If we can just get those three secrets into NetworkManager when we ask it to bring up the connection, that would suffice. Everything else can be left to an external wrapper which invokes openconnect and then nmcli.

This external wrapper would also probably want a way to query the VPN configuration (so it's just given a connection name or UUID and it finds out all the rest of the details about the server, certificates to use, stored passwords, etc. for itself. But you can leave all that as an exercise for the reader, as long as we have a way to 'prod' the required secrets into nmcli when we get to the final "make the connection" stage.

I have added a helper function for OpenConnect. It calls "openconnect --authenticate", getting the secrets and sending them to NetworkManager. Pushed upstream now.

master:
3511530 merge: enable VPN secrets for nmtui/nmcli secret agent (rh #975185)
a1536fe tui: prefill a secret in the entry if we have a value
2e345fa tui: allow connecting to OpenConnect
fb62fc7 cli: do not present secrets from openconnect to the user for confirmation
45fc268 cli: make asking VPN secrets for OpenConnect really work
ea54b7f clients: add a helper function to get required openconnect VPN secrets
8dfafac clients: add vpn_type member to secret structure in secret agent
6dd1e26 clients: move vpn_get_secret_names() to nm-vpn-helpers
de86c23 clients: enable VPN secrets for nmtui/nmcli secret agent (rh #975185)

and rebased to nm-1-0 too:
5745e95 merge: enable VPN secrets for nmtui/nmcli secret agent (rh #975185)
71cfa4f tui: prefill a secret in the entry if we have a value
3f2dd0b tui: allow connecting to OpenConnect
19756e8 cli: do not present secrets from openconnect to the user for confirmation
7acbf23 cli: make asking VPN secrets for OpenConnect really work
348ba76 clients: add a helper function to get required openconnect VPN secrets
d6b9844 clients: add vpn_type member to secret structure in secret agent
dca2ded clients: move vpn_get_secret_names() to nm-vpn-helpers
9d18afb clients: enable VPN secrets for nmtui/nmcli secret agent (rh #975185)

Scratch build for Fedora 23:
http://koji.fedoraproject.org/koji/taskinfo?taskID=12182335

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

The feature has been in Fedora 23 from NetworkManager-1.0.10-1.fc23
and also in Fedora 24 (NetworkManager-1.2.0-1.fc24)