Automated ownership permissions need to be reworked

[cchance27]

Description

When i login with a apikey, i get the "connect your first device" but if i click "i know what i'm doing", i get a full list of all my devices as expected....

If i login with OIDC, it works and i get logged in and it says the "connect your first device" if i click "i know what im doing" .... no devices show up at all...

This was a migration from a 0.24.3 headscale to 0.26.1 and we used to use strip domain name from users... not sure if that matters, in 0.26.1 we removed that setting from our config as its not valid anymore for headscale.

Headplane Version

v0.6.0

Headscale Version

v.26.1

[tale]

Yes, this is slightly intended behavior because by design, Headscale API keys are not tied to a user and therefore I consider them as "admin" keys. Default users via OIDC are actually assigned permissions on first login. You can check this in the users.json file (refer to your config for the location). It's stored as a JSON array of the user's subject and a permission number.

The first OIDC user to log in will normally receive the "owner" role, which grants them admin. So by default, you need specific permissions to view the entire list of devices. If you want to manually assign owner to a specific user, change their permission to 65535 in the JSON file.

I will say, hindsight is 2020 and requiring you to specify the users who are granted the "owner" role might make more sense rather than just assigning it willy nilly.

[cchance27]

hmmm...

[{"u":"102158659552393480743","c":0,"oo":true},{"u":"unknown-non-oauth","oo":true}]

so doesn't look like it got assigned the 65535, i set c to 65535 and restarted headplane and now i can see them all

I mean its a minor issue and now that i know it was easy enough to fix.

Does feel like some better explanation could be on the users page, as well as showing the current oidc users and permissions on the users page.

[tale]

Hmmm, this is definitely a bug then, it should've set it to 65535. But you are also correct, I will document this better.

[lpereira]

Would it make sense to have a OIDC-group-to-role mapping in the configuration?

[tale]

We could do that, how would you foresee that being configured?

[lpereira]

I have to think a little bit about this; a simplistic map in the YAML file would work for me, but it might not be sufficient for everybody.

It may be better if I explain my use case a little bit.

I'm running Headscale (and now Headplane -- which is incredibly nice, by the way, thank you so much!) at my local hackerspace, so that members can link up their computers. We do have an OIDC server set up, that we already use for other services, so it makes sense to reuse it for the tailnet as well.

Right now, even though people can use OIDC to log onto Headplane, they don't have access to the UI, and can't add/remove/edit their own machines. It would be nice if I could map already existing groups (e.g. "hackerspace-member") to an "it_admin" (or some other role), so that I wouldn't need to update the Headplane database manually to give them the required capabilities. Allowing machines to be associated with OIDC users (rather than only Headplane-managed users) would also be pretty cool, and help with this use case quite a bit.

It may be the case that adding new capabilities, such as read_own_machines and write_own_machines could be added to the member role, alongside ui_access, would also make sense for this particular use case.

[tale]

It's not necessarily easy to associate OIDC users with machines only because I have no control of Headscale's internal state. I could synchronize it, but in my previous experience it doesn't play nicely. I'll probably do a YAML keyed system for now just to assign groups to roles automatically on registration.

Keep in mind, I don't keep groups up to date, so for now this would probably run only on registration until I have time to implement a cron or watching system to see if permissions need to be updated.