Re: OpenConnect configuration question

[David Woodhouse <dwmw2 infradead org>]

On Sat, 2010-08-21 at 13:17 -0400, Matthew Saltzman wrote:
> I notice that the OpenConnect plugin behaves differently from the other
> VPN clients.  In particular, it doesn't seem to be able to save a
> password in the keyring and log in without requiring human intervention
> to enter a password in a pop-up dialog.

We don't have gnome-keyring support for storing passwords yet. Patches
to add it would be massively appreciated.

Remember, the server can give you *arbitrary* web forms. Currently we
remember user's responses for 'select' or 'text' input fields, but not
'password' input fields. An acceptable patch would make it cope with
arbitrary input fields marked as 'password', too. Not just a single
password.

And presumably we'd want to be able to store passphrases for SSL keys?

In fact, it would *also* be useful to use the keyring for storing the
successful login 'cookie', so that you don't have to re-authenticate.
Even if it can be automatic, we don't want to re-authenticate because
that means you get a *new* IP address, due to Cisco's crappy IP
allocation code. (Please file a ticket with Cisco about that, if you are
able -- when user X logs in again within a few seconds of her previous
disconnection, even if the IP address she previously had is still
available in the pool, she doesn't get that same IP address back again.
She gets a new IP address, and all her existing connections into the VPN
are broken. This is a completely inadequate IP address allocation setup,
and they ought to be ashamed of it.)

If we get a connect request, and the keyring has a valid cookie which
still has sufficient time left before it expires, then we should use
that cookie rather than getting a new one.

> And there's this odd state where you have to click a button to start
> the login process if there isn't an option selected with a check box.

Forgive me if I'm being dim, but I'm not entirely sure what you mean
here. For reference for the peanut gallery, this is the kind of thing
we're looking at: http://david.woodhou.se/nm-openconnect-auth.png

When you ask NetworkManager to connect to the VPN, it runs the
nm-openconnect-auth-dialog tool and waits for it to spit out the IP
address of a server to connect to, and an HTTP cookie to use for
authentication.

The auth-dialog first has to choose between a number of different
servers. This list is automatically updated, from an XML configuration
file which is downloaded from the server after each successful login.

When you select a 'VPN host' from the combobox, it'll immediately start
connecting to that host and will display the forms that the host
presents for authentication.

Or if you've checked the 'Automatically start connecting next time'
option, it'll automatically start connecting to the last host you
successfully connected to, and you don't have to click anything.

Next there's the form itself. "Forms", actually, since you can get lots
of them one after the other. The dialog will just let you fill in web
forms repeatedly, until you're rewarded when the successful HTTP cookie
that you need to actually make the VPN connection. And then of course it
exits and gives NM the IP address and the cookie it was waiting for.

My example screenshot above shows a fairly traditional form where the
entry fields include 'username' and 'password', but it really doesn't
have to look like that.

As I said above, we do currently remember the user's input for all the
input fields which are marked as 'choice' or 'text' -- so the GROUP and
Username entries in the example are automatically filled in for you. As
I said, patches would be welcome to use the keyring to store 'password'
input fields too.

Once keyring support is implemented and you ask NM to connect to the
VPN, you would get *directly* to the state I show in my screenshot,
where all you have to do is click once on the 'Login' button to actually
go ahead and log in with the responses that it remembers.

Once we get to that point, it would certainly make sense to see how we
could eliminate the need for that click on the 'Login' button -- the
dialog could automatically attempt to log in, if it has answers to all
the input fields. There are plenty of details to think about to make
sure we get this right and it doesn't submit out-of-date remembered
answers, but it's certainly feasible.

> Is there a reason that's different here, and/or are there plans to
> change it? 

There are certainly plans to implement keyring support, but they're
mostly of the "I hope someone does it and sends me patches" variety.

I'm open to all kinds of other changes if you can help me understand how
it can be better. I'm not really sure I understood what you meant by
having to 'click a button to start the login process' -- the only button
I have to press is the Enter button, after typing my password. And we
can't eliminate that until *after* we implement keyring support.

-- 
David Woodhouse                            Open Source Technology Centre
David Woodhouse intel com                              Intel Corporation