🚀 Feature: Map allowed groups to applications

[luketainton]

Feature description

Applications should have a list of allowed groups, i.e. groups of users that are allowed to use this application.

Pitch

This allows better control over which users can use which applications.

Example:
I'd like to be able to add a user to group "X" and then tell Pocket ID that for a user to be allowed access to an application, they must be in group "X". If the user signs into the app and they are in group "X" then it works as it does today. If they are not, Pocket ID should disallow authentication.

[stonith404]

Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service.

[simono41]

Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service.

I also think, it could also be set at grafana that only certain groups have access to the dashboards.

But would be a cool feature if the pocket id could also regulate itself, e.g. such an exclude or include option which services can be used with the account and which cannot.

[luketainton]

Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service.

In an ideal world yes each client would handle this themselves, but unfortunately there are plenty of applications out there that don't. Some examples:

• GlitchTip
• Gatus (you can tell it specific users to allow but not groups)
• Stirling PDF

[stonith404]

Okay, I see.

While I personally wouldn’t use this feature and believe that handling group-based access is more appropriately managed by the client, I’ll keep an eye on the interest level. If this feature request gets more likes (👍), I’ll consider implementing it.

Of course I'm also open for a pull request.

[stonith404]

This feature has received a lot of attention, so I’ll probably work on it after finishing the LDAP implementation.

[halictuz]

I was redirected to this issue. I upvote it. Would be great to see this feature. Its the only thing im missing from Authentik.

One more example. WHen using oauth2-proxy with Pocket ID it would be cool to handle access rights within Pocket ID even for such services that do not have OIDC/SSO support. While I also agree, that the services itself should handle the groups and users themselves. The reality is different though.

[ExXxtr3me]

Great that you want to implent this feature, i think it makes it easier for someone that's not a pro with setting SSO up, it' would be much easier to just allow a group access to an application in Pocket ID than to set it up in some applications. 👍

[fallenleavesgocrunch]

I just found this issue too. I may have missed something but both Hoarder and Seafile don't seem to have a way to specify what groups to allow. The ideal world the clients would handle this but the reality seems to be the oidc provider needs to.

To expand on this - I use caddy security and I reverse_proxy seafile. This was working great because caddy lets me select the required groups to use. But then I added seadoc and seadoc refused to work behind caddy security. I configured seafile as an oidc client instead and of course now I cannot specify the group to use. sigh.

[daniel-tp]

I was redirected to this issue. I upvote it. Would be great to see this feature. Its the only thing im missing from Authentik.

One more example. WHen using oauth2-proxy with Pocket ID it would be cool to handle access rights within Pocket ID even for such services that do not have OIDC/SSO support. While I also agree, that the services itself should handle the groups and users themselves. The reality is different though.

Yes I have been looking into this recently. I have Pocket-ID setup with Vouch Proxy, and found that while it works it is a very blanket solution. While currently per-client permissions can't be set in pocket-ID, when it is I think the only current solution (Beyond pocket-ID implementing it's own forward-auth or similar) is to have a different instance (and thus client credentials) of oauth2proxy/vouch per client that doesn't support OIDC. This may work for some, but isn't great for me.