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

[OIDC] Plans about Known limitation #408

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

Originally created by @yaroslavkasatikov on GitHub (Jan 6, 2023).

Hey team,

Do you have any plans for adding dynamic ACL support and ability to use OIDC groups in ACL?

Many thanks!

Known limitations:

No dynamic ACL support
OIDC groups cannot be used in ACLs
Originally created by @yaroslavkasatikov on GitHub (Jan 6, 2023). Hey team, Do you have any plans for adding dynamic ACL support and ability to use OIDC groups in ACL? Many thanks! ``` Known limitations: No dynamic ACL support OIDC groups cannot be used in ACLs ```
adam added the enhancementstalepolicy 📝 labels 2025-12-29 01:28:26 +01:00
adam closed this issue 2025-12-29 01:28:26 +01:00
adam commented 2025-12-29 01:28:27 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Jan 6, 2023):

Hi @yaroslavkasatikov we are under a huge effort to add integration testing for all the ACL functionality, in preparation for a major rewrite to cover more cases.

So yes, it will come.

@juanfont commented on GitHub (Jan 6, 2023): Hi @yaroslavkasatikov we are under a huge effort to add integration testing for all the ACL functionality, in preparation for a major rewrite to cover more cases. So yes, it will come.
adam commented 2025-12-29 01:28:27 +01:00
Author
Owner
Copy Link

@aelbarkani commented on GitHub (Jan 6, 2023):

Good news! @juanfont is there any approximative timeline for it ? We can sponsor this feature if that helps accelerating the implementation.

@aelbarkani commented on GitHub (Jan 6, 2023): Good news! @juanfont is there any approximative timeline for it ? We can sponsor this feature if that helps accelerating the implementation.
adam commented 2025-12-29 01:28:28 +01:00
Author
Owner
Copy Link

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

The OIDC implementation has been working flawlessly for authorizing new users and devices, but all ACLs have to be done completely manually. I'm currently using Azure AD for SSO, but the annoyance of having to maintain two sets of groups (one in Azure and one in Headscale) is currently unavoidable.

Imagine we have 2 group ID's within Azure
ae7941be-a6e2-42e7-90df-a68ff00779fe - Admins
53505c95-dcde-48d9-9e0a-d6ddf9b41efc - Users

When a user authenticates via OIDC:

  1. Add or udate a column in the database for OIDCGroups
  2. Add a mechanism in ACL's called oidc-groups: (in addition to the existing tag: or group: use cases)

When a user authenticates, the provided IDs in the groups claim, if provided, can be added to the database and can be updated any time a user re-authenticates. This would allow syntax like:

{
  "acls": [
    {
      "action": "accept",
      "src": [
        "oidc-group:ae7941be-a6e2-42e7-90df-a68ff00779fe",
      ],
      "dst": [
        "tag:servers:22"
      ],
    },
    {
      "action": "accept",
      "src": [
        "oidc-group:ae7941be-a6e2-42e7-90df-a68ff00779fe",
        "oidc-group:53505c95-dcde-48d9-9e0a-d6ddf9b41efc",
      ],
      "dst": [
        "tag:servers:80,443"
      ],
    },
  ]
}

Either this, or treat group: prefix as either manually putting someone in a group within the ACL OR matching a group name/ID in the oidcGroups database column.

This seems feasible, where is my glaring mistake?

@GoodiesHQ commented on GitHub (Aug 28, 2023): The OIDC implementation has been working flawlessly for authorizing new users and devices, but all ACLs have to be done completely manually. I'm currently using Azure AD for SSO, but the annoyance of having to maintain two sets of groups (one in Azure and one in Headscale) is currently unavoidable. Imagine we have 2 group ID's within Azure `ae7941be-a6e2-42e7-90df-a68ff00779fe` - Admins `53505c95-dcde-48d9-9e0a-d6ddf9b41efc` - Users When a user authenticates via OIDC: 1. Add or udate a column in the database for OIDCGroups 2. Add a mechanism in ACL's called oidc-groups: (in addition to the existing tag: or group: use cases) When a user authenticates, the provided IDs in the groups claim, if provided, can be added to the database and can be updated any time a user re-authenticates. This would allow syntax like: ``` { "acls": [ { "action": "accept", "src": [ "oidc-group:ae7941be-a6e2-42e7-90df-a68ff00779fe", ], "dst": [ "tag:servers:22" ], }, { "action": "accept", "src": [ "oidc-group:ae7941be-a6e2-42e7-90df-a68ff00779fe", "oidc-group:53505c95-dcde-48d9-9e0a-d6ddf9b41efc", ], "dst": [ "tag:servers:80,443" ], }, ] } ``` Either this, or treat `group:` prefix as either manually putting someone in a group within the ACL OR matching a group name/ID in the oidcGroups database column. This seems feasible, where is my glaring mistake?
adam commented 2025-12-29 01:28:28 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 24, 2023):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Dec 24, 2023): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 01:28:28 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 31, 2023):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Dec 31, 2023): This issue was closed because it has been inactive for 14 days since being marked as stale.
adam commented 2025-12-29 01:28:29 +01:00
Author
Owner
Copy Link

@guyguy333 commented on GitHub (Dec 31, 2023):

Please consider reopen this issue @juanfont

