On Wed, 2020-01-22 at 20:05 +0000, Alan Jowett wrote: > OpenConnect folks, > > Patch to add support to the OpenConnect client to send RFC6750 style bearer tokens during establishment of the TLS tunnel. > > Background: > My team is working on a feature to support using OpenID Connect > tokens (https://openid.net/specs/openid-connect-core-1_0.html) to > authenticate and authorize clients connecting to an OpenConnect > server. There are growing list of OpenID Connect providers that this > should work with, making this change fairly broadly applicable. > > Overall flow would be along the following lines: > Client authenticates to the OpenID Connect provider based on their > policy (potentially including MFA or other options) and obtains a > OIDC token. > Client then includes that token in the HTTP header when connecting to > the OpenConnect server. > OpenConnect server verifies claims in the OIDC token and then allows > or denies the connection. > > My team is also working on the server side changes, but writing the > tests would be easier if we can use the stock OpenConnect client. > > Please let me know if there are any questions about this. Hi Alan, thanks for the patch. In general it looks sensible so far. A couple of minor tech review points: Please could you make sure that the new ->proxy_bearer_token and ->bearer_token fields are freed in openconnect_vpninfo_free() in library.c. Does this even make sense for proxy auth? Is the 'Proxy-Bearer:' form actually defined and will it ever be implemented? Not that I have much objection to the way you've done things if the answer is no; we already support Basic and NTLM-with-password support *only* for proxies and not for the real HTTP connection and this would just be the converse. Moving on to the more high-level review.... what is the expected user experience here? Looking at Figure 1 of RFC6750: +--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+ Figure 1: Abstract Protocol Flow What you're implementing in OpenConnect is purely part (E), right? An external wrapper or something is expected to obtain the Access Token for us, and indeed also to *renew* it when necessary? Or is it a one- use token? Shouldn't we be implementing the whole protocol, so OpenConnect can obtain the token for itself? We already need to extend OpenConnect so that at least the GUI authentication tools (using libopenconnect) can spawn a WebView for various types of VPN, and let it run until it wins a certain cookie or redirects to a certain URL/scheme. Do we want to use that same mechanism to *obtain* (or renew) the bearer token? 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. 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
