[keycloak-dev] Suggestion and fix for e-Directory federation provider
Marek Posolda
mposolda at redhat.com
Mon Dec 5 05:28:19 EST 2016
Ok, It will be good if you can create another separate JIRA for the
netIQ eDirectory and send PR and then we can discuss it there too.
Btv. Last Friday it was related community contribution for adding the
ActiveDirectory LDS support. I guess that once you rebase you will
probably need to do just the change like this in LDAPConfig class:
public boolean isObjectGUID() {
- return
getUuidLDAPAttributeName().equalsIgnoreCase(LDAPConstants.OBJECT_GUID);
+ return
getUuidLDAPAttributeName().equalsIgnoreCase(LDAPConstants.OBJECT_GUID)
|| getUuidLDAPAttributeName().equalsIgnoreCase(LDAPConstants.EDIR_GUID);
}
Hopefully it will work with just those minimal changes.
We're not going to support another vendor in the "Vendor" list and we
won't maintain the netIQ eDirectory support by ourselves. But I am
thinking about creating the section in the docs about various LDAP
vendors and what are the related needed configuration changes to have
the vendor working with Keycloak. So if you can create JIRA, send PR
with the change and then create some steps to have netIQ eDirectory
working in the JIRA similar to this [1] it will be appreciated.
Thanks,
Marek
[1]
https://issues.jboss.org/browse/KEYCLOAK-4009?focusedCommentId=13333341&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13333341
On 02/12/16 13:35, Tomas Tikovsky wrote:
> I think that the problem mentioned in Keycloak-3099 is not caused by
> utf8 as its more related
>
> to this function interpretting UUID attribute as string in case of
> anything else than activeDirectory.
>
> eDirectory guid attribute is of byte[] type so reading byte[] as
> string results in that garbish found in LDAP_ID field in DB.
>
>
> /federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/store/ldap/LDAPOperationManager.java
>
> public String decodeEntryUUID(final Object entryUUID) {
> String id;
>
> - if (this.config.isActiveDirectory() && entryUUID instanceof byte[]) {
> + if (entryUUID instanceof byte[]) {
> id = LDAPUtil.decodeObjectGUID((byte[]) entryUUID);
> } else {
> id = entryUUID.toString();
> }
>
> Guid attribute needs to be declared as binary to be correctly returned
> from server.
>
> +
> + if (config.isEDirectory()){
> + env.put("java.naming.ldap.attributes.binary",
> LDAPConstants.EDIR_GUID);
> + }
> +
>
> I posted full diff as attachment in my first post, but didnt realize
> it will be discarded. I can make a pull request but i wanted to
> consult it first here.
>
> Cheers
>
> Tom
>
>
> 2016-12-02 10:07 GMT+01:00 Marek Posolda <mposolda at redhat.com>:
>
>> On 02/12/16 10:04, Marek Posolda wrote:
>>
>>> That's the question... Actually we rejected KEYCLOAK-3099, but it's
>>> possible that problem described below by Tomas is a little bit different
>>> then the issue in the ticket. AFAIK the ticket was specific just to
>>> combination of e-directory LDAP with MSSQL database.
>>>
>> Sorry, small update. We didn't rejected the ticket, but it should be fixed
>> automatically with fixing some other task (work in progress by Hynek). So
>> the MSSQL issue KEYCLOAK-3099 should just work fine in new version -
>> hopefully :)
>>
>> Marek
>>
>>
>>> IMO It's always good to support more different LDAP servers. But the
>>> problem is that:
>>> - Supported vendors should be likely tested, but we don't have capacity
>>> to test and maintain all the LDAP (and DB) vendors in the world
>>> - There is a chance that community PR for supporting new LDAP vendor
>>> breaks other vendors etc. There is just always some additional
>>> complexity with each server supported.
>>> - We don't have possibility to re-test the PR by themselves due to the
>>> LDAP server not available for us.
>>>
>>> We tries to focus especially on the most important servers, so if there
>>> is enough demand from the community and customers for some LDAP vendor,
>>> we will add it. But it seems that ATM you're the only one with the
>>> demand for netIQ e-directory.
>>>
>>> So if there is possibility to workaround and have the netIQ e-directory
>>> working by setup of our existing LDAP StorageProvider configuration
>>> options and mappers (which AFAIK it is), then it is preferred way
>>> instead of the PR for adding support for it OOTB.
>>>
>>> My 2 cents :)
>>>
>>> Marek
>>>
>>> On 02/12/16 09:24, Sebastien Blanc wrote:
>>>
>>>> Hi !
>>>>
>>>> Sure that would be awesome if you can create a pull request and attached
>>>> it
>>>> to the ticket !
>>>>
>>>> Sebi
>>>>
>>>>
>>>>
>>>> On Thu, Nov 24, 2016 at 1:38 PM, Tomas Tikovsky <
>>>> tikovsky.tomas at gmail.com>
>>>> wrote:
>>>>
>>>> Hello everyone,
>>>>> im using e-directory federation ldap provider and came to this bug
>>>>> KEYCLOAK-3099 <https://issues.jboss.org/browse/KEYCLOAK-3099> as i was
>>>>> experiencing the same problem.
>>>>> e-Directory sends guid attribute as byte[] so it needs to be declared as
>>>>> binary the same way as its done for activeDirectory.
>>>>> Sending simple diff to fix this issue if you consider this as helpfull.
>>>>>
>>>>> Novell was acquired by microfocus and their product has been renamed to
>>>>> netIQ eDirectory so i incorporated that change as well.
>>>>>
>>>>> Another thing i noted were 2 incorrect attribute mappings in
>>>>> administration
>>>>> console.
>>>>>
>>>>> "username" -> "uid"
>>>>> correct as long as users are enabled for linux (not default) otherwise
>>>>> cn.
>>>>> So cn should work for more cases than uid.
>>>>>
>>>>> "firstname" -> "cn"
>>>>> wrong, should be "givenname"
>>>>>
>>>>> Cheers
>>>>>
>>>>> Tom
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
More information about the keycloak-dev
mailing list