Tag: LDAP

LDAP Attributes in JNDI

Almost everything that you do with LDAP concerns the retrieval and manipulation of attributes. Due to the extensible nature of attributes finding out their types and content can be quite involved. Here is a simple sample code snip to the very basic of attribute look up including type information.

    /**
     * printAttributes
     *
     * Prints the attributes listed in ats to the stream defined by s.  If ats
     * is null all attributes will be listed.  If ats is empty none will be
     * listed.
     *
     * example:
     *      String obj = "uid=admin,ou=system";
     *      String[] ats = {"uid","displayName"};
     *      printAttributes(ctx,obj,ats,System.out);
     *
     *
     * @param ctx initial directory context
     * @param obj object in directory to retrieve attributes for
     * @param ats attribute list of attribute names to retrieve, null for all
     * @param s stream to write the attributes to
     * @throws javax.naming.NamingException
     */
    public static void printAttributes(InitialDirContext ctx, String obj,
            String[] ats, PrintStream s) throws NamingException {

        Attributes a = ctx.getAttributes(obj, ats);
        NamingEnumeration e = a.getAll();

        while (e.hasMore()) {

            Attribute t = (Attribute)e.next();

            s.println("<attribute name=\"" + t.getID() + "\">");
            s.println("      <syntax>" + t.getAttributeSyntaxDefinition().getAttributes("") + "</syntax>");
            s.println("      <schema>" + t.getAttributeDefinition().getAttributes("") + "</schema>");
            NamingEnumeration f = t.getAll();

            while (f.hasMore()){

                Object z = f.next();
                s.println("      <value>" + z + "</value>");
            }

            s.println("</attribute>");
        }

    }

This produces output that looks something like this:


    <attribute name="cn">
      <syntax>{x-schema=X-SCHEMA: system, x-is-human-readable=X-IS-HUMAN-READABLE: true, numericoid=NUMERICOID: 1.3.6.1.4.1.1466.115.121.1.15}</syntax>
      <schema>{name=NAME: cn, commonName, substr=SUBSTR: caseIgnoreSubstringsMatch, x-schema=X-SCHEMA: system, syntax=SYNTAX: 1.3.6.1.4.1.1466.115.121.1.15, numericoid=NUMERICOID: 2.5.4.3, sup=SUP: name, desc=DESC: RFC2256: common name(s) for which the entity is known by, usage=USAGE: userApplications, equality=EQUALITY: caseIgnoreMatch}</schema>
      <value>developer</value>
    </attribute>

LDAP vs RDBMS is the war over?

Perhaps the question is better put, ‘Did the war even happen?’ What war you might well ask; well when different ways of looking at potentially the same data are viewed then there are bound to be zealots on either side fanning the flames of FUD on the opposition and extolling the vitues of their chosen creed. However although both RDBMS and LDAP are commonly used to host the same data for applications there appears to be little controversy.

Mostly, I think, there is no conflict because in general LDAP is not even an option for the vast masses of application developers out there. Especially as the bulk of application development appears to be done facing the Internet. Normally hosting environments provide a choice of RDBMS or RDBMS. LDAP is just too difficult a concept, and that’s probably the first reason that it has fallen out of contention for storing the masses of organisational data out there. Yet it is probably the best candidate that I know of for holding operational control of that data.

To illustrate this conceptual difficulty lets consider the contention between software developer and database architecht perspectives. Typically the developer does not really understand the various tools that the RDBMS offers to manage data. The database expert loaths the way that developers start implementing relational contraints in code instead of applying the appropriate design concepts of foriegn keys, triggers, stored procedures etc. I’ve seen this many times. Often I’ve seen the opposite where database folk have decided to embed code into their domain. To really get this right each party needs to understand the value that the other brings to the table. But I continually read laments from either side criticising the way that this or that should really be done over here and not there.

Which brings us into LDAP. This underused gem is typically used by the development community simply as a convienient pre-built authentication tool. Even when LDAP is used a lot of information is then stored in an RDBMS that it really does not do well; or at least as well as LDAP. I’ll spare you the history of why this is so and how it came to be but the fundamental difference between the two is that RDBMS generally is a collection of flat file tables that are related by loose rules; whereas the LDAP server is a tightly coupled hierarchy of objects (called the Directory Information Tree – DIT) similar in nature to that of other concepts like XML.

LDAP servers are generally built for high speed retrieval and mass replication focussed on the enterprise, where RDBMS is a general ledger store house, and pretty primative too. The kind of data then that you should store in the LDAP directory is structural data. Like say configuration data for a telephone system or contact information for a customer relationship management (CRM) type of application. Even the configuration and preferences information of WordPress for this blog should really be stored in an LDAP server. But its not.

If you want to know if the data that you are looking at is suited to LDAP then consider.

  • Is the data dynamic or relatively static?
  • Does the data need to be distributed?
  • Can the data be used by more than one application?
  • Is the data multi-valued?
  • Can your data or application take advantage of a hierarchical relationship?
  • Do you need flexible security options?
  • Do you need single sign-on?
  • Do you need distributed or delegated administration capabilities?

If you can answer yes to some or all of these questions, then directories and directory-based applications would likely be useful to your application or project.

So why did I write this post? Basically it is a pointer into the world of LDAP for those who’ve not thought of it. A start. If you really want a better introduction go here. Have fun.


Copyright © 1996-2010 Code Snips. All rights reserved.
iDream theme by Templates Next | Powered by WordPress