[keycloak-user] [keycloak-dev] How to add custom LDAP attribute mapper

Wed Sep 4 09:11:25 EDT 2019

Hey Shiva,

On Wed, Sep 4, 2019 at 1:07 PM Shiva Prasad Thagadur Prakash <
shivaprasadtp8 at gmail.com> wrote:

> Hi Jan,
> Thank you very much for the reply. Sorry, I think I didn't clearly state
> my doubt.
>
> I wanted to write my own mapper "custom-ldap-attribute-mapper" like
> "user-ldap-attribute-mapper".  How can I do this?
>
> The problem I am facing is:
> I am trying to find a way to populate the uidNumber when a user is created
> in LDAP via Keycloak. I don’t want to use hardcoded-attribute-mapper as it
> would put the same value to all the users. Is there is a way to populate
> these values when a user is created at the Keycloak side?
>

Is it acceptable all the users labelled with the "uidNumber" attribute to
share some field, common to all such users? Or is it expected,
the "uidNumber" labelled users to be randomly (arbitrarily) distributed
across the set of all possible users (read like might the 'uidNumber'
attribute be required to be able to cross different LDAP ou categories)?

If the former is allowed, you could have two disjunctive set of groups
(e.g. the first one having "ou=Users", the second one
"ou=uidNumberedUsers"). You would create two instances of the LDAP user
federation provider ("users-ldap" and "uid-numbered-users-ldap").
For both of these providers you would create corresponding
'user-ldap-attribute-mapper's.

To achieve these sets of users to be disjunctive, you would set "ou=Users"
LDAP filter on the first set, and "ou=uidNumberedUsers" on the second one
[1]. For the "ou=uidNumberedUsers" user-ldap-attribute-mapper, you would
set it in the way, so the "uidNumber" attribute is always mapped to
something.

Finally, you would mark the "ou=Users" federation provider as 'READONLY',
so users from this group can only be imported from LDAP to Keycloak, but
not vice versa. And for the "ou=uidNumberedUsers" provider, you would
configure the federation provider as a 'WRITABLE' one, so users can be
imported both ways (login of a new such user to Keycloak would be
propagated to LDAP directory store too).

> For “posixAccount” in LDAP these are MUST be present attributes and LDAP
> throws error if these values are not present when a user is created.
> Eagerly waiting for your reply.
>

Unless I am mistaken, this could work (though might need to be tried &
possibly adjusted as necessary). The only disadvantage seems to be you
would have two LDAP organizational units ("ou"s) of users at the LDAP side
of things.

HTH

> Thanks,
> Shiva
>

Thank you && Regards, Jan
--
Jan iankko Lieskovsky / Keycloak / RH-SSO Team

[1] This would mean, the first LDAP federation provider would process only
LDAP entries, having "ou=Users" in the DN, while the other would process
just "ou=uidNumberedUsers" subgroup of users from all the LDAP users
present in the directory server.

>
> On Wed, Sep 4, 2019 at 1:06 PM Jan Lieskovsky <jlieskov at redhat.com> wrote:
>
>> Hey Shiva,
>>
>> On Wed, Sep 4, 2019 at 10:01 AM Shiva Prasad Thagadur Prakash <
>> shivaprasadtp8 at gmail.com> wrote:
>>
>>> Hi Guys,
>>> Any suggestions on this? Eagerly waiting for your reply.
>>>
>>> Thanks,
>>> Shiva
>>>
>>> On Mon, Sep 2, 2019 at 12:15 PM Shiva Prasad Thagadur Prakash <
>>> shivaprasadtp8 at gmail.com> wrote:
>>>
>>> > Hi Guys,
>>> > I want to add a custom LDAP user attribute mapper to Keycloak. How can
>>> I
>>> > do this?
>>>
>>
>> You would do as usual:
>>
>>    - Add new LDAP federation provider first (User Federation -> Add
>>    Provider, choose 'ldap'  & setup / provide the necessary bits (Vendor,
>>    Connection URL, ..., click 'Save' once done), then click 'Mappers' tab,
>>    click 'Create', add some name to it & choose 'user-attribute-ldap-mapper',
>>    specify the name of the attribute, you want to be stored in Keycloak DB in
>>    the 'User Model Attribute' field, and specify the name of the attribute, as
>>    already exists in LDAP in the 'LDAP Attribute' field. Customize / set up
>>    the other options ('Read Only', 'Always Read Value from LDAP', ... as
>>    needed), then click 'Save'.
>>
>> Yet, it should be verified, if there already isn't an existing
>> 'user-ldap-attribute-mapper', mapping the same attribute, but having
>> different settings, so those two wouldn't conflict.
>>
>>
>> >
>>> > Actually I wanted to have an LDAP attribute mapper which would have
>>> some
>>> > initial value hardcoded for an LDAP attribute but the attribute value
>>> can
>>> > be edited/changed later.
>>>
>>
>> Initial name of the user attribute to map from LDAP to Keycloak would be
>> initially hardcoded, but it might change later?
>>
>> If that's the case, once the name of the LDAP attribute changed, you
>> would either:
>>
>>    - Go to the admin console and perform User Federation ->
>>    previously_created_provider_name -> Mappers tab -> choose the custom user
>>    attribute mapper created before, change the respective field (LDAP
>>    attribute or even User Model attribute if needed), click 'Save' again)
>>    - Or this can be (AFAICT) performed also in a programmed way using
>>    the REST API (get the realm in question, get it's mappers, then update the
>>    mapper with the new 'User Model attribute' value). See the available REST
>>    API methods, if interested in pursuing this way.
>>
>> Though if you are searching for some "inotify" based functionality (IOW
>> the mapper itself to realize the name of the attribute changed in LDAP, and
>> to have some automated way how this would update itself based on the
>> changed attribute name -- from the original name to the updated one), I am
>> not aware of a way, on how this could be achieved. But maybe others can
>> suggest an approach..
>>
>> HTH
>>
>>
>>> >
>>> > Thanks,
>>> > Shiva
>>> >
>>>
>>
>> Regards, Jan
>> --
>> Jan iankko Lieskovsky
>>
>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>