Issue #746 has been updated by Clément OUDOT. Category set to Core Status changed from New to Assigned Assigned to set to Raphaël Ouazana Target version set to 2.1.2
---------------------------------------- Bug #746: Escaping characters in DN is amiguous http://tools.lsc-project.org/issues/746 Author: Marian Harbach Status: Assigned Priority: High Assigned to: Raphaël Ouazana Category: Core Target version: 2.1.2 Problem in version: As already described in the discussion on the lsc-users list (http://lists.lsc-project.org/pipermail/lsc-users/2014-December/002305.html), the following problem occurs: When syncing one LDAP to another, it happens that one server escapes commas and other values in RDNs as \, and another as \2C. This is valid according to RFC 2253. However, it causes a problem when we use LSC to populate a meta-directory, as syncs fail due to non-matching DNs causing modrdn modifications that ultimately fail. I would like to propose the following for fixing this problem: The issue described in the above mailing list discussion 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: <pre> /** * 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(); } </pre> 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://tools.lsc-project.org/my/account
_______________________________________________________________ Ldap Synchronization Connector (LSC) - http://lsc-project.org lsc-dev mailing list [email protected] http://lists.lsc-project.org/listinfo/lsc-dev
