[OIDC] Plans about Known limitation

[yaroslavkasatikov]

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

[juanfont]

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.

[aelbarkani]

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

[GoodiesHQ]

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?

[github-actions]

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

[github-actions]

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

[guyguy333]

Please consider reopen this issue @juanfont

[joachimtingvold]

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

[cmueller-tp]

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

[kradalby]

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.

[joachimtingvold]

[…] 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.

[kradalby]

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.

[joachimtingvold]

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.