Some feature requests

[DRO34]

Hello,
Few ideas on feature requests.

1. SSO/OIDC - Please add SAML as an option for SSO

2. Once SSO is enabled please allow the ability to block/hide the username/password field so only SSO shows up or make it so once SSO is enabled as soon as you go to your FQDN it automatically redirects to the SSO provider.. Also, if possible for backdoor access make proxcenter available on a separate sub path so you can manually go to that path. It will then present the username/password field. Some applications we use have this functionality and it works great for backdoor access when SSO is down or broken.. For example https://fqdn/access this url would present the standard auth page so you can use your admin username/password

3. Allow 2fa for admin accounts to protect for backdoor access or just in general - Just wanted to mention it again as this is very critical feature once opened to the public - eventhough from our situation we have it completely locked down. but it is still nice to have - I know it is tracked in [Feature]: 2FA #140

4. Addition - Added capability for verified push. Using DUO for example, Verified push requires a code be entered to confirm the Push not just a tap of the button which can prevent an accidental push in the event someone remotely triggers the push. We use this globally on all our applications (but of course application must support the push via api in the browser) Is this something you can look into adding for additional security? Not sure if this lends any insight into what I mean - https://help.duo.com/s/article/8871?language=en_US
   https://help.duo.com/s/article/8014?language=en_US

Thank you!

[adminsyspro]

Hi @Trembler34, thanks for the suggestions. Replying on point 3 first since it's the freshest news.

2FA landed yesterday on main (PR #351). What's in:

• TOTP (Google Authenticator, Authy, 1Password, etc.) with recovery codes (one-time, hashed at rest with PBKDF2).
• Enrollment from the profile page: 3-step wizard (scan QR, verify code, save recovery codes). Disable/regenerate require password or current TOTP re-auth.
• Step-up at login: when 2FA is enabled, the password form transitions to a 6-digit code prompt. The same field accepts a recovery code in XXXXX-XXXXX form.
• Two enforcement modes for admins:
• global policy Require 2FA for super_admin (toggle in Compliance), blocks login until the user enrolls, with a foot-shoot guard so the operator can't enable it without first enrolling themselves;
• per-user Require 2FA flag (super_admin-only action on the users page) for forcing it on a specific account regardless of role.
• Admin tooling: disable another user's 2FA from the users page (destructive confirmation, types the target email), set/clear the per-user requirement, and a 2FA column showing enrolled / pending-requirement / none.

What's not in yet: passkeys / WebAuthn. Same plan as in #140, TOTP first, passkeys could follow as a second step if there's demand.

Release status: main only for now. The current latest Docker tag is v1.4.1 (21 May), which predates this. It will ship in the next tag (v1.4.2) along with the Node 26 dispatcher hardening and the js-cookie bump. I'll comment back here when it's tagged.

[DRO34]

awesome, thanks.

[adminsyspro]

Following up on point 1 (SAML).

NextAuth (which ProxCenter uses for auth) doesn't ship a native SAML provider, so we wouldn't reimplement SAML from scratch. The standard path in the NextAuth ecosystem for this case is @boxyhq/saml-jackson, a SAML-to-OIDC bridge that's already in production at Vercel, Cal.com, Retool, etc. The idea:

• You give us your IdP's SAML metadata (entity ID, SSO URL, signing cert, attribute names) through a config screen we'd add.
• Jackson handles the SAML side end-to-end (request signing, response validation, XML crypto).
• ProxCenter's existing OIDC code talks to Jackson as an internal OIDC provider, so the login flow stays consistent with what's already there.

Jackson supports an embedded mode (no extra service to run, fits the single-container Community deployment), MIT licensed, actively maintained.

Before we commit to this approach, two questions:

1. Which IdP are you on? (Entra ID / ADFS / Okta / Keycloak / OneLogin / Google Workspace / other.) Jackson covers all the big ones but we'd want to confirm yours is in scope and ideally test against the same one.
2. Is a SAML-via-Jackson integration acceptable on your side? From your perspective the login flow looks identical to a native SAML SP (your IdP sees a normal SAML AuthnRequest, signs the response normally). But some security teams require that the SP itself be the certified SAML endpoint rather than a proxy/bridge. If that's your case it would push us toward a bespoke implementation, which is a much larger ticket. If you're flexible, Jackson is the pragmatic answer.

Let us know and we'll open a tracking issue once we have a direction.

[DRO34]

DUO for IdP and i mention SAML just because it is pretty much the standard for SSO and requires a lot less then OIDC with the scopes and a lot more nuanced of a setup. Supporting both i think would be good.. I do believe DUO supports that but i am not 100% sure. If you need more specifics with DUO let me know. I do have a business enterprise account with them.

[DRO34]

I added a 4th as It has come up if you can look into adding support for it.

[adminsyspro]

On point 4 (Verified Duo Push), @Trembler34: good news, this one needs no work on the ProxCenter side and you can turn it on today.

Because ProxCenter uses Duo via OIDC, the entire authentication (including the push) happens inside Duo's Universal Prompt. ProxCenter never renders or controls the push itself, it just hands the user off to Duo and consumes the result. Verified Duo Push is one of the authentication methods the Universal Prompt supports, and it is controlled entirely by your Duo policy.

One scope note: this covers the OIDC/SSO login path only. ProxCenter's built-in local 2FA (the TOTP from #351, for the local super_admin backdoor account) is TOTP-based and has no push concept, so Verified Push does not apply there. That account is protected by the 6-digit TOTP code instead.

[DRO34]

Verified push is not working for Proxcenter. It’s the same policy we have applied for all our other apps that work with verified push for SSO. Thats why I wanted to bring it up. Not sure why only that app is not working with it. If you say it already supports it. I will have to see what’s going on with it more from my end.

EDIT: Verfied Push is now working for proxcenter =) This was a SSO/Passwordless issue not triggering the verified push each time.

