DefGuard
2FA - Use configured external OIDC Provider for 2FA
Is your feature request related to a problem? Please describe.
Not as such. At least not a Functional / Technical Problem with DefGuard but an Organisational Problem we see with running 2FA in our context using DefGuard.
Describe the solution you'd like
We use Authentik as an OpenIDConnect Provider and have 2FA in Place there. It is exposed to the Internet since we have both types of Applications running, exposed to the Internet and VPN internal. Evaluating DefGuard we thought that the 2FA for Wireguard would be an additional "Login" to the configured external OIDC via DefGuard Client. But instead, DefGuard just adds another TOTP to the game which is puzzling for the EndUser at least...
Describe alternatives you've considered
None with DefGuard, there are several alternatives that introduce a 2FA Approach with Additional TOTPs but that's not what we where hoping to find.
Additional context
We like OpenSource and would like to see this Feature in DefGuard (Enterprise Features) and would consider buying an Enterprise Subscription if that Feature would be met...
There is no such possibility to just enforce 2FA from external OIDC.
As a standard and a protocol OIDC has a full path of authentication and there is no possibility to just ,ask external OIDC to do TOTP or other 2FA method'.
There would need to be a full authentication path (login + pass + 2FA).
That's why we use our internal MFA to have the possibility just to do codes (totp/email - and soon more).
Hi thee and thank you for getting into this...
There is no such possibility to just enforce 2FA from external OIDC.
I'm aware of that...
As a standard and a protocol OIDC has a full path of authentication and there is no possibility to just ,ask external OIDC to do TOTP or other 2FA method'.
And this is what we are happily doing with Authentik...
There would need to be a full authentication path (login + pass + 2FA).
THAT ist exactly what I was hoping to find with DefGuard, thus the Feature Request given
That's why we use our internal MFA to have the possibility just to do codes (totp/email - and soon more).
This possibility would of cause be still available...
I'll try to make the picture more bright and clear...
- We would like to have an additional Authentication with WireGuard...
- I think that is a goal that DefGuard wants to achieve...
- We Thought that DefGuard would use the OIDC Backend for that purpose but learned that OIDC and LDAP is only used for enrollment...
- Since LDAP and OIDC are already in Place and implemented for Enrollment Authentication and Authorisation I THINK it would be quite unspectacular to implement the same call in front of the activation of the WireGuard session...
- An Administrator should be able to configure a DefGuard Site to enforce 2FA with LDAP or OIDC or DefGuard Login for the User to initiate the VPN (and that could be an exclusive or non exclusive setting together with the other "PURE" 2FA means)...
A user story would go like this...
- An enrolled user has his DefGuard Client installed and configured oh his device.
- The User clicks on Connect for a sites vpn configuration in DefGuard Client
- The DefGuard Client "knows" the admin's 2FA - OIDC LogIn enforcement configuration and thus spawns an OS Browser call towards that OIDC login flow...
- If the Browser is already Logged in to OIDC Provider nothing happens there (SSO done by the external OIDC Provider) the VPN Connection gets established...
- If the Browser is not logged in or needs to reauthenticate the "normal" OIDC Flow of the external Provider does it's thing (with or without whatever 2FA is configured there) and comes back to the DefGuard Client afterwards, the VPN Connection gets established...
- If No Authentication is present or (re)established the vpn connect is rejected by DefGuard...
A quite similar Integration is in place with our Jitsi Meet and Authentic. We have a Jitsi Meet Desktop Client that does exactly the same in order to Authenticate and Authorize the VideoCall-Moderator before opening the Conference Session...
Ok, understood. We already have requests that VPN sessions should be authenticated by external OIDC or even if the client desktop app launches there should be authentication in order to open the app.
I'll put this on the roadmap.
TODO: verify how we should proceed:
a. WebView in the desktop client? b. Open External Link in browser?
As far as I'm concerned I'd rather choose b.
Why...???
Because the User might already have an Authenticated Session in the Browser and would rather want that to be recycled. If you would use a seperate webview the oidc context would always be a new one and a user would always have to re authenticate, even if he had done that previously in the browser with some other oidc app in the same oidc context, which is not exactly what oidc and sso is about...
Oidc Apps should alwas share the given authentication session / context.
This is of cause only my opinion...
For technical analysis:
- [ ] Prepare sequence diagram for the authorization flow with external OIDC.
@4lb we need the following designs for this feature:
Desktop Client:
In the desktop client - a modal stating (maybe with a design / infographic showing a web browser opening?):
In order to connect to the VPN please login with [XYZ].
To do so, please click "Authenticate with XUZ" button below.
This will open a new window in your Web Browser and automatically redirect you to XYZ login page.
After authenticating with XYZ please get back here.
The XYZ his will be: Google/Okta/MS.. depending on what is configured in Defguard.
Also another button/link: "I have authorized" (that will check if the authentication was done in proxy).
Proxy
- Success screen:
You have been successfully authenticated. Please close this window and get back to Defguard VPN Client.
- Error screen:
There was an error during authentication with XYZ. Please click [Authenticate with XUZ" button below] to repeat the process.
Defguard
We need to have a setting that will enable MFA with external OpenID. Maybe it should be on the OpenID tab? Or maybe a new tab?
The most important thing is that when enabling external SSO MFA - we need to inform the admin that:
By enabling the external SSO Multi-Factor process, users in order to connect to VPN locations that require MFA will need to authenticate in their browser with [XYZ] on each connection.
When this settings is turned off - the VPN locations with MFA will require MFA using internal defguard SSO - and the user will have to have configured TOTP/Email MFA in their profile.
Important - if defguard instance has no external SSO configured - this features should be disabled and there should be some info - that this feature requires external SSO configuration.
@Zappo-II if you would like to test it - latest dev images + client 1.5-alpha1 supports this feature.
