Messages

Hello,

I am not sure if this is related, since the ACME client (issuing/renewing) and the OPNCentral cert push (distribution) are really separate paths – but in case it helps: after the last two updates I had ACME client trouble too (different DNS provider), which I could clear with a ,,Reset ACME Client" + ,,Renew Certificate". Probably not related to the push mechanism you're describing, though.

Cheers,
Marco

Wrote this up as a feature request: https://github.com/opnsense/core/issues/10435

Short version: an option to require membership in at least one configured group and deny the login otherwise, instead of constraint_groups only doing the mapping.

Sorry if the wording/description of the FR is a bit clumsy – all this ,,who's in which group and why" logic makes my head spin. I'm clearly better with firewalls than with group theory. 😉

Cheers,
Marco

Yes, I agree that OPNsense should have an internal check as well. Something like "require membership in at least one of the configured groups, otherwise deny" would be much easier to set up than per-client flow overrides, especially when multiple teams need access. It looks like constraint_groups only changes how groups are mapped right now, not whether access is granted, so a real "deny if not a member" option would be nice to have.

Meanwhile, if you're using Keycloak, you can solve this server-side on the IdP: duplicate the browser flow, add a conditional sub-flow with a "Condition — user role" (negated) plus a "Deny Access" execution, and bind that flow to the OPNsense client only (Clients -> Advanced -> Authentication flow overrides). When you gate on a role and map your group to it, people who aren't in your group won't get a token at all, so OPNsense doesn't create them automatically. No auth proxy required.

Cheers,
Marco

Quick follow-up: I had a bit of time this morning to dig into this and test it on a BE VM. Turns out the deep-link target is already available on the login page (OPNsense puts it in $_GET['url'], same as the password login uses), so it just needs to be carried through the OIDC flow and applied at the end instead of always landing on the dashboard. I got it working end-to-end on the VM.

I've opened a feature request with the details (validation helper, the open-core changes, and the two Business Edition controller inserts described by file/method): https://github.com/opnsense/core/issues/10433

Cheers,
Marco

Thanks, will do. I'll open a feature request on GitHub. But I'm pretty busy right now, so it might take me a few days to get to it. I'll post the link here once it's filed.

Cheers,
Marco

I suspect this isn't a config error on your side. I'm seeing the same behavior here.

As far as I can tell, the redirect_uri has to be the fixed .../api/oidc/rp/finalize/<appcode> callback, and finalize seems to just create the session and send you to the dashboard. My guess is the originally requested URL simply isn't carried through the round trip (it would need to be stashed in the OAuth state and restored at finalize), so it gets lost—whereas with password login that URL never leaves OPNsense, which would explain why it works there.

I also couldn't find any setting for it: the WebGui/Admin provider only exposes Application code, Service, Extensive log, and Description.

Since it's a Business Edition feature, I assume any fix would have to come from Deciso – probably worth a feature request to preserve the original REQUEST_URI (validated as a local /ui/... path so it can't become an open redirect).