I'm using Keycloak 19 and I'd like to give my users the authorization to create other user within their own group.
I was able to give access to users to see only the users from their own group by combining the realm_management:query-users role and the activation of fine grained permissions on the concerned group and setting a Group policy on the view-members permission.
I wanted to do the same for groups but it seems that the realm_management:query-groups allows one to see all groups. I was expecting it to work like its users counterpart but it seems like it works more like the realm_management:view-users role.
Moreover when I want to create a new user, it tells my I actually need the query-groups role in addition to the query-users role. So I feel like I'm reaching some kind of dead end here.
How could I configure the roles and permissions to allow users of a specific group to be able manage users within their own group or sub groups ?
The only solution I can think of is to move this in an external app that will handle the additional security of not letting a user see the groups. The app would be the one in charge of doing the change once it verified the user has the rights.
Related
Hello again every one,
I have a question: I successfully implemented django-auth-ldap, the LDAP users can request successfully my DRF API. But nows, for my projetc needs, I have to define permissions depending of the group.
Indeed, I will have like 12 groups in my app. Depending of the group, I will authorize or not the user to request a given route, BUT even if I defined the global var AUTH_LDAP_MIRROR_GROUPS = True, and saw in my database the are linked to a group (see capture):
Users in database
Groups from LDAP inserted in db thx to django-auth_ldap settings
User linked to the groups defined
But now, I have some other problems: I do not know how to implement permissions depending of the group the user belong. In fact, if a user belong to the group ServerAdministrator, I want to allow him to access to every route accessible, but I dont know where to see this in the received request in my view?
As I understood, I should implement custom permissions I should write programmatically in a User object (which should inherit from django AbstractUser)
If yes, How does it work? Should I empty my whole Database and then let django-auth-ldap insert users and it also will create the given permissions defined inside the database?
Maybe it is not clear, do not hesitate to ask questions if I can be more precise.
Kind regards.
Benjamin
I guess this question basically boils down to some misunderstanding that I have about how the SonarQube LDAP plugin works in general. We have integrated the LDAP plugin and our users are authenticating against our corporate LDAP server. When we we want to create a new group and add users to that group for a new project, we have assumed that the users themselves must authenticate into SonarQube first so they get added as a user to SonarQube. After that, then we are able to put them into the appropriate groups that they belong to. This is a pain for our administrators since the people that need to be added are logging in at differing times or forgetting to log in at all. What we would like is something that Nexus provides where we can do a lookup of that user's account id, then add them and place them into the appropriate group(s). In that way, the user is not bothered by having to login first and then the administrator has to give the privileges and then the user logs out and logs back in. Is this a misunderstanding on my part? I ask because when I go to the users page and click on 'Create New User' it not only asks for the user's id but also the user's password which I obviously don't know so this is telling me that this will be a local account.
By default SonarQube's LDAP plugin works like you think it does. You can configure LDAP group mapping so that when the user enrolls, he/she is automatically added to the appropriate group.
In other words, create the group for the project in SonarQube, and then create the same group in LDAP and add users to it. Then when users login for the first time they will be in the appropriate group, and on each subsequent login any group changes will be reflected in SonarQube.
This, in my opinion, is infact better than adding users manually.
Can usergrid support User's in (Group or Role) have access to ALL user's in same (Group or Role)? The way i understand it is because users are in /users/user1, you would have to iterate over all the users in the group and give explicit permissions to a (group/role/user). Can you prefix user's /users/group_user1?
Could use the organization / application but /users and permissions are specific to a single application.
Basically I want to model organization and groups within a single usergrid application, things such as inheriting permissions, etc.
Any ideas? I am going about this in the wrong way? Other frameworks/apis?
Users are linked within a role, so depending on how you configure your roles you can do set a resource within a role like this:
/roles/{role uuid}/users/*
Which would look more like this in a real example:
/roles/7a7fbe9ec74-70f39f37-1825-379f-8385/users/*
You can then set your verbs (GET, POST, DELETE) as you see fit within that role to allow all members of that role to see or change users within that role. I assume you're looking for them to be able to do a GET but if you have additional linked resources below that user, you can add them explicitly as well like this:
/roles/7a7fbe9ec74-70f39f37-1825-379f-8385/users/*/mylinkedrsource/**
Then you can set the verb to GET for roles/{id}/users/* and add POST or PUT for the resources linked below /users/*/{linked resource}
Cross posting from the usergrid google group:
I think you can do what you need with groups.
The idea with groups is that all users in that group get the group's permissions.
So if you do this:
create a group.
give that group permissions for various resources
add users to that group
all users in the group will have the permissions of the group
or
create a group
create various roles, each with various permissions
add the various roles to the group
add users to the group
all users in the group will have the roles (and thus the permissions) of the group
So in this way, you could create various roles for your users. And add users to roles as needed to satisfy the needs of the users. Then, you can create one group for admins. Add all the roles to that admin group, then add your admin users to that admin group. They will have the collective permissions of all the roles.
While reading the web2py manual, I came across this following:
'Once a new user is registered, a new group is created to contain the
user. The role of the new user is conventionally "user_[id]" where
[id] is the id of the newly created id.'
which makes me wonder why Web2py does this. More specifically, why do we need to have so many seemingly redundant groups created where each only contains a single user? For example, what is the purpose of having a group called 'user_2' created just for containing the user with id '2'?
If no particular justification exists, is there any way to disable this default behavior of automatically creating unique groups for individual users, so that more meaningful groups can be created separately? Thanks.
The very next sentence says:
The creation of the group can be disabled with
1. auth.settings.create_user_groups = False
It goes on to say:
Users have membership in groups. Each group is identified by a name/role. Groups have permissions. Users have permissions because of the groups they belong to.
It is a role-based access control (RBAC) system, so groups/roles rather than individual users are given permissions, and users gain access by virtue of the groups to which they belong (including their own user-specific group). This is explained more fully in the chapter intro.
If you don't need to give specific permissions to individual users but only to more broadly defined groups/roles, then feel free to disable the automatic user-specific group creation as per the above.
You can add user2 to group of user1 so user2 obtains permissions of user1. Its usefull in many cases ...
I have to programmatically create a task for a user that was not explicitly added in the site users. He has permissions to contribute to the task list, though, because he belongs to an AD group that has been granted those permissions. I can assign the task to the user through the UI; how do I do it through code though?
The accepted way of assigning tasks to users is to set the AssignedTo field of the task to an SPFieldUserValue pointing to that user. Except it cannot be done in this case, because the users cannot be found in SharePoint, only his group! Assigning the task to the whole group is a bad idea, for obvious reasons. And our system administrators categorically refuse to add the users to Sharepoint one by one, because that would duplicate the data they have in Active Directory, and generally be a pain to manage. What do I do?
When a user authenticates to SharePoint, an entry is created for them in the profile store, even if their permission to the site comes from an AD group.
I did a quick test by adding new user (TGroupsUser) and group (SPtestPermissions) to my AD, so there is no chance the user was ever on my site before. I added the user to the group and gave the group "Member" permissions to my site. I then authenticated to SP with this new user.
To show that the user is part of this SPWeb, I wrote a quick webpart to enumerate the users on the web. Note that there are three groups of users with the SPWeb. All Users, Site Users and Users. See this link for full description of these properties. Basically, users are users on the web. Site Users are users and groups on the site collection. All Users is all users of the site including those granted direct permission or granted through group and then visited the site. Here are the results, minus the system accounts.
All Users
SPSDEV\rross
SPSDEV\sptestpermissions
SPSDEV\TGroupsUser
Site Users
SPSDEV\rross
SPSDEV\sptestpermissions
SPSDEV\TGroupsUser
Users
SPSDEV\rross
Since this account (TgroupsUser) is part of the user collection for the web, you can treat just like a user added directly to the site. To finish the testing, I created a task with the following code for the assignedTo field.
TaskItem[SPBuiltInFieldId.AssignedTo] = web.SiteUsers.GetByEmail("myemail#domain.com");
Here is a screenshot of the new task assigned to TGroupsUser.
FYI - I needed to use AllowUnsafeUpdates on the web object.