This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
it's a persistent store that is optimized for reads (vice writes) with a framework for querying a tree-based hierarchy, both elements and attributes. openLDAP is the open-source version, elsewise netscape is the big player.
Could you please explain more as I am new to LDAP as well?
Joined: Mar 12, 2001
Yeah maybe I'm just a novice security guy but could you explain that in english please?
Joined: Aug 05, 2002
well, i think of it (correctly or not) as very similar to a database (i.e. persistent store) but optimized for reading, therefore useful for keeping data that does not need to be changed often (typically, user login data). it differs from a database in that the data is stored hierarchically, so you access data by navigating the tree (like a DOM i guess). it also has a query language not at all like sql, that gain emphasizes the hierarchic nature of the data.
Hello ! Imagine how to maintain 2500 users with access profiles to several corporate platforms like Lotus Domino, An application server, a content management system , SAP etc. ... Wouldn't it be nice to maintain all those profiles from just one place with a "single sign on". As an example will a Logon to SAP give you implicit rights to the other platforms via LDAP. Hopefully my english was not that bad !!
Simply put a Directory is a hierachical data store. Information is stored as objects in folders (containers) or as leaf nodes. LDAP is a protocol used to access data in this data store. Directory vendors support a server that can understand this protocol, and perform operation as specified by this protocol. Well known directories are Novell's eDirectory, Microsoft's Active Directory and Sun/Netscape Directory. LDAP directories are typically used to store User information - like login-name/password/profiles etc, like a phone book (phone directory) if you will. This way there is one place to store employee information: name, email, dept, phone, title, blah.blah. When one such directory is designed and populated within one company, then many LDAP aware products can integrate with this directory, such as, VPN, Outlook, building access/security products, etc.etc. Now when I change my password, I automatically reflects within all these other zillion applications...or if I walk one employee out of the door, there is one place to turn it "off". But be aware to plan for redundancy and fault-tolerance 'cos if the CEO cannot login, you could be fired
LDAP itself is just a protocol, just like HTTP, SMTP, etc... The various products, such as Active Directory, eDirectory, Sun One Directory Server, and OpenLDAP, all have their own way of doing the actual storage of information on disk, but use LDAP as a way for clients to access and manage the information. A lot of people will say that LDAP vs. Database is a comparison of faster searches vs. transactional and relationship capabilities. While this is usually true, the real judge of the type of information that should be accessible via LDAP vs a Database is twofold: 1. Is there standard schema for the data being stored? The LDAP standards define not only a protocol, but various schema related to things such as people and groups. Directories that store this type of information can be reused by many applications out-of-the-box, whereas with most databases there is no standard schema for this type of information so something custom is generally done to hook in this type of general-purpose information. 2. Even if the information is defined in a standard schema, it may not be worthwhile storing it in LDAP or it may be. The second test is really whether the data being stored is generally useful to a variety of applications in a non-relational way. Meaning that if you are constantly associating users with sales information in reports, it may be important that user information is stored in a database. The reverse could be true if you have relatively stand-alone information that is generally useful to many different applications, but doesn't have standard schema defined. Sometimes information both needs to be in relation with other information and accessed in a standard way (such as LDAP) by off-the-shelf applications (like Netegrity and many application servers). In those cases there are various integration technologies that either synchronize information between directories and databases (meta-directories) or performs database->LDAP translation on the fly (virtual directories). From a programmer's perspective and from a security perspective, the reason LDAP is so important is that most user accounts are now being managed in an LDAP-enabled directory. As an application developer, you wouldn't want the people using your applications to have to manage a whole set of users just for your application if these users are already being managed (passwords and everything) in an existing repository. Since most of those repositories are LDAP-enabled, you can easily use something like JNDI or JAAS to do your own authentication to these stores or use the built-in functionality in an application server (such as the LDAP Realm in BEA WebLogic Server). Hope this helps... Clayton [ March 17, 2003: Message edited by: Clayton Donley ]