2014-12-16 10:05 GMT+01:00 Marian Harbach <[email protected]>: > > > Hi Clément, > > sadly we do have the problem that we do not know how many ou= elements are > present in the DN as the source LDAP is not under our control. Also, the > structure we currently see is very deep already and would thus cause us to > have too many tasks. > > I would like to propose fixing this problem in a different way. I think > the issue occurs because RFC 2253, which is about the DN structure, is not > specific enough. It allows both, just using a backslash to escape certain > values but also allows these characters to be put into a hex-representation > (which is what is happening for us). On top of that it, it even allows > implementations to quote additional characters. So to alleviate this > problem and any further problems with escaping in the DN, I would modify > LSC to maintain a canonic, more strict internal representation of DNs. This > is fairly easy to achieve as the DNs of all incoming search results need > only be passed through one method and can then pass through LSC without > further modifications (as they will still be RFC 2253 compliant, just more > strictly escaped). In particular, LSC would no longer have a comma in a RDN > escaped as both \, or \2C but unify this to always be \,. > > I wrote and tested a bit of code that relies on Java’s implementation of > RFC 2253, which should be sufficiently strict. This method could be, for > example, put into org.lsc.utils.StringUtils: > > /** > * This method will make sure that all DNs from sources and > destinations are escaped similarly. RFC 2253 is too vague > * and lets implementations escape either with a simple \ or by also > converting the character in question into a hex representation. > * This can cause syncs between differently escaping LDAPs to fail. > This method should be applied to all results that have been > * fetched from the server. > * > * The method will first unescape all RDNs in the DN and the re-escape > everything using the constructor of javax.naming.ldap.Rdn. > * > * @param dn The DN to canonify. > * @return The DN in a commonly escaped format. > * @throws InvalidNameException thrown if the passed DN is not a > valid name (i.e. the constructor of javax.naming.ldap.LdapName throws this > exception). > */ > public static String canonifyDN(String dn) throws > InvalidNameException{ > LdapName name = new LdapName(dn); > List<Rdn> canonicRdns = new ArrayList<Rdn>(); > for(Rdn rdn : name.getRdns()){ > if(rdn.getValue() instanceof String) > canonicRdns.add(new Rdn(rdn.getType(), > Rdn.unescapeValue((String)rdn.getValue()))); > else > //in case this part is not a string we just keep it. > canonicRdns.add(rdn); > } > return new LdapName(canonicRdns).toString(); > } > > You would then add calls to this method in JndiServices.doGetAttrsList(), > JndiServices.doGetDnList(), as well as LscBean.getInstance() whenever a DN > is retrieved from a javax.naming object into a LSC-specific data structure. > > How does that sound? Any feedback is welcome. We need a solution to this > problem as soon as possible. > >
Could you please open an issue on http://tools.lsc-project.org/projects/show/lsc ? We will look at it this week. Clément.
_______________________________________________________________ Ldap Synchronization Connector (LSC) - http://lsc-project.org lsc-users mailing list [email protected] http://lists.lsc-project.org/listinfo/lsc-users
