-
-
Notifications
You must be signed in to change notification settings - Fork 177
Improve Headplane/Headscale permissions and OIDC reconciliation #387
Copy link
Copy link
Open
Labels
AuthenticationAuthentication & PermissionsAuthentication & PermissionsBugSomething isn't workingSomething isn't workingFeatureAdditions to HeadplaneAdditions to HeadplaneIntegrationsRelated to Headplane integrationsRelated to Headplane integrationsUI/UXRelated to the frontend UIRelated to the frontend UIUpstreamCaused by changes in Headscale or other upstream toolsCaused by changes in Headscale or other upstream tools
Milestone
Metadata
Metadata
Assignees
Labels
AuthenticationAuthentication & PermissionsAuthentication & PermissionsBugSomething isn't workingSomething isn't workingFeatureAdditions to HeadplaneAdditions to HeadplaneIntegrationsRelated to Headplane integrationsRelated to Headplane integrationsUI/UXRelated to the frontend UIRelated to the frontend UIUpstreamCaused by changes in Headscale or other upstream toolsCaused by changes in Headscale or other upstream tools
Projects
Status
In Progress
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:
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_headscaleoption for this enhanced behavior.