[adminsyspro]

On point 2 (SSO-only login + backdoor path), @Trembler34: this is now implemented in PR #362.

What it does, matching your three asks:

• Hide the local form: a new show_local_login toggle in the OIDC settings. When off, /login shows only the SSO button, no username/password field.
• Auto-redirect to the IdP: a force_sso_redirect toggle. When on, hitting your FQDN sends the user straight to the SSO provider without showing an intermediate page.
• Backdoor path: /access (exactly the example you gave). This route always renders the local username/password form and never auto-redirects, so an admin can sign in locally even when SSO is hidden from /login or the IdP is down.

A couple of safety notes baked in:

• The two flags only take effect when OIDC is enabled. If SSO is off, the local form is always shown, so you cannot accidentally lock yourself out by leaving a flag on.
• The login view waits for the provider config before rendering, so the local form never flashes for a moment before the redirect.

Pair this with the local 2FA from #351 and the /access backdoor account is protected by a TOTP code as well.

Release status: it is on PR #362 against main now and will ship in the next tag (v1.4.2), same train as the 2FA work and the Node 26 hardening. I will follow up here when it is tagged.

[DRO34]

Awesome work. Thank you. I showed some of this setup to some of my guys yesterday and they were impressed and loved having one location to see remote sites. Can’t wait to eventually get as many as we can migrated. 😃

[adminsyspro]

Thanks @Trembler34, really glad it landed well with your team, and that the single-pane view of remote sites resonated, that is exactly the workflow we are building toward. The SSO-only login and /access backdoor will be in the v1.4.2 tag and I will ping this thread when it ships. When you start migrating more sites, feel free to open a discussion if anything comes up, that kind of field feedback is what shapes the roadmap.

[DRO34]

Will do. Once we get the true multi tenant msp model and all of that. Things will be really shaping up and fixing some of these minor issues we’ve come across. I did mention the vnc issue in another thread and also the duo verified push issue has been resolved. That was caused by having a passwordless device not triggering the prompt when logging into Proxcenter. So once I turned off that feature all together we get the prompt verified every time.

[adminsyspro]

Good news on the multi-tenant front, @Trembler34: we are actively working on the true multi-tenant MSP model right now, and we expect to be able to ship it next week. That is the piece that pulls a lot of this together for your use case, so it is the current priority.

Glad the Duo verified push issue is sorted on your side, and thanks for capturing the root cause (passwordless device not triggering the prompt). The VNC item you raised in the other thread is noted there, we will follow up in that one so it stays tracked.