I've created some resource groups as pointed out in:
https://console.bluemix.net/docs/services/IoT/reference/rlac.html#configure_RLAC
I assigned defined users to have access to these groups, then
removed that access and decided to have different groups. After
a while of struggle, I decided that groups cannot be deleted.
I've detached them from users, which makes "resourceCount" : 0,
but they have "subjectRefCount" as well.
So DELETE gives: {"message":"CUDRS0067E: The group must not be deleted since it is a resource group of a subject.","exception":{"id":"CUDRS0067E","properties":[]}}
What can I check/do to delete such resource group ?
Related
I have a feature where I am supposed to assign a particular role to a group. Result is such that all the members of the group should be mapped to the role. However the roles dashboard doesn't reflect the group assigned to it. How do I achieve this?
I am attempting to do a put on
https://team.vssps.visualstudio.com/_apis/Graph/Memberships/{aadgp.GroupDescriptor}/vssgp.{GroupDescriptor}
I can come up with the ADO group starting with vssgp. but I have been unable to come up with the AAD descriptor.
Calling AAD graph with
https://graph.microsoft.com/v1.0/groups?$filter=displayName eq 'groupName'
doesnt appear to provide me anything that looks like that and calling
https://team.visualstudio.com/_apis/IdentityPicker/Identities?api-version=6.0-preview
with body
{
"query": "groupName",
"identityTypes": ["group"],
"operationScopes": ["ims", "source"]
}
doesnt give me anything that starts with aadgp.
I am running out of ideas and was hoping one of you may have done this already. I am unable to get all of the groups that have access to the org or team project as it will likely be a new group being added.
tia
You have to make a bunch of calls.
Get Azure graph to get Guid of group
GET https://graph.microsoft.com/v1.0/groups?$filter=displayName eq ‘GroupName’
Get projects to determine id of project I need
GET https://dev.azure.com/{organization}/_apis/projects?api-version=6.0
Post to group entitlements to add the new group in
POST https://vsaex.dev.azure.com/{organization}/_apis/groupentitlements?api-version=6.0-preview.1
Get all groups from the org to get the aadgp value
GET https://vssps.dev.azure.com/{organization}/_apis/graph/groups?api-version=6.1-preview.1
Put on graph membership to add the group
PUT https://vssps.dev.azure.com/{organization}/_apis/graph/memberships/{subjectDescriptor}/{containerDescriptor}?api-version=6.0-preview.1
Delete on group entitlements to eliminate unneeded group entitlement
DELETE https://vsaex.dev.azure.com/{organization}/_apis/groupentitlements/{groupId}?api-version=6.0-preview.1
User-Ankit
He is in two groups named flights and hotels.
In flights,he is a manager
In Hotels,he is a supervisor.
can we assigns these different roles to Ankit in different groups in keycloak?
I think you have to separate the roles to be specific to the group - you'd need a flights-manager role and a separate hotels-manager role and so on.
You can assign roles to a user or group but assigning roles to a group effectively assigns those roles to all the members of the group. I think this is pretty typical.
When you assign roles to the user, you just assign roles to the user and not a user within a group:
There's a thread in the keycloak mailing list where this comes up. Basically groups are just ways of collecting users and not part of the access control structure.
If hotels and flights correspond to apps then you might want to consider whether you could handle them as clients rather than groups but I think you'd still need to have separate sets of roles.
Can you please explain how can i setup the role management and security groups in suiteCRM to achieve this,
Two General Manager, they cannot access the records of other GMs and his team records
Any number of Divisional Managers under GM, they cannot access the records of their own GM, other GMs, and other DM but can access the reports of SR under them.
SR (Sales representative) can access only their own records.
Thanks :)
Try this (not tested)
Create All Security groups for DM. This is the main unit of security.
Assign the GM users to the DM security groups they have access to. No need to create a GM group, just give them access to the groups they need.
Create SR role and set the permissions to own. Assign SR users to this role. This will restrict users in this role to only see their own records.
Create DM role and set the permission to group. Assign DM users to this role. Only one DM role is needed, and ALL of the GM and DM users should belong to it.
Add SR and DM role to all the DM security groups.
The logic is like this
Users who try to access a record will have to go through their Roles First, if its say Own, then that's where the security logic compares the owner of the record.
If the users Roles have a Group setting then User groups will be scanned, and check if the record belongs to someone on those groups. If not access is denied.
So thats it, the Group setting needs to be on each module you want to restrict access to, sadly this is a manual work. Take a look at this image, you can see the different types of access you can grant on a role/action.
How can i restrict the default Read access for the newly created content(page) for the old groups?
I have observed that there is a default read access is created for the newly created content(webpage) for the existing all groups.
This is the default behavior. But one correction, the read access is not created for the newly created content, instead it is inherited from the parent.
We have local policies and effective policies, where the local policies are the one's that are configured for the specific node and the effective policies are those that are inherited from the parent.
Hence, the ACL's of the parent node is effectively applied to the child nodes, unless and until they are denied explicitly for that particular child.
In your case, the parent node would have read access to the old groups, due to which they are applied to the newly created child as well. In case, the old groups are denied read access to the parent, then they will not have read access for the newly created child pages by default.