Skip to content

Improve Headplane/Headscale permissions and OIDC reconciliation #387

@tale

Description

@tale

Description

This is a loaded issue by a large margin but fundamentally touches several parts of how Headplane assumes authentication and OIDC are setup. Going forward this is the approach that should be taken if Headscale and Headplane use OIDC:

If there is a user returned from the Headscale API who's provider ID matches a user that Headplane has kept track of, then we can link both of those users together and store the Headscale User ID in the database with the Headplane user. This will then mean that devices owned by the Headscale user are automatically "owned" by the Headplane user in the UI.

If OIDC is not enabled for the Headplane instance, there should be NO onboarding UI whatsoever as the API key authentication is solely a "service mode" for managing Headscale as far as Headplane is concerned. Onboarding also needs to be changed to not assume a linked device will appear, but rather make a clickable dialog that does the following:

  • Offers the user an option to register a device with a node-key.
  • If Headscale does not use OIDC, allow creating a "Headscale user" for the logged in user.
  • If a device is detected to be connected via OIDC, show it automatically (current behavior).

That way OIDC is not explicitly dependent on what Headscale's OIDC configuration looks like and merely enhances the features of Headscale if they use the same client ID and issuer. I'm also no longer concerned with making this work on minimal principles. Headscale's OIDC configuration needs to be readable to validate such a setting and Headplane needs to offer an oidc.integrate_headscale option for this enhanced behavior.

Metadata

Metadata

Assignees

Labels

AuthenticationAuthentication & PermissionsBugSomething isn't workingFeatureAdditions to HeadplaneIntegrationsRelated to Headplane integrationsUI/UXRelated to the frontend UIUpstreamCaused by changes in Headscale or other upstream tools

Projects

Status

Todo

Relationships

None yet

Development

No branches or pull requests

Issue actions