Currently just the "dn" is retrieved and the membership attribute
(typically "member"). I guess your roles are big because they have
thousands of "member" items on them, is it correct?
Few tips:
- Maybe if you have possibility to configure "User Roles Retrieve
Strategy" to be "MEMBER_OF" ? This will work if your LDAP server
supports it and if it tracks role memberships on "memberOf" attribute of
user. If it works, you can maybe configure "Membership attribute" to
some non-existing value (eg. "foo"), which mean that roles from LDAP
will be retrieved really just with the DN attribute.
- It's also possible to create your own version of mapper and enhance
some functionality. You may need to override
RoleLDAPStorageMapperFactory and RoleLDAPStorageMapper and override some
methods like for example "createRoleQuery()" . See our
server-development guide for tips how to create and deploy your own
providers.
- Create JIRA if none of the above won't work for you. But not sure when
we manage to look into it though...
Marek
On 27/09/17 19:16, Adam Lis wrote:
Hi!
I've role-ldap-mapper defined for my LDAP federation.
I can see on user logon, KeyCloak is issuing LDAP search with filter build
on role-ldap-mapper conditions.
KeyCloak is requesting whole resource from LDAP - in my case groups are
quite big.
If I understand correctly, only 'dn' attribute could be requested, since
query is being done anyway for each user on his logon.
In my case current approach results in waiting for LDAP response for over
20 seconds. In case only "dn" attribute for group would be requested, LDAP
response time is very short.
Is there a way to instruct role-ldap-mapper to retrieve only 'dn'
attribute, and assing a requesting user all groups based only by retrieved
'dn' attributes?
AdamLis;
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user