Thanks for the feedback. I have mostly been focused on the ocserv side of this change. Now that the server side is in ocserv, I will resume working on this.
-----Original Message----- From: Daniel Lenski <dlen...@gmail.com> Sent: Monday, March 9, 2020 7:03 PM To: David Woodhouse <dw...@infradead.org> Cc: Alan Jowett <alan.jow...@microsoft.com>; openconnect-devel@lists.infradead.org Subject: [EXTERNAL] Re: Patch to add support to the OpenConnect client to send RFC6750 style bearer tokens during establishment of the TLS tunnel. On Thu, Jan 23, 2020 at 3:36 AM David Woodhouse <dw...@infradead.org> wrote: > > Even if not, if the bearer token is persistent and just stored > alongside the VPN configuration, we need a way for libopenconnect to > provide it; please either add an API for it in addition to the > command- line option you add in main.c, or let's see if we can work it > into the generic form handling as a specific thing that gets requested. I just left a review on this MR. Couple small issues around enable-by-default that could use eyeballs. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fopenconnect%2Fopenconnect%2F-%2Fmerge_requests%2F70&data=02%7C01%7CAlan.Jowett%40microsoft.com%7C843970faaecc423a949108d7c48ede87%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193990207422279&sdata=RMCU61Wb%2Bzfl8KRrmnV9p3PON6BkOdZ3p1JQASgr3%2B0%3D&reserved=0 > For example, if we see an 'Authorization: Bearer' challenge and we > *don't* already have a token, we could present the user with a form > asking for the token? You still need a wrapper or something to provide > it, but it fits into the NetworkManager secret storage model without > any changes that way. The Bearer token could also be supported via… * `--token-mode=BEARER --token-secret=(string or filename)`, same as RSA or OATH tokens, rather than adding a new `--bearer-token` option. That way, we wouldn't need to add any new API functions, and GUIs could support it simply by adding a new option to their token mode dropdown. The Bearer would be treated basically like an RSA or OATH secret: something that the user has to configure ahead of time, rather than enter on-the-fly. Upside: no new API functions. Downside: this probably isn't the way the Bearer token is used in the real world. It probably doesn't remain valid for a long time. * Treating it as an alternative that replaces the password, much like the GlobalProtect+SAML “alternative secret.” Perhaps add an `--alt-secret=[BEARER, GP-cookie-name]` option to integrate the two? Upside: probably closer to the way it's actually used. Would allow us to get rid of my horrid GP urlpath hack, or at least replace it 😬 Downside: still doesn't give OpenConnect a way to do the whole auth flow from the CLI/API, or integrate with a GUI auth dialog. Thanks, Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
