starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-13 12:50:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

Usage of OIDC groups claim #344

New Issue
Closed
opened 2025-12-29 01:27:23 +01:00 by adam · 5 comments
adam commented 2025-12-29 01:27:23 +01:00
Owner
Copy Link

Originally created by @edvardvb on GitHub (Oct 5, 2022).

Feature request / question

We're in the process of setting up a Headscale instance for our organization, and are using our own Azure AD to handle authorization via OIDC.

We noticed in oidc.go at line 35 that the OIDC groups claim is read, but not used for anything specific.

We were wondering what use cases you envision down the line for this claim? I saw some comments in the file related to HostInfo, what would that entail?

For our own case, this claim would be a big help when it comes to maintaining the ACL-file as people leave and join our teams. For instance, we would love to be able to set up all members of an AD group as the source in an ACL-rule, instead of each member explicitly. This would of course require a semi-regular refresh of the ACL as well, but I think we can find a solution for that on our end 😄

Originally created by @edvardvb on GitHub (Oct 5, 2022). <!-- Headscale is a multinational community across the globe. Our common language is English. Please consider raising the feature request in this language. --> **Feature request / question** We're in the process of setting up a Headscale instance for our organization, and are using our own Azure AD to handle authorization via OIDC. We noticed in `oidc.go` at [line 35](https://github.com/juanfont/headscale/blob/main/oidc.go#L35) that the OIDC `groups` claim is read, but not used for anything specific. We were wondering what use cases you envision down the line for this claim? I saw some comments in the file related to HostInfo, what would that entail? <!-- Please include the reason, why you would need the feature. E.g. what problem does it solve? Or which workflow is currently frustrating and will be improved by this? --> For our own case, this claim would be a big help when it comes to maintaining the ACL-file as people leave and join our teams. For instance, we would love to be able to set up all members of an AD group as the source in an ACL-rule, instead of each member explicitly. This would of course require a semi-regular refresh of the ACL as well, but I think we can find a solution for that on our end 😄
adam added the enhancement label 2025-12-29 01:27:23 +01:00
adam closed this issue 2025-12-29 01:27:23 +01:00
adam commented 2025-12-29 01:27:24 +01:00
Author
Owner
Copy Link

@newellz2 commented on GitHub (Dec 8, 2022):

I submitted a pull request (#1041) that was merged that added support for authorization via the OIDC groups claim. I tested it with Keycloak and it's working well in our deployment.

@newellz2 commented on GitHub (Dec 8, 2022): I submitted a pull request (#1041) that was merged that added support for authorization via the OIDC groups claim. I tested it with Keycloak and it's working well in our deployment.
adam commented 2025-12-29 01:27:24 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Dec 15, 2022):

Gonna close this as completed

@kradalby commented on GitHub (Dec 15, 2022): Gonna close this as completed
adam commented 2025-12-29 01:27:24 +01:00
Author
Owner
Copy Link

@GoodiesHQ commented on GitHub (Aug 27, 2023):

Were you ever able to get this done? I created a group claim:
image

And set the groups scope within the headscale configuration:
image

But I always get this error:
image

AADSTS650053: The application 'TailScale' asked for scope 'groups' that doesn't exist on the resource

@GoodiesHQ commented on GitHub (Aug 27, 2023): Were you ever able to get this done? I created a group claim: ![image](https://github.com/juanfont/headscale/assets/4576046/9d89abb5-5feb-42a6-93d9-7cdee64a04b0) And set the `groups` scope within the headscale configuration: ![image](https://github.com/juanfont/headscale/assets/4576046/dc4a84f8-b50c-4418-a2c7-c27c8e577ffe) But I always get this error: ![image](https://github.com/juanfont/headscale/assets/4576046/29d1e512-23dc-4711-ad56-b3fb5469a9f1) `AADSTS650053: The application 'TailScale' asked for scope 'groups' that doesn't exist on the resource`
adam commented 2025-12-29 01:27:25 +01:00
Author
Owner
Copy Link

@newellz2 commented on GitHub (Aug 28, 2023):

Yes, it works well with Keycloak. It looks like validateOIDCCallbackParams or RegisterOIDC is returning an error because your groups claim is missing.

@newellz2 commented on GitHub (Aug 28, 2023): Yes, it works well with Keycloak. It looks like `validateOIDCCallbackParams` or `RegisterOIDC` is returning an error because your groups claim is missing.
adam commented 2025-12-29 01:27:25 +01:00
Author
Owner
Copy Link

@gentoorax commented on GitHub (Nov 17, 2023):

I think "allowed_groups" is slight different to what the OP was talking about regarding use of groups in ACLs "this claim would be a big help when it comes to maintaining the ACL-file as people leave and join our teams"

And I agree, trying to manage a changing set of users this way is painful. Furthermore, once linked with an identity provider, new people can register via the "allowed_groups" linked back to OIDC, but then unless you manually modify the ACLs to allow them access as well, they can't actually access anything if you have ACLs in place in some scenarios.

@gentoorax commented on GitHub (Nov 17, 2023): I think "allowed_groups" is slight different to what the OP was talking about regarding use of groups in ACLs _"this claim would be a big help when it comes to maintaining the ACL-file as people leave and join our teams"_ And I agree, trying to manage a changing set of users this way is painful. Furthermore, once linked with an identity provider, new people can register via the "allowed_groups" linked back to OIDC, but then unless you manually modify the ACLs to allow them access as well, they can't actually access anything if you have ACLs in place in some scenarios.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#344
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?