@guyguy333 commented on GitHub (Dec 31, 2023): Please consider reopen this issue @juanfont
adam commented 2025-12-29 01:28:29 +01:00
Author
Owner
Copy Link

@joachimtingvold commented on GitHub (Jan 10, 2024):

Yes, please re-open this as this is very much still relevant.

@joachimtingvold commented on GitHub (Jan 10, 2024): Yes, please re-open this as this is very much still relevant.
adam commented 2025-12-29 01:28:30 +01:00
Author
Owner
Copy Link

@cmueller-tp commented on GitHub (Jan 21, 2025):

Are there any updates to this? This is a major issue for being able to actually scale headscale (pun intended) :)

@cmueller-tp commented on GitHub (Jan 21, 2025): Are there any updates to this? This is a major issue for being able to actually scale headscale (pun intended) :)
adam commented 2025-12-29 01:28:30 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 22, 2025):

At the moment there is no plan to add groups from OIDC to the ACL, the main reason is that there dont seem to be any standard way the OIDC providers implement this, we are actively avoiding platforms we cannot have full end to end tests as it is unfeasible for us to maintain it over time.

As for the "Dynamic ACL", I assume in this context it is referring to having the ACL use these groups, but if not, there is not API support for updating the ACL which should be useful.

@kradalby commented on GitHub (Jan 22, 2025): At the moment there is no plan to add groups from OIDC to the ACL, the main reason is that there dont seem to be any standard way the OIDC providers implement this, we are actively avoiding platforms we cannot have full end to end tests as it is unfeasible for us to maintain it over time. As for the "Dynamic ACL", I assume in this context it is referring to having the ACL use these groups, but if not, there is not API support for updating the ACL which should be useful.
adam commented 2025-12-29 01:28:31 +01:00
Author
Owner
Copy Link

@joachimtingvold commented on GitHub (Jan 22, 2025):

[…] there dont seem to be any standard way the OIDC providers implement this

That's not true. There might not be an RFC standard describing how it should be done, but all the OIDC providers and applications that I currently use groups with operate in the same way;

  • OIDC provider can easily be customized to return any property/scope mapping (in this case: an array of groups)
  • Application has a setting to specify what property/scope to fetch "an array of groups" from

headscale would not need to care about the OIDC provider side; you'd only need to have a setting where you can specify what property/scope it should expect "an arrray of groups" from. If the setting is not specified, headscale would operate as it does today (i.e. no dynamic group fetching).

[…] we are actively avoiding platforms we cannot have full end to end tests as it is unfeasible for us to maintain it over time.

The above solution does not remove the possibility of having full end to end tests.

@joachimtingvold commented on GitHub (Jan 22, 2025): > […] there dont seem to be any standard way the OIDC providers implement this That's not true. There might not be an RFC standard describing how it should be done, but all the OIDC providers and applications that I currently use groups with operate in the same way; * OIDC provider can easily be customized to return any property/scope mapping (in this case: an array of groups) * Application has a setting to specify what property/scope to fetch "an array of groups" from headscale would not need to care about the OIDC provider side; you'd only need to have a setting where you can specify what property/scope it should expect "an arrray of groups" from. If the setting is not specified, headscale would operate as it does today (i.e. no dynamic group fetching). > […] we are actively avoiding platforms we cannot have full end to end tests as it is unfeasible for us to maintain it over time. The above solution does not remove the possibility of having full end to end tests.
adam commented 2025-12-29 01:28:31 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 22, 2025):

Sure, I can be up for the simple one where they pass groups as part of the OIDC claim, I have seen it with some providers.

The reason I am conservative is that I want to make it clear that something simple that supports many at the same time in a very simple implementation would be ok, and testable, while some providers, like google does not, and is not possible for us.

Can you open a separate issue with some example OIDC Claim JSON blobs that contains groups and explain the use case?
In this case, I imagine something simple, if there is a group in OIDC, we store it and you can use it in the ACL, nothing dynamic, nothing fancy.

@kradalby commented on GitHub (Jan 22, 2025): Sure, I can be up for the simple one where they pass groups as part of the OIDC claim, I have seen it with some providers. The reason I am conservative is that I want to make it clear that something simple that supports many at the same time in a very simple implementation would be ok, and testable, while some providers, [like google](https://github.com/juanfont/headscale/pull/1858) does not, and is not possible for us. Can you open a separate issue with some example OIDC Claim JSON blobs that contains groups and explain the use case? In this case, I imagine something simple, if there is a group in OIDC, we store it and you can use it in the ACL, nothing dynamic, nothing fancy.
adam commented 2025-12-29 01:28:31 +01:00
Author
Owner
Copy Link

@joachimtingvold commented on GitHub (Jan 22, 2025):

I just created #2366. Tried to give as much info as possible. If its feasible to do as I've described, it would be somewhat dynamic in the sense that you still have to specify what groups should have access to certain resources (the acls:{} section of acls.hujson), but you don't have to manually/statically maintain the groups and their members.

@joachimtingvold commented on GitHub (Jan 22, 2025): I just created #2366. Tried to give as much info as possible. If its feasible to do as I've described, it would be somewhat dynamic in the sense that you still have to specify what groups should have access to certain resources (the `acls:{}` section of `acls.hujson`), but you don't have to manually/statically maintain the groups and their members.
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 policy 📝 stale
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#408
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?