RE: [EXTERNAL] Re: Patch to add support to the OpenConnect client to send RFC6750 style bearer tokens during establishment of the TLS tunnel.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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&amp;data=02%7C01%7CAlan.Jowett%40microsoft.com%7C5874df8d0be548d1bd2308d7c491ca8f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637194002760234625&amp;sdata=BS1ac8z8Hg5YjKItgd2ifyz4BmHv5lyZU7pdCKcNvIY%3D&amp;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&amp;data=02%7C01%7CAlan.Jowett%40microsoft.com%7C5874df8d0be548d1bd2308d7c491ca8f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637194002760234625&amp;sdata=Oq8ioOIxV%2FhMkfD%2B%2BeSnZHqJl4a8rOfR4qVtHYtUPs8%3D&amp;reserved=0
_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux