goauthentik / goauthentik/authentik
Allow entitlements to be used as application access bindings
- Dominant language
- Python
- Stars
- 25.6k
- Forks
- 2k
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 651
Description
**Is your feature request related to a problem? Please describe.**
When using Entitlements for applications, we currently have to specify users/groups twice to provide access. Once for the relevant entitlement, and then also for the Policy/Group/User Bindings.
Additionally, for applications that does not support the OIDC groups scope (and therefore cannot use Entitlements), I cannot see a good way of creating application specific/scoped groups.
Eg. while I may create a group, and provide that group access to an application. I cannot restrict that group to only be used for that specific application, neither can I easily see from the group which applications it provides access for.
**Describe the solution you'd like**
Ability to either manually, or automatically use Entitlements for Application Bindings. Eg. if you create an Entitlement for an application, and add "app-users" as a group for that entitlement, the "app-users" group should also get access to the Application itself.
This to solve two things:
1. Avoid duplicate work, all users with an Entitlement binding (normally? are there exceptions?) also requires access to the application itself. Currently users/groups that need access to an application must be defined twice, once in the relevant Entitlement, and then also in the "Policy / Group / User Bindings" tab to allow access.
2. Allows you to "group" users only using a Application Entitlement. Eg. if creating a view Entitlement for an application, and adding user/group bindings there.
**Describe alternatives you've considered**
N/A
**Additional context**
Mock-up image:

Contributor guide
Research direction
Start by tracing how application access bindings and entitlements are evaluated, including Policy, Group, and User Bindings. Compare the proposed manual and automatic approaches, and identify cases where entitlement access should not imply application access. Done means the chosen behavior is implemented without duplicate bindings and is covered by appropriate tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- authorization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100