Is it possible to grant a user the permission to view only some (not all) users of the realm?
example:
we have user_1 and group_1, group_2. user_1 can see members of group_1 but can't see members of group_2
Yes, you would need to enable fine grained permissions feature (admin_fine_grained_authz). See the docs on how to do this.
And then you will need to configure your policies and permissions according to your needs. In your case, you need to allow the right/scope view-members for user_1 on resource group_1.
Related
https://developers.google.com/admin-sdk/directory/v1/quickstart/python
Is the "Google account for that domain with administrator privileges" mentioned in this prerequisite a super administrator?
https://support.google.com/a/answer/2405986
Or are other admins included?
Thanks for your help.
Others included, depends on the level of access you want to have. For example, you can have a Custom Admin role with Users and Groups Read permission, that will allow you to read all information about users and groups (but you will not be able to modify/add users).
Is there a way to include the list of groups a user is a member of inside a Keycloak access token, along with the roles they are in? I've created several groups and mapped them to roles. However, I may have more than 1 group that maps to a particular role. I'd like to be able to make fine-grained authorization decisions so I know that User A is in Role A but also Group B. Is that possible?
Found the answer to this right here. All I had to do was add an additional mapper to my Client. Worked like a charm.
I have checked the docs from Microsoft for AzureDevops and I understand how to manage permissions for a branch.
What I would like to know is if a user is automatically added with Edit Policies permission to Allow as he creates the branch (assuming a normal user not admin, and he's not inheriting this permission) ?
If the answer to the above question is yes, then is there any case when a second user could be added to the list of branch permissions automatically ? without an administrator adding it explicitly ? I couldn't find this in the docs anywhere.
*picture from msdn
Yes, for each branch's permission setting, you could directly manage that user's or create a group then add that consultancy in the group, manage the group's permission.
In other words, without adding it explicitly, the user B could also be added to a group.
You just need to make sure that you are not part of any groups that have the complete privilege Denied.
In Azure DevOps, Deny trumps Allow.
Unless you're a member of the Project Collection Administrators group on your organization, membership in a group that explicitly Denies any permission will deny your permission, even if you are in another group that explicitly Allows you the permission and even if you as an individual user are granted Allow on that permission.
We usually add developer to Contributors.
For the Inheritance part, you could turn on your inheritance and clear explicit with single click for each branch which have explicit permissions.
After this, Contributors Group in other branches will totally inherit the permissions set by root path of your repo/workspace. For example, if root path are Allow, your branches should be Allow(inherited), if it's Deny, your branches should be Deny(inherited).
If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.
Users inherit permissions from the groups to which they belong. When
a permission is allowed for a user directly or through membership in
a group that has that permission, and it is denied, either directly
or through group membership, the permission is denied.
Members of Project Collection Administrators or **Team Foundation
Administrators** retain any allowed permissions, even if they belong to
other groups that deny those permissions.
Object-level permissions that are assigned for nodes of a hierarchy -
areas, iterations, version control folders, work item query folders -
are inherited down the hierarchy. That is, a user's permissions that
are set at area-1 are inherited by area-1/sub-area-1, if the same
permission is not explicitly allowed or denied for area-1/sub-area-1.
If a permission is set explicitly for an object, like
area-1/sub-area-1, then the parent node is not inherited, regardless
of whether it is denied or allowed. If it's not set, then the
permissions for that node are inherited from the closest ancestor
that has the permission explicitly set.
More details please take a look at our official tutorial here: Inheritance and security groups
Using the KeyCloak admin console, I am attempting to enact the following use-case.
We have Group X and Group Y.
The role 'Group X Admin' can do the following:
Can create users without a group.
Can assign users without a group to group X.
Can edit and manage users in group X.
Cannot see/edit/manage users in group Y.
It seems that in order to fulfill case 1, I must make 'Group X Admin' a composite role linked to the 'manage-users' role from the realm-management client.
However, upon doing this, the 'Group X Admin' now has permission to view/manage/edit group Y users.
It seems I cannot restrict access to group Y as fine-grained permissions seem to completely overridden by the manage-users role.
Is there a way to grant permissions to Add Users while restricting access to certain groups?
You should have a look at Fine Grain Admin Permissions. It's still in preview (so no support from RedHat) but it's the kind of functionality you are looking for.
I certainly have tested a setup that would fulfill items 3 and 4. The description in chapter 11.3.2 Restrict User Role Mapping should get you sufficiently close to item 2. Item 1 probably needs somewhat more investigation. I can't tell you if it's doable.
Even though Fine Grain Admin Permission is quite powerful, we came to the conclusion that it's not sufficient for our requirements. So we discarded it and went with a different solution (a privileged service in front of Keycloak for delegated user administration).
Update
Some instructions how to set it up:
Enable preview profile (in Keycloak startup script)
Enable permissions on client Realm-management (Clients / Realm-Management / Permissions / Permissions Enabled)
Create a group x-users
Create a group x-admins
Enable permissions on group x-users (Groups / X / Permissions / Permissions Enabled)
Click view-members (on the same page) and add a group policy:
Scopes: view-members
Apply Policy: Create Policy... / Group
Enter name, e.g. x-admin-policy
Enter description
Groups: select group x-admins
Save
Repeat for manage-members
seems like there is no way in current admin console :(.
I also went through documentation (and even through source code ;) ) and did not find a way.
Maybe better create a request in keycloak jira project.
by the way i also was looking to solve exact the same problem.
Actually there is a jira ticket about documenting the fine grained permissions to admin console.
https://issues.jboss.org/browse/KEYCLOAK-3444
maybe you can post your comment there or open new story
I have a small question related to granting access to multiple sites in Sitecore 7.5.
Let's say I have a website named as website_1 and another website named as website_2 in my Sitecore environment. Now I have created two roles. One role named as r_website_1 gives access to website_1 and another role r_website_2 gives access to website_2.
In r_website_1, only access to website_1 is granted and access to website_2 is denied. The same goes for r_website_2 but for
website_2.
Now I want to give read and write access to user_1 for both websites. What I did was went to User Manager>user_1>Edit>Member Of and then assigned both roles.
What I noticed that the user_1 only gets access to one website. it seems that both roles are countering each another. For example, the denied permission for website_2 in r_website_1 is conflicting with allowed permission for website_2 in r_website_2.
May I know what's the fix for this problem?
Thanks in advance,
Vaibhav
Deny permission always has priority. You cannot remove by simply adding another role with allow access rights.
Instead of using deny you should break the inheritance of chosen access right for the role1 for site2 and similarly for the role2 for site1.
Here is a quote from Sitecore Administrator Security Cookbook:
We recommend that you use inheritance whenever possible to limit the access that roles have to the items in Sitecore. Using inheritance instead of directly denying access rights to items makes it easier to manage the security system.
And you can read about breaking inheritance of access rights in Assign access rights to a security account document.