Implement a richer AuthZ model #1099

New issue

Open

opened 2026-02-20 14:11:03 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-20 14:11:03 -05:00

Owner

Originally created by @simonarnell on GitHub (Jan 10, 2026).

Originally assigned to: @mdevaev on GitHub.

Is your feature request related to a problem? Please describe.
When using the PiKVM Switch, it would be great to specify which ports of the Switch a given user is authorised to access and what functions they can perform, this latter aspects applies to PiKVM more generally than just with use of the Switch.

Describe the solution you'd like
An OIDC (requiring #161) claims-based model for AuthN, allowing for the offloading of AuthN and user attribute enrichment. Whilst a Policy Decision Point implemented in something like OPA could supply which ports / functions a given identity / group / attribute is authorised to access and the PiKVM API endpoints can serve as the Policy Enforcement Point.

Logging of which identities (un)successfully accessed which ports would be a great further addition.

Describe alternatives you've considered
The ability to specify on a per PiKVM basis, the ACLs for users / groups, specifying which ports and functions they can perform - perhaps using a device local instance of OPA.

Additional context
N/A

Originally created by @simonarnell on GitHub (Jan 10, 2026). Originally assigned to: @mdevaev on GitHub. **Is your feature request related to a problem? Please describe.** When using the PiKVM Switch, it would be great to specify which ports of the Switch a given user is authorised to access and what functions they can perform, this latter aspects applies to PiKVM more generally than just with use of the Switch. **Describe the solution you'd like** An OIDC (requiring #161) claims-based model for AuthN, allowing for the offloading of AuthN and user attribute enrichment. Whilst a Policy Decision Point implemented in something like OPA could supply which ports / functions a given identity / group / attribute is authorised to access and the PiKVM API endpoints can serve as the Policy Enforcement Point. Logging of which identities (un)successfully accessed which ports would be a great further addition. **Describe alternatives you've considered** The ability to specify on a per PiKVM basis, the ACLs for users / groups, specifying which ports and functions they can perform - perhaps using a device local instance of OPA. **Additional context** N/A