10:37 p.m.
Hi,
In replicated LDAP setups, it's a common situation where the slave is
read-only, and if a write operation is attempted, it returns a so-
called referral (see more here). Simply put, a referral is an
instruction to proceed with the same LDAP operation but using different
URL, contained within response. In a replicated setup, this URL would
point to master instance, which is read-write.
Currently, KeyCloak cannot use such a slave replica as a federation
provider in a WRITABLE edit mode. LDAP entries are imported
successfully; but further attempts to modify them in KeyCloak admin
console give success message, while the actual values are not modified.
If Sync Registrations is on, attempt to create a user results in the
following exception:
javax.naming.PartialResultException: [LDAP: error code 10 - Referral];
remaining name 'uid=foo,ou=People,dc=foobar,dc=com'
at
com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971)
at
com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
at
com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:812)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(Compone
ntDirContext.java:341)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(Pa
rtialCompositeDirContext.java:268)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(Pa
rtialCompositeDirContext.java:256)
at
javax.naming.directory.InitialDirContext.createSubcontext(InitialDirCon
text.java:197)
at
javax.naming.directory.InitialDirContext.createSubcontext(InitialDirCon
text.java:197)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.exec
ute(LDAPOperationManager.java:434)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.exec
ute(LDAPOperationManager.java:431)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execut
e(LDAPOperationManager.java:536)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.create
SubContext(LDAPOperationManager.java:431)
LDAP referrals are fully supported by JNDI and LDAP stack; the only
thing we need is to set a Context.REFERRAL ("java.naming.referral")
environment property to "follow" before creating an InitialLdapContext.
I've noticed that in org.keycloak.federation.ldap.LDAPConfig, there is
an initial support for additional connection properties (currently
hardcoded to return null). Are there any plans to implement this?
Cheers,
Mitya
2:54 p.m.
LDAP referrals were not yet tested and supported, could you please
create JIRA for this?
Thanks,
Marek
On 18/05/16 05:37, Mitya wrote:
Hi,
In replicated LDAP setups, it's a common situation where the slave is
read-only, and if a write operation is attempted, it returns a
so-called referral (see more here
<http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html>). Simply
put, a referral is an instruction to proceed with the same LDAP
operation but using different URL, contained within response. In a
replicated setup, this URL would point to master instance, which is
read-write.
Currently, KeyCloak cannot use such a slave replica as a federation
provider in a WRITABLE edit mode. LDAP entries are imported
successfully; but further attempts to modify them in KeyCloak admin
console give success message, while the actual values are not
modified. If Sync Registrations is on, attempt to create a user
results in the following exception:
javax.naming.PartialResultException: [LDAP: error code 10 - Referral]; remaining name
'uid=foo,ou=People,dc=foobar,dc=com'
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
at com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:812)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:341)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:268)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:256)
at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:197)
at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:197)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.execute(LDAPOperationManager.java:434)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.execute(LDAPOperationManager.java:431)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:536)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createSubContext(LDAPOperationManager.java:431)
LDAP referrals are fully supported by JNDI and LDAP stack; the only
thing we need is to set a Context.REFERRAL ("java.naming.referral")
environment property to "follow" before creating an
InitialLdapContext. I've noticed that in
org.keycloak.federation.ldap.LDAPConfig, there is an initial support
for additional connection properties (currently hardcoded to return
null). Are there any plans to implement this?
Cheers,
Mitya
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:21 a.m.
Marek,
Sorry for delay. Here we go: https://issues.jboss.org/browse/KEYCLOAK-3
083
LDAP referrals were not yet tested and supported, could you please
create JIRA for this?
Thanks,
Marek
On 18/05/16 05:37, Mitya wrote:
> Hi,
>
>
> In replicated LDAP setups, it's a common situation where the slave
> is read-only, and if a write operation is attempted, it returns a
> so-called referral (see more here). Simply put, a referral is an
> instruction to proceed with the same LDAP operation but using
> different URL, contained within response. In a replicated setup,
> this URL would point to master instance, which is read-write.
>
>
> Currently, KeyCloak cannot use such a slave replica as a federation
> provider in a WRITABLE edit mode. LDAP entries are imported
> successfully; but further attempts to modify them in KeyCloak admin
> console give success message, while the actual values are not
> modified. If Sync Registrations is on, attempt to create a user
> results in the following exception:
>
>
> javax.naming.PartialResultException: [LDAP: error code 10 -
> Referral]; remaining name 'uid=foo,ou=People,dc=foobar,dc=com'
> at
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971)
> at
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> at
> com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:812)
> at
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(Com
> ponentDirContext.java:341)
> at
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontex
> t(PartialCompositeDirContext.java:268)
> at
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontex
> t(PartialCompositeDirContext.java:256)
> at
> javax.naming.directory.InitialDirContext.createSubcontext(InitialDi
> rContext.java:197)
> at
> javax.naming.directory.InitialDirContext.createSubcontext(InitialDi
> rContext.java:197)
> at
> org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.
> execute(LDAPOperationManager.java:434)
> at
> org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.
> execute(LDAPOperationManager.java:431)
> at
> org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.ex
> ecute(LDAPOperationManager.java:536)
> at
> org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.cr
> eateSubContext(LDAPOperationManager.java:431)
> LDAP referrals are fully supported by JNDI and LDAP stack; the only
> thing we need is to set a Context.REFERRAL ("java.naming.referral")
> environment property to "follow" before creating an
> InitialLdapContext. I've noticed that in
> org.keycloak.federation.ldap.LDAPConfig, there is an initial
> support for additional connection properties (currently hardcoded
> to return null). Are there any plans to implement this?
>
>
> Cheers,
> Mitya
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
3127
days inactive
3144
days old
2 comments
2 participants
participants (2)
-
Marek Posolda -
Mitya