Assign different default user groups in Keycloak based on different LDAP user federation - ldap

Question is more advanced than usual.
Imagine you have three users groups in Keycloak: Group_Basic, Group_Client_A, Group_Client_B.
You add two different LDAP user federation setting for "Client A" and "Client B".
You make Group_Basic as your default group.
How to automatically assign Group_Client_A to LDAP users from "Client A", and Group_Client_B group to LDAP users from "Client B" ?
Any ideas are welcome! Thanks!

Basically #Vadim pointed to right thing:
Under created LDAP -> Mappers -> Create ->
Mapper type: hadrcoded-ldap-group-mapper
Group: /Group_Client_A
Did synced user, got default Group_Basic group + hardcoded Group_Client_A.
I assume pointing to different group under different LDAP synchronisation will got another group assigned.
Thanks!

Related

User Filter for nested OU inside gitlab using RFC 4515

I am setting up gitlab to have LDAP access.
I would like to give access to 2 seperate OU's OU=Users,OU=Dept1,OU=land,DC=my,DC=com and OU=Users,OU=Dept2,OU=land,DC=my,DC=com (basically the users of 2 departments.
I believe that I would have to set the base to OU=land,DC=my,DC=com and then use a user_filer (Format: RFC 4515)
Probably something of the sort
(|(ou=Dept1)(ou=Dept2))
How do I extend this to specify only for the USERS within those ou's? Thanks
Note:
When I use the Filter: (objectClass=user)I am given access
however if i change it to any of the following I am refused access
(&(objectClass=user)(ou=Users))
(&(objectClass=user)(ou=Dept1))
(&(objectClass=user)(ou=Users,ou=Dept1,ou=land))
(&(objectClass=user)(ou=Users,ou=Dept1,ou=land,dc=my,dc=com))
You should add an objectClass constraint to the filter to limit it only to users , say (&(objectClass=Person))

memberOf attribute does not exist when user is in a group (dirsrv, CentOS6.2)

I have a problem adding user in a group using dirsrv, CentOS6.2.
Default schema, have user jmarsden in "People" and created a group into "Groups".
Tried to use any types of the group: groupOfNames, groupOfUniqueNames, posixgroup. Member (uniqueMember or memberUid) is successfully added as attribute.
member=uid=jmarsden,ou=People,dc=mymy,dc=localdomain
But when I fetch operational attributes using Apache Directory Studio there is not memberOf attribute for user jmarsden. Search with filter "memberOf=cn=M"* does not work either.
What am I doing wrong?
memberOf is an attribute that is most often associated with Active Directory.
Many LDAP implementation do not use an attribute on the user to represent which group the users are a member of.
Which LDAP implementation are your using?

How to model restrictions on data visible on resources?

How to model restrictions on data visible on resources? Different people are accessing the same resources but with different roles so they are not allowed to see all the information.
The case I am working on:
Solution without access restriction on information:
User:
name
phoneNumber
If anyone could access it this would be easy to model as:
GET /User -> [{name:"John", phoneNumber: "322-333"}]
GET /User/{id} -> {name:"John", phoneNumber: "322-333"}
However, say I have two roles, admin and user. The phoneNumber must only be visible to users who are also admins. Authorization token is transmitted in a cookie, header or similar. The server will know which roles a requester has. How would one design an API to handle this? I have a couple of ideas:
1) The naive solution would be to just filter it and leave the fields unset if you arent allowed to access it ie.
If user: GET /User -> [{name:"John"}]
If admin: GET /User -> [{name:"John", phoneNumber: "322-333"}]
2) Embed the role in the url:
If user is wanted as a User: GET /User/User -> [{name:"John"}]
If user is wanted as an Admin: GET /Admin/User -> [{name:"John", phoneNumber: "322-333"}]
3) Define a new resource for each possible subset of fields:
If user is wanted as a User: GET /PublicUserInfo -> [{name:"John"}]
If user is wanted as an Admin: GET /FullUserInfo -> [{name:"John", phoneNumber: "322-333"}]
Would a different approach be better ?
Does anyone have experience with a solution that worked out in practice?
Use option 1 based on the authenticated user. If you opt for 2 or 3 clients implementing your API have to worry about twice as any API endpoints and when they should be used.

Where to implement the security filter for dynamic groups

First I'll describe rougthly the context. I want to have a symfony application where I can create various areas. In each of the areas, you can have different kinds of users (or roles). Each user can have multiple roles in different areas.
To illustrate the question, we'll define:
2 areas: "Area 1" and "Area 2".
2 users: "User 1" and "User 2".
2 roles: "seller" and "buyer".
"User 1" is a seller and a buyer in "Area 1"
"User 2" is a seller and a buyer in "Area 1" and a buyer only in "Area 2"
My question is: which is the best way to check in restricted pages if a user belongs to a given area and if he has the required role in that area.
After thinking a bit about it, I have done the following:
When an area is created, I also create one sfGuardGroup per role and one global sfGuardGroup for the area, each suffixed with the area id. So in our example, we'll have the roles:
area-1, sellers-1, buyers-1 for area 1
area-2, sellers-2, buyers-2 for area 2
The users are added to the relevant groups. So in our example:
User 1 will belong to the groups area-1, sellers-1 and buyers-1
User 2 will belong to the groups area-1, sellers-1, buyers-1, area-2 and buyers-2
From the URL, I know in which area we are, for instance:
http://example.com/area-1/sellers-restricted-page (accessible to users in the group area-1 and sellers-1)
http://example.com/area-2/buyers-restricted-page (accessible to users in the group area-2 and buyers-2)
http://example.com/area-2/ (accessible to users in the group area-2)
At that point, I am kind of stuck as I cannot make out the best place to implement the permission check: modify the guard filter? Change the actions?
Your required implementation is not supported by sfGuard so I would recommend creating a new, additional, security filter.
You can create a brand new filter that extends sfFilter, then add it into filter.yml after the existing security filter. This means that all existing security functionality provided by sfGuard continues.
You can then determine what area is being requested by looking at the current module name and action name (how you access these is different dependent on which version of symfony you are using, look in sfBasicSecurityFilter for a clue) then compare that with the roles that the current user has using sfGuardSecurityUser.

What is used to login in LDAP mail server?

If I added data on LDAP in this way:
$ldapserver = "mail";
$ds = ldap_connect($ldapserver);
$r = ldap_bind($ds, $ldaprootun, $ldaprootpw);
add = ldap_add($ds, "cn=$full_name,ou=$domain,o=mygroup.com", $infonew);
Then does that mean that when I log in to my account I will use:
`cn="mynameHere",ou="domainIused",o=mygroup.com`
as my username? Or just my uid?
My account cannot login but I'm sure that it exists in LDAP.
Answers are very much appreciated. =)
Typically in LDAP applications you only ned to login with your UID, not your full X.500 name.
Try calling ldap_bind() with your creds and see what it returns?
Usually, the user provides a simple name. Then the app searches the LDAP source for some attribute that has that value. Then you bind or password compare in your code, as that full DN.
You can use uid which is Unique ID, which is required to be unique. I.e. If you find more than one instance of it, that is an error.
You can try CN, but that can often be multi valued depending on your LDAP implementations schema.
If you know you are going against eDirectory, then uid is fine, or CN just do something if it is multi valued.
If you know you are going against Active Directory, you can assume sAMAccountName is unique since the system enforces uniqueness. userPrinicpalName ought to be unique, but nothing actually enforces it.
You can always use mail, which is the email address pretty uniformly.