Feature Request: Pass Client ID and Key ID to plugins

[jkroepke]

Hi,

I'm currently looking for possibilities in my OpenVPN auth plugin (https://github.com/jkroepke/openvpn-auth-oauth2) to replace the management interface with the plugin API.

I'm wondering why Client ID and Key ID is not passed and I would like to asked, if they can added as ENV as well.

[cron2]

I would guess "because nobody needed it yet" - for the use cases I had so far I didn't need them, and in general not that many people seem to use the plugin API.

Not sure how complicated this is to add on the OpenVPN side - it's been a while since I looked at those code paths (mostly when reviewing and testing the deferred client-connect implementation in 2.5). @schwabe might have ideas and opinions.

[schwabe]

client id and key id are also basically only used in the management interface to identify the connection. For the plugin/script interface there is no need to identify the client this way since the plugin/script is called exactly for a single authentication and expects the return for that. The client ID does not even exist in the code without management support enabled.

So you need to explain a bit more detailed why you think you need the client id in the plugin interface

[jkroepke]

since the plugin/script is called exactly for a single authentication and expects the return for that.

If users are initially authenticated, I want to store a cookie on the server. The value of this cookie is larger than the allowed auth-token size.

During re-authentication (soft reset), I plan to use the stored cookie to perform re-authentication against an external system.

I believe binding the cookie to the ClientID is the best approach OpenVPN offers in this context. It ensures the cookie cannot be leaked to other connections.

The overall use case here is that the auth_oauth2 plugin is currently implemented as an OpenVPN Management Interface solution, even though it does not provide actual management functionality. Since OpenVPN supports only one Management Interface client at a time, I would like to re-implement jkroepke/openvpn-auth-oauth2 as a proper OpenVPN plugin, if possible.

[jkroepke]

close by mis-click.

[schwabe]

Just auth auth-token and auth-token-user for that?

[jkroepke]

Such cookie values (for example, OIDC JWT tokens) can be up to 8 KiB in size.

Following the discussion at #295, passing larger values appears problematic. That is why I would like to store such large values inside the memory area of the plugin and re-use them when re-authentication is requested.

I have not the feeling that the proposal of larger values is getting accepted.

[schwabe]

Yeah but to identify that it is the same client again, you should just use an auth-token . Nobody expects you to pass your 8k token in the auth-token just but a 32 character random string into the authtoken that you also have in memory. So if you see the auth-token again, you know it is the same client. auth-token is designed to store basically a session ID so the server knows that it is the same client again.

If you use the integrated auth-gen-token of OpenVPN it will also provide a session id in the environment that allow to identify the session in reconnects and renegotiations. If you do not want to use that, you can do something similar with your own generated auth-token/auth-token-user

[jkroepke]

The benefit of using the Client ID instead of the auth-token is that the Client ID is already available during the authentication step. After successful authentication, I can safely link any token to that specific Client ID.

Using OpenVPN’s auth-gen-token is not an option here, because it generates the token after the user is authenticated. I could work around this by generating a custom token, but that would break all the features OpenVPN provides with auth-gen-token.

Another reason to rely on the Client ID in this plugin: during initial authentication, users get redirected to a browser using a WEBAUTH URL. Since the login happens in a different context (outside OpenVPN), I use the Client ID to make sure the login is bound to the correct VPN session.

I could have used the auth_control_file as a unique identifier for this, but it’s too long. The WEBAUTH URL must stay under 230 characters, and I need room for other data as well.

[schwabe]

The benefit of using the Client ID instead of the auth-token is that the Client ID is already available during the authentication step.

It is not. The client-id is an internal number that the management interface manages. If you disable managment, OpenVPN will not assign these numbers. So providing them to plugins/scripts would be not as easy. Especially since we don't want to have the behaviour of scripts/plugins to depend on whether management support is compiled in or not.

Using OpenVPN’s auth-gen-token is not an option here, because it generates the token after the user is authenticated. I could work around this by generating a custom token, but that would break all the features OpenVPN provides with auth-gen-token.
The unique session id that auth-gen-token generates is already available in the environment as session_id before the user is authenticated. That is how our product tracks unique sessions.

Also this goes against what you said in your initial message, that you want to be able to identify a user renegotiation. Does having an integer vs a session_id make that much different?

Another reason to rely on the Client ID in this plugin: during initial authentication, users get redirected to a browser using a WEBAUTH URL. Since the login happens in a different context (outside OpenVPN), I use the Client ID to make sure the login is bound to the correct VPN session.

Do you trust the client to never modify the web auth url?

Maybe you need to have a bit more detailed explaination of your auth process. I don't see a good reason so far that you would need client id which server a different purpose in management alltogether anyway, to be able to tell what reply is for what query.