| Message ID | 20210728124103.565145-1-arne@rfc2549.org |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [Openvpn-devel,v2] Introduce webauth auth pending method and deprecate openurl | expand |
Hi, On Wed, Jul 28, 2021 at 02:41:03PM +0200, Arne Schwabe wrote: > The experience with openurl/OPEN_URL has shown that just sending > a URL to a client is not enough and we often need different > behaviour of the client depending on circumstances. Replace > OPEN_URL with a more flexible WEB_AUTH pending auth method. > > Patch v2: use WEB_AUTH instead WEBAUTH [..] I think this is mostly ready, except for a small oversight: > -proxy_url > -======== > -This is a variant of openurl that allows opening a url via an > +webauth with proxy > +================== > +This is a variant of webauth that allows opening a url via an > HTTP proxy. It could be used to avoid issues with OpenVPN connection's > persist-tun that may cause the web server to be unreachable. > The client should announce proxy_url in its IV_SSO and parse the > PROXY_URL message. The format of {EXTRA} in this case is ^^^^^^^^^ there is no PROXY_URL anymore, so this might read ... and parse the "proxy=..." part of the "flags" section. The format of {EXTRA} in this case is: Or something like this. gert
Hi, -proxy_url > -======== > -This is a variant of openurl that allows opening a url via an > +webauth with proxy > +================== > +This is a variant of webauth that allows opening a url via an > HTTP proxy. It could be used to avoid issues with OpenVPN connection's > persist-tun that may cause the web server to be unreachable. > The client should announce proxy_url in its IV_SSO and parse the > PROXY_URL message. The format of {EXTRA} in this case is > "PROXY_URL message" above should be replaced by "proxy flag and related flags in the message" (Gert has already pointed this out.) But we keep the requirement that compliant clients should announce "proxy" in IV_SSO, right? As the flag is called "proxy", I suggest we change that IV_SSO value to "proxy" as well. With "flags", WEBAUTH is extensible and we have to decide which features require an explicit announce from the client. As not every client may be ready to support proxy, looks reasonable to require it in IV_SSO. We may soon require a section titled IV_SSO and list all legal values in there. - > PROXY_URL:<proxy>:<proxy_port>:<proxyuser_base64>:<proxy_password_base64>:url > + > WEB_AUTH:proxy=<proxy>;<proxy_port>;<proxyuser_base64>;<proxy_password_base64>,flags:url > This may be an opportunity to change proxyuser_base64 to proxy_user_base64 as well. That would match proxy_password_base64 and proxy_port. > > The proxy should be a literal IPv4 address or IPv6 address enclosed in [] > to avoid > ambiguity in parsing. A literal IP address is preferred as DNS might not > be > diff --git a/include/openvpn-plugin.h.in b/include/openvpn-plugin.h.in > index abbfd9c2a..28b845af1 100644 > --- a/include/openvpn-plugin.h.in > +++ b/include/openvpn-plugin.h.in > @@ -573,7 +573,7 @@ OPENVPN_PLUGIN_DEF openvpn_plugin_handle_t > OPENVPN_PLUGIN_FUNC(openvpn_plugin_op > * auth_pending_file is > * line 1: timeout in seconds > * line 2: Pending auth method the client needs to support (e.g. openurl) > - * line 3: EXTRA (e.g. OPEN_URL:http://www.example.com) > + * line 3: EXTRA (e.g. WEBAUTH::http://www.example.com) > * > * In addition the OPENVPN_PLUGIN_CLIENT_CONNECT_DEFER and > * OPENVPN_PLUGIN_CLIENT_CONNECT_DEFER_V2 are called when OpenVPN tries to > -- Looks good otherwise. Selva <div dir="ltr"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> -proxy_url<br> -========<br> -This is a variant of openurl that allows opening a url via an<br> +webauth with proxy<br> +==================<br> +This is a variant of webauth that allows opening a url via an<br> HTTP proxy. It could be used to avoid issues with OpenVPN connection's<br> persist-tun that may cause the web server to be unreachable.<br> The client should announce proxy_url in its IV_SSO and parse the<br> PROXY_URL message. The format of {EXTRA} in this case is<br></blockquote><div><br></div><div>"PROXY_URL message" above should be replaced by "proxy flag and related flags in the message" (Gert has already pointed this out.)</div><div>But we keep the requirement that compliant clients should announce "proxy" in IV_SSO, right? As the flag is called "proxy", I suggest we change that IV_SSO value to "proxy" as well.</div><div><br></div><div>With "flags", WEBAUTH is extensible and we have to decide which features require an explicit announce from the client. As not every client may be ready to support proxy, looks reasonable to require it in IV_SSO.</div><div><br></div><div>We may soon require a section titled IV_SSO and list all legal values in there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> - PROXY_URL:<proxy>:<proxy_port>:<proxyuser_base64>:<proxy_password_base64>:url<br> + WEB_AUTH:proxy=<proxy>;<proxy_port>;<proxyuser_base64>;<proxy_password_base64>,flags:url<br></blockquote><div><br></div><div>This may be an opportunity to change proxyuser_base64 to proxy_user_base64 as well. That would match proxy_password_base64 and proxy_port. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> The proxy should be a literal IPv4 address or IPv6 address enclosed in [] to avoid<br> ambiguity in parsing. A literal IP address is preferred as DNS might not be<br> diff --git a/include/<a href="http://openvpn-plugin.h.in" rel="noreferrer" target="_blank">openvpn-plugin.h.in</a> b/include/<a href="http://openvpn-plugin.h.in" rel="noreferrer" target="_blank">openvpn-plugin.h.in</a><br> index abbfd9c2a..28b845af1 100644<br> --- a/include/<a href="http://openvpn-plugin.h.in" rel="noreferrer" target="_blank">openvpn-plugin.h.in</a><br> +++ b/include/<a href="http://openvpn-plugin.h.in" rel="noreferrer" target="_blank">openvpn-plugin.h.in</a><br> @@ -573,7 +573,7 @@ OPENVPN_PLUGIN_DEF openvpn_plugin_handle_t OPENVPN_PLUGIN_FUNC(openvpn_plugin_op<br> * auth_pending_file is<br> * line 1: timeout in seconds<br> * line 2: Pending auth method the client needs to support (e.g. openurl)<br> - * line 3: EXTRA (e.g. OPEN_URL:<a href="http://www.example.com" rel="noreferrer" target="_blank">http://www.example.com</a>)<br> + * line 3: EXTRA (e.g. WEBAUTH::<a href="http://www.example.com" rel="noreferrer" target="_blank">http://www.example.com</a>)<br> *<br> * In addition the OPENVPN_PLUGIN_CLIENT_CONNECT_DEFER and<br> * OPENVPN_PLUGIN_CLIENT_CONNECT_DEFER_V2 are called when OpenVPN tries to<br> --</blockquote><div><br></div><div>Looks good otherwise.</div><div><br></div><div>Selva</div></div></div>
diff --git a/doc/management-notes.txt b/doc/management-notes.txt index c20344298..d794a4a98 100644 --- a/doc/management-notes.txt +++ b/doc/management-notes.txt @@ -645,11 +645,11 @@ Before issuing a client-pending-auth to a client instead of a client-auth/client-deny, the server should check the IV_SSO environment variable for whether the method is supported. Currently defined methods are crtext for challenge/response using text -(e.g., TOTP), openurl and proxy_url for opening a URL in the client to -continue authentication. A client supporting the first two methods would -set +(e.g., TOTP), openurl (deprecated) and webauth for opening a URL in +the client to continue authentication. A client supporting webauth and +crtext would set - setenv IV_SSO openurl,crtext + setenv IV_SSO webauth,crtext The variable name IV_SSO is historic as AUTH_PENDING was first used to signal single sign on support. To keep compatibility with existing @@ -668,33 +668,50 @@ notification as where {EXTRA} is formatted as received from the server. Currently defined formats for {EXTRA} are detailed below. -openurl -======== +webauth and openurl +=================== For a web based extra authentication (like for SSO/SAML) {EXTRA} should be OPEN_URL:url -and client should ask the user to open the URL to continue. +or + + WEB_AUTH:flags:url + +The OPEN_URL method is deprecated as it does not allow to send flags which +proved to be needed to signal certain behaviour to the client. + +The client should ask the user to open the URL to continue. The space in a control message is limited, so this url should be kept short to avoid issues. If a longer url is required a URL that redirects -to the longer URL should be sent instead. +to the longer URL should be sent instead. The total length is limited to 1024 +bytes which includes the INFO_PRE:WEB_AUTH:flags. + +flags is a list of flags which are separated by commas. Currently defined +flags are: + +- proxy (see next pargraph) +- hidden start the webview in hidden mode (see openvpn3 webauth documentation) +- external Do not use an internal webview but use an external browser. Some + authentication providers refuse to work in an internal webview. + A complete documentation how URLs should be handled on the client is available in the openvpn3 repository: https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md -proxy_url -======== -This is a variant of openurl that allows opening a url via an +webauth with proxy +================== +This is a variant of webauth that allows opening a url via an HTTP proxy. It could be used to avoid issues with OpenVPN connection's persist-tun that may cause the web server to be unreachable. The client should announce proxy_url in its IV_SSO and parse the PROXY_URL message. The format of {EXTRA} in this case is - PROXY_URL:<proxy>:<proxy_port>:<proxyuser_base64>:<proxy_password_base64>:url + WEB_AUTH:proxy=<proxy>;<proxy_port>;<proxyuser_base64>;<proxy_password_base64>,flags:url The proxy should be a literal IPv4 address or IPv6 address enclosed in [] to avoid ambiguity in parsing. A literal IP address is preferred as DNS might not be diff --git a/include/openvpn-plugin.h.in b/include/openvpn-plugin.h.in index abbfd9c2a..28b845af1 100644 --- a/include/openvpn-plugin.h.in +++ b/include/openvpn-plugin.h.in @@ -573,7 +573,7 @@ OPENVPN_PLUGIN_DEF openvpn_plugin_handle_t OPENVPN_PLUGIN_FUNC(openvpn_plugin_op * auth_pending_file is * line 1: timeout in seconds * line 2: Pending auth method the client needs to support (e.g. openurl) - * line 3: EXTRA (e.g. OPEN_URL:http://www.example.com) + * line 3: EXTRA (e.g. WEBAUTH::http://www.example.com) * * In addition the OPENVPN_PLUGIN_CLIENT_CONNECT_DEFER and * OPENVPN_PLUGIN_CLIENT_CONNECT_DEFER_V2 are called when OpenVPN tries to
The experience with openurl/OPEN_URL has shown that just sending a URL to a client is not enough and we often need different behaviour of the client depending on circumstances. Replace OPEN_URL with a more flexible WEB_AUTH pending auth method. Patch v2: use WEB_AUTH instead WEBAUTH Signed-off-by: Arne Schwabe <arne@rfc2549.org> --- doc/management-notes.txt | 41 ++++++++++++++++++++++++++----------- include/openvpn-plugin.h.in | 2 +- 2 files changed, 30 insertions(+), 13 deletions(-)