I think the first option below is probably a simpler approach. One thing to note: Technically the are OpenIDConnect tokens, or at least that how it's implemented in ocserv. So, how about we do the following: --token-mode=oidc --token-secret= token | @FILE containing token. Would that make sense? -----Original Message----- From: openconnect-devel <openconnect-devel-bounces@xxxxxxxxxxxxxxxxxxx> On Behalf Of Alan Jowett Sent: Monday, March 9, 2020 7:24 PM To: Daniel Lenski <dlenski@xxxxxxxxx>; David Woodhouse <dwmw2@xxxxxxxxxxxxx> Cc: openconnect-devel@xxxxxxxxxxxxxxxxxxx Subject: RE: [EXTERNAL] Re: Patch to add support to the OpenConnect client to send RFC6750 style bearer tokens during establishment of the TLS tunnel. 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 <dlenski@xxxxxxxxx> Sent: Monday, March 9, 2020 7:03 PM To: David Woodhouse <dwmw2@xxxxxxxxxxxxx> Cc: Alan Jowett <Alan.Jowett@xxxxxxxxxxxxx>; openconnect-devel@xxxxxxxxxxxxxxxxxxx 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 <dwmw2@xxxxxxxxxxxxx> 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%7C5874df8d0be548d1bd2308d7c491ca8f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637194002760234625&sdata=BS1ac8z8Hg5YjKItgd2ifyz4BmHv5lyZU7pdCKcNvIY%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@xxxxxxxxxxxxxxxxxxx https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Fopenconnect-devel&data=02%7C01%7CAlan.Jowett%40microsoft.com%7C5874df8d0be548d1bd2308d7c491ca8f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637194002760234625&sdata=Oq8ioOIxV%2FhMkfD%2B%2BeSnZHqJl4a8rOfR4qVtHYtUPs8%3D&reserved=0 _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
