-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HELP WANTED] Implement username override in OpenVPN [clang coding] #202
Comments
Hi everyone!
It looks like OpenVPN and openvpn-auth-oauth2 are somehow exchanging this data. |
It's the CLI option:
|
I am a bit confused about the ussage of openvpn-auth-oauth2, it seems to me that this is one additional layer of authentication with SSO. I still need to generate the cert for each user to connect to OpenVPN right? also it looks like I can use the same client certificate for more than one client ( of course each client will use their own credential to login to SSO ) is that right? |
No, you can disable any builtin auth layer in OpenVPN and fully delegate authentication to openvpn-auth-oauth2. In that case, there is no client certificate and client are anonymous, e.g. no CN and username. |
TL;DR: If you have the request that openvpn-auth-oauth2 should report the SSO username back to OpenVPN: This isn't currently possible in OpenVPN:
See: OpenVPN/openvpn#299
Intoduction
openvpn-auth-oauth2 is an open-source solution designed to streamline the management overhead in OpenVPN environments.
Traditionally, OpenVPN relies on X.509-based PKI for authentication using client certificates. The Common Name (CN) field of the client certificate serves as the identifier in OpenVPN. This CN is fixed early in the TLS authentication process, prior to any potential alteration by plugins or external authentication mechanisms. Additionally, OpenVPN supports username/password authentication, where both values provided by the client are also fixed. There exists an option to use the username as the common name (refer to
--username-as-common-name
in the manual page).openvpn-auth-oauth2 aims to replace the X.509-based PKI with the WEBAUTH protocol entirely, enabling the distribution of OpenVPN profiles without user-specific settings. This transition may enhance security by allowing Single Sign-On (SSO) providers such as Google Workspace, Keycloak, or Microsoft Azure AD to enrich the authentication process, potentially incorporating additional authentication methods like push-based one-time passwords or FIDO2 credentials.
The proposed idea has been implemented, with openvpn-auth-oauth2 functioning as an OpenVPN management client communicating via a TCP (plaintext) socket.
Problem Statement
Several built-in functionalities of OpenVPN rely on the common name of a connection:
--client-config-dir
in man page)--ifconfig-pool-persist
in man page)--status
in man page)client-connect
scripts are pointless, because the have no information about the authenticated user.However, these features cannot be used simultaneously with openvpn-auth-oauth2 since the OpenVPN server lacks the capability to report/override the common name while some features rely on it.
An ongoing upstream issue, OpenVPN/openvpn#299, describes this limitation. Despite recognition of the validity of the feature request by core maintainers, there has been no significant traction.
Proposed Solution
A potential solution, subject to acceptance by maintainers, is to make the username field mutable by an authentication solution (management client, plugin interface, or auth-user-pass-verify script) within OpenVPN. This would enable the username reported back by openvpn-auth-oauth2 to be used as the common name in OpenVPN, alongside the
--username-as-common-name
option.Additional information
I could found a discussion related to my feature request here: https://patchwork.openvpn.net/project/openvpn2/patch/20221010071229.7935-1-gert@greenie.muc.de/
For serious developers interested in this enhancement, a bounty can be set up through an external platform. The community can contribute to the bounty, with the condition that the feature gets merged into the default branch of OpenVPN.
The payout requirement is that the feature has been merged into the official default branch of OpenVPN.
Acceptance Criteria
The OpenVPN server should possess the capability for authentication plugins to modify the username of an incoming connection.
The text was updated successfully, but these errors were encountered: