authentik

authentik copied to clipboard

Describe your question/ I'm trying to assign some user the permissions to manage the members of a specific group, by using the new RBAC features and assigning object permissions and global permissions

Relevant infos Authentik 2023.10.6

Screenshots

Permissions of the user that should be able to manage the group members:

Screenshot of error message and failed (403) request when trying to add a new group member:

Additional context From what I understand after reading the source code for a few minutes I'm think that I should be running into this GroupView action:

https://github.com/goauthentik/authentik/blob/main/authentik/core/api/groups.py#L149C1-L149C60

It's setup with required the authentik_core.add_user permission, which the user has assigned as a global permission. It also has the authentik_core.change_group permission on that specific Group object as far as I understand.

I'm not sure which permission is missing, or which permission check is failing here.

Also, I'm not sure if checking for authentik_core.add_user permission is correct here - shouldn't this rather be an additional permission to check (e.g. authentic_core.add_group_member and authentic_core.remove_group_member) similar to how additional permissions have been added on the User model? https://github.com/goauthentik/authentik/blob/main/authentik/core/models.py#L275

It seems like this method is requiren people to create new Users just to be able to add existing users to existing groups, which seems like unnecessarily wide permissions.

My use-case for this is that I want to grant some unprivileged users the permission to manage the members of specific groups. This would allow me to give owners of an application that uses Authentik for authentication to control who exactly can authenticate for that application, which we would like to use as a very binary authorization function.

Am I misunderstanding something here, or is this an actual issue with the very early preview of RBAC?

I really appreciate you adding the RBAC feature by the way, it would solve a huge issue and remove a bunch of work for us!

Am I misunderstanding something here, or is this an actual issue with the very early preview of RBAC?

I just tested out this feature today aswell and expected that exact behaviour like you said. Basically thats how the most services like that work. Glad I found out that im not alone.

I also experimented with a few additional permissions, such as "Core Can Change User" but these did not work either. Therefore, I'm starting to think this might be a bug in the RBAC system.

From me also great feature. keep up the great work!

Hey @JanKoppe just make the following changes and it should do the trick ->

1. Remove Can Change User permission
2. Add Can add Group permission

This worked for me and I was able to create group managers

@hiteshsondhi88 thanks for the suggestion. We've already saw that as well, but this is a complete no-go: This will allow those group managers to create groups with superadmin privileges and thus elevate their privileges. Security-wise, this would be a complete no-go.

@JanKoppe Can add Group doesn't allow users to create groups. If they try they just get a loading screen:

It's poorly named and really means "can add user to group"

They can do it via the API, e.g. with the Terraform Provider. We've tried that, and it works without any issues.

The reason why the WebUI breaks is because it tries to fetch other information first to which the user does not have permissions.

This will not prevent someone who wants to abuse this from doing so.

Example code for Terraform (written from memory, not tested, but that's the gist):

data "authentik_user" "me" {
  user = "maliciousperson"
}

resource "authentik_group" "hijack" {
  name = "allyourbasearebelongtome"
  users = [data.authentik_user.me.id]
  is_superuser = true
}

curl -v -X POST "https://sso.yourdomain.com/api/v3/core/groups/" \
 -H "accept: application/json" \
 -H "content-type: application/json" \
 -H "Authorization: Bearer apitokenofuser" \
 -d '{"name":"supermaliciousgroup","is_superuser":true,"attributes":{}}'

Here is a quick curl command to check that. Jan is right. The right "Can add group" gives via API the right to create superuser groups.

After removing the permission again the user gets the error. {"detail":"You do not have permission to perform this action."}

To clarify further: My current assumption (not verified, didn't have enough experience with DRF or the time to research it) is that for whatever reason adding a user to a group is not just interpreted as the action itself (which it is declared as) and only its permissions being checked, but also as a general POST to the Group ViewSet, which translates to the automatic/default permission of add_group internally. That would at least explain why adding the "Can add group" permissions suddenly allows adding users to a group. #8555 IMO should not be addressed, as it is correctly named, but just misbehaving and thus misunderstood.

I forgot to link it, but this is fixed by #9254

Nice feature! Would it be possible to restrict the visibility of a subset of users through permissions? Okta recently introduced the concept of realms, enhancing user management security for large organizations.

You can already restrict the visibility of users by assigning permissions to specific users, however we're also planning to have an additional container object most likely called "Organizations" to further group users and manage them in chunks

Organizations will help a lot when managing governance. Thanks

I'm getting a similar issue, but the problem with mine is that it's just a blank error.

Can't assign a user at all, just throws a blank message, and no other info in the logs.