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.
Related
So I am using Node/MongoDB (mongoose) to implement this feature.
What I need is the right solution for the following problem:
We have many Company(ies)
Each Company can create it's own Roles
Role is a set of predefined Permissions (like task.create, task.read, task.update, task.delete)
They can choose which Permissions are included in which Role
Company can create it's own Users, and assign them a Role
Lets say that company created 3 roles (the order matters):
Owner (always predefined, has all Permissions)
Team Leader
SuperAgent
Agent
Beside that, I also have Users in a tree structure, with parent reference which holds the _id of the User above him.
The rules are:
User can have none or many children
User cannot be above someone that have higher role than him
User cannot be below someone that have lower role than him
The Tree can get as deep as they want...
So the right representation of this would be:
But because Company Owner can at any time make new Role, or switch the order of roles, the problem occurs...
Let's say he switched the places of 2 roles, and they are now:
Agent
SuperAgent
How would you update all Users?
Also, what if he creates a new Role, puts it in 3rd place, and now needs to update everyone 1 role below, so he can attach that new role to a user...
What approach would you take to solve this kind of issue?
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 want to set up a Keycloak instance which provides AAI to several applications. The users and groups will come from multiple sources (e.g. LDAP) so I want to use mappers so that the attributes on the Keycloak side are the same for users with the same properties. For user attributes, one can use a user-attribute-ldap-mapper, and that works like a charm.
My users now are part of groups, and the groups have their own attributes. So for instance I would have in one of my LDAPs:
Group1
-- MySpecificAttribute1: value
-- MySpecificAttribute2: other value
User1:
-- member of Group1
-- MyUserAttriute1: vall
What I would like to do is to map the attributes MySpecificAttribute1 to Attribute1 in the Group1 group that has been imported into Keycloak.
Is there a (hopefully easy) way to achieve this?
EDIT
I thought it could make sense to specify a bit more what I try to achieve. The thing is we are developing an application that needs to have access to the group information, so answering questions like "give me the list of users who are linked in the contactpoint attribute of all groups". Our current approach is to use the REST API to obtain this data directly from keycloak, and it would not be optimal if we had to implement a translation table for the different sources of information. There may be a way to obtain this information in a different way where we would put the translation somewhere in keycloak, that could be worth investigating too.
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.
From the PostgreSQL docs:
The concept of roles subsumes the concepts of "users" and "groups". In
PostgreSQL versions before 8.1, users and groups were distinct kinds
of entities, but now there are only roles. Any role can act as a user,
a group, or both.
Why did they make this change in 8.1?
Perhaps it's easier from the C coders point of view, with a single Role class (struct)?
More details:
CREATE USER is equivalent to CREATE ROLE except that CREATE USER gives the LOGIN permission to the user/role.
(I'm about to design a permission system for my webapp, hence I'm interested in this.)
The merge has many advantages and no disadvantages. For instance, you can now seamlessly convert a "user" to a "group" and vice versa by adding / removing the LOGIN privilege.
ALTER ROLE myrole LOGIN;
ALTER ROLE myrole NOLOGIN;
Or you can GRANT membership in any other login ("user") or non-login role ("group") to a role:
GRANT joe TO sue;
You can still:
CREATE USER james;
That's just a role with login privilege now. Or:
CREATE GROUP workers;
That's effectively the same as CREATE ROLE now.
The manual has it all.
I found this thread in the PostgreSQL-Hackers list, from June 6, 2003, that in the end suggests that users and groups and roles be consolidated. (Thanks Craig Ringer for suggesting that I check the pgsql-hackers list archives.)
Here are some benefits mentioned (those that I found).
allow groups to have groups as members
the ACL code would be simplified
the GRANT/REVOKE syntax and the display format for ACL lists could be
simplified, since there'd be no need for a syntactic marker as to
whether a given name is a user or a group.
In some circumstances I could see it making sense to allow logging in
directly as a group/role/whatchacallit
This would also solve the problem that information_schema views will
show only owned objects
[makes it easier to] representing privileges granted to groups [since
you'd simply reuse the role related code?]
From the manual:
The SQL standard defines the concepts of users and roles, but it
regards them as distinct concepts and leaves all commands defining
users to be specified by each database implementation. In PostgreSQL
we have chosen to unify users and roles into a single kind of entity.
Roles therefore have many more optional attributes than they do in the
standard.
Having a distinction between users and groups doesn't gain you anything.
AFAIK the motivation for changing it was to simplify uses like:
One user masquerading as another, eg a superuser simulating a reduced permissions user. With unified roles this becomes just another change of current role, no different to changing primary group.
Groups that are members of other groups to implement granular access permissions.
If you want the details, though, you're best off checking out the archives of the pgsql-hackers list for the period, and the git history (converted from CVS).