Getting to Know LDAP and Directories: What to Consider
Articles and Tips: article
LDAP Directory Specialist
PricewaterhouseCoopers
vikas.mahajan@us.pwcglobal.com
01 Aug 2001
This AppNote presents an overview of Lightweight Directory Access Protocol (LDAP) and directories in general. It lists some of the things to be considered when choosing an LDAP-compatible directory for deployment or development purposes.
This information is adapted from an article published on the LDAPzone Web site at http://www.ldapzone.com. This is a great source for learning how to profit from developing solutions and services with LDAP, as well as XML (eXtensible Markup Language), DSML (Directory Services Markup Language), and other network industry standards.
- Introduction
- Directory Services Primer
- An Overview of LDAP
- Benefits of Using LDAP Directories
- Conclusion
|
Topics |
directory services, full-service directory, Lightweight Directory Access Protocol (LDAP), Novell eDirectory |
|
Products |
Novell eDirectory |
|
Audience |
network administrators, integrators, developers |
|
Level |
beginner |
|
Prerequisite Skills |
familiarity with networking basics |
|
Operating System |
n/a |
|
Tools |
n/a |
|
Sample Code |
no |
Introduction
Consider eDirectory, iPlanet, Active Directory, and other leading LDAP servers. If you are new to the world of directories, you may be wondering exactly what a real directory service is and how to best make use of one. Perhaps you are wondering when to use the directory as opposed to a relational database. The biggest obstacle most developers and administrators face in implementing LDAP is reaching an understanding of the database structure. It's difficult at first to determine how attributes, object classes, and distinguished names function. This AppNote will help you learn more.
Directory Services Primer
This section presents the basics of what a directory service is and what it is not. It also introduces the concept of a full-service directory.
What Is a Directory Service?
A directory is an organized listing of data or information. The directory with which most people are familiar is the telephone book. The white pages directory provides a easy way to store, organize, and search for telephone numbers and addresses of people and businesses in your community. Your computer also stores data in directories (or folders). The Windows directory, for example, contains files related to the Windows operating system. Underneath the Windows directory you will also find a System folder, which contains files related to the operations of the operating system (such as DLLs). So the file system directory allows you to create a hierarchy of folders to logically organize and manage files.
A directory service stores information about a network and the resources available on the network and makes this information available to users, devices, applications or anything else that requests the information. The directory commonly stores information about users, servers, printers, and other network devices. Directory entries are represented as objects. Objects contain information that identifies and characterizes the entry they represent.
Directory service design allows for a hierarchical arrangement of network resources. This design is referred to as the Directory Information Tree. The tree is actually inverted, starting with the ROOT at the top and then branching out. The tree can be made up of either container or leaf objects.
A container object is analogous to a folder or branch because it can store other objects beneath it. Container objects are commonly used to organize the directory. For example, if you have a company with offices in New York and Chicago, you may want to use two container objects-one for each city-to organize the structure of your tree to reflect that of your geography. Container objects may contain additional containers, or subcontainers, to further divide and organize the tree.
A leaf object represents an actual network entry such as a user, group, printer, server, and so on. Leaf objects don't necessarily represent something physical. Rather, they represent organized units of data stored in the directory. For example, a leaf object may represent rules or policies used by a particular application or device.
The directory itself is governed by certain rules that define the type of data it can store, the syntax of that data, and the objects the directory can contain. These rules are collectively referred to as the directory schema. The schema rules can be divided into two sets of definitions: object classes and attributes.
Object class definitions define the type of objects the directory can store and the attributes the object can have.
Attribute definitions define the structure of an attribute including syntax and constraints. The attribute value is the actual content or data.
One of the prime benefits of directories is schema extensibility. This allows for easy modification of the directory to meet the needs of your applications or business requirements. For example, Novell's directory schema is easily extended through its support for all leading interfaces and programming languages, and on most popular servers.
Applications (of which NOS logon is only one category) need access to user information and attributes in the directory. Directory-enabled applications can make use of the directory to store user information and so that users can move freely from desk to desk (and to laptop and handheld) without worrying about configuration details.
What Isn't a Directory Service?
From our broad definition of a directory, many rudimentary user stores appear to have the fundamental building blocks of a directory service. But now we examine the taxonomy of a "real" directory service by examining differences between a full-service directory and the rudimentary user lookup and authentication stores in use in many of today's applications.
While simplified directory stores, such as domains, relational database tables, or flat files, can provide authentication services, these architectures generally lack the sophistication to store meaningful user data and securely share that data with other applications or resources across the network and the Internet. These systems are designed for specialized uses and limited user counts, using proprietary databases that lack the scalability to handle millions of users. And because these systems are designed for specific applications, they are often unable to interoperate with the corporate directory, leaving network customers with a plethora of usernames and passwords to manage. Finally, because these systems lack an open, extensible schema they are unable to expand and adapt to the needs of the customer's business.
The Problem of Directory Proliferation
Examining a typical business, we can find the problem of directory proliferation throughout the enterprise. In fact, Forrester Research and Gartner Group discovered the average Fortune 1000 company has more than 180 disparate directories. How can there be so many? Just consider how many systems and applications require user stores: e-mail, NT domains, NetWare 3.x binderies, mainframes, database applications, Unix systems, PKI, VPN, intranet, ERP, custom applications, PBX, security systems, and so on.
The list of applications that require support grows very quickly once you consider all operations of a business. And the drain on IS resources takes the form of redundant administration, focused on daily password resets, instead of more important application deployments, system upgrades and maintenance, or (wouldn't it be nice) integrating key platforms for the future.
The Solution: A Full-Service Directory
The solution to these problems is a full-service directory. The full-service directory provides a single source for management, authentication, authorization, and administration of users and other directory-enabled network resources. Here are some of the services that a full-service directory, as defined by Aberdeen Group and Novell, should provide:
Discovery allows you to browse, search, and retrieve information in the directory. It consists of several components: publication, notification, search, identification, retrieval, and indirection.
Security allows you to control access to directory information and control the flow of information throughout your intranets, partner networks, customers, and the Internet. The components of security include authentication, key management, qualification, authorization, enforcement, and audit.
Storage describes the ability to store information in the directory database. The database can be indexed, cached, and distributed. Components of storage include persistence, integrity, segmentation, distribution, indexing, caching, and classification.
Relationship gives you the ability to build associations between people, network devices, applications, and other resources and information. Relationship consists of federation, organization, collection, registration, reference, inference, policy, and subscription.
(A detailed discussion of the full-service directory is available online at http://www.novell.com/products/nds/fsd.)
As you can see, the benefits and features of a full-service directory are extensive. Novell's LDAP-compliant directory, Novell eDirectory, provides all of these. For these reasons it is far superior to the proprietary authentication and lookup services available in many applications today. It provides a scalable, high- performance, fault-tolerant, and secure platform for a variety of key services, including authentication, authorization, and personalization. And with complete LDAP access through C, Java, and scripting APIs, writing applications to take advantage of the power and reach of the directory has never been smarter, faster, or easier.
An Overview of LDAP
No longer an option for network applications, the directory service in all its forms has quickly become a core component of eBusiness infrastructure development. And the surging number of disparate directories is likewise fueling the need for access and interoperability standards such as LDAP, XML, SOAP, DSML, and others.
Among these standards, Lightweight Directory Access Protocol (LDAP) enjoys broad industry acceptance as the protocol for deploying directory-based applications and solutions. Novell, the Sun-Netscape Alliance, Red Hat, Sun, Microsoft, Oracle, and IBM, along with other leading ISV developers, consultants, and system integrators, have all endorsed LDAP.
The Evolution of LDAP
The OSI X.500 standard first released in 1988 serves as the basis for most directory technologies, including Novell eDirectory. It is not necessary to understand the X.500 standard to understand LDAP or eDirectory. However, we refer to X.500 for historical purposes to guide the discussion on the evolution of LDAP and NDS.
The X.500 standard defined a client Directory Access Protocol, or DAP. DAP provided the ability to read, search, and modify the directory. However, DAP tended to be complex, often requiring more processing power than desktop computers of the age could provide. As a result of this complexity, research began at the University of Michigan to develop an alternate, "lighter" version of DAP that could operate over the TCP/IP protocol stack. This effort resulted in the creation of the LDAP specification. Ongoing LDAP development was then handed to the IETF (Internet Engineering Task Force). Since that time, the IETF has released additional specifications to complement LDAP, including schema extensions, syntax definitions, and a data interchange format.
Initially LDAP directories focused on personal information such as names and addresses, but LDAP directories are now becoming the foundation for heterogeneous network operating systems and enterprise-wide systems management. Applications running on disparate platforms can now use the LDAP protocol to access corporate directories for user information and authentication.
The Evolution of Novell's Directory Service
It's easier to understand LDAP if you understand the strategic role the directory occupies in the networked enterprise. Years ago, Novell recognized the importance of a single, enterprise-wide system to manage users and resources across the network. This resulted in the creation of NDS, released with the NetWare 4 Operating System. However, with the arrival of the Internet, Novell realized the importance of extending the reach of the directory beyond a single operating system. The company also realized the directory needed to be platform independent, extensible through open standards, and massively scalable to support exponential numbers of users, customers, partners and suppliers.
This resulted in the creation of eDirectory, Novell's 8th generation directory. Novell eDirectory 8.5 provides native LDAP support and has been demonstrated to scale beyond 1.5 billion objects with little or no loss in performance. Furthermore, it includes the features inherent in previous versions of NDS, including multimaster replication and referential integrity. The result is a proven LDAP directory that can serve as both an enterprise and an eBusiness platform with no concerns about reliability, security, or scalability.
In 1997, Novell embraced LDAP as a preferred protocol for developing directory-enabled networking solutions. Today, Novell eDirectory is a full-service directory running on NetWare, Linux, Solaris, Windows, Tru64 and AIX servers, offering complete LDAP version 3 support while providing the unsurpassed scalability, security, redundancy, and high-speed performance required in today's e-business environment.
Benefits of Using LDAP Directories
Companies deploy directories such as Novell's to lower administrative costs, simplify and/or distribute administration, reduce user logins/passwords via single sign-on, enhance security, and provide a single location for information about users. Directories are also major components of enterprise PKI (Public Key Infrastructure) deployments and identity management initiatives.
From the developer perspective, using LDAP to store application user information in the directory means reduced development time because there is no need to design your own user data store. You can easily access and leverage the security features inherent in eDirectory to provide authentication and/or authorization for your application. What's more, because your application uses LDAP, it can quickly locate any type of directory information it needs, regardless of the target platform, saving you from having to develop this functionality yourself.
Since the directory contains user information, it is also ideally suited for large-scale application personalization and identity management. From a Web perspective, this means leveraging the directory for portal services, B-to-B, or supply-chain initiatives. For example, CNN.com is a premier example of rapid delivery of personalized content and advertising that can be created with LDAP and eDirectory. Xircom, an Intel company, is leveraging eDirectory to establish a single global repository for both internal and external identity and profile information. The use of directory services is rising dramatically, and Novell's leads its competitors when it comes to satisfied customers with real-world directory success stories.
So what types of information would you store in the directory? Recall that directories are optimized for read performance and as such, the data you store should not require frequent changes. User profile information, such as address, phone number, e-mail address, and personal preferences, are ideal for directory lookup. But BLOB data or transactional data is not recommended for storage in the directory. Remember, directories are not replacements for relational databases.
Choosing an LDAP Directory
With an accepted standard in place, it might seem that today's multiple competing LDAP directories are identical. It is true that LDAP-compliant directories will understand and reply to the same LDAP queries and commands. However, this is not enough to provide all of the functionality required by customers who are looking for a full-service directory.
So, what are the advantages of a full-service directory from a customer perspective, and why should the LDAP developer choose eDirectory?
Consider the Vendor Perspectives. Novell evolved NDS eDirectory from the networking perspective. Sun-Netscape's iPlanet was created from the Internet perspective. Microsoft created Active Directory to support the Windows platform.
Consider Scalability and Reliability. The LDAP specification does not define the directory's underlying data store or repository, instead leaving this choice to directory vendors. It is within this data store that a great many features of the directory depend upon. While some vendors have chosen to build their LDAP solutions on top of a RDBMS, most vendors have instead opted to use proprietary data stores that are optimized for directory performance and scalability.
For example, iPlanet Directory Server relies on the Berkeley sleepycat B-tree database. Novell eDirectory is built upon a database known as FLAIM. While the architecture of this database is beyond the scope of this document, it should be noted that Novell has publicly demonstrated this database to scale beyond 1.5 billion objects. It is precisely this type of scalability that sets Novell's LDAP directory apart.
Consider Technical Maturity. LDAP specifications do not yet define a standard for replication. Once again, the vendors are left to implement this as they see fit. Some vendors have chosen a supplier-consumer based replication architecture, where a single Master server is able to handle write requests, and changes are propagated from the Supplier server to various read-only consumer servers. The Supplier-Consumer architecture is used by iPlanet Directory Server. It is also used by Microsoft NT domains; however, Active Directory features multi-master replication.
Novell, on the other hand, has always used a multi-master replication scheme to allow the directory to be distributed across many servers, each of which could hold a read/write copy of the database. In addition, the schema is also replicated across servers.
Novell eDirectory allows container-level partitioning, meaning replication can occur at the container level, as opposed to requiring the replication of the entire database. With eDirectory 8.5, Novell also supports a filtered replica, allowing customers to replicate only the objects and attributes needed, offering "full-service functionality" that keeps users, information, and applications up to date as it saves administrative time and maximizes network bandwidth.
Directory versus Database
A common misconception is that directories exist to somehow replace traditional relational database management systems (RDBMS). However, the truth of the matter is that directories and databases complement one another. Directories and databases serve different purposes and each is optimized for suitability to their respective tasks.
For example, directories are optimized for reading rather than writing. This makes the directory an ideal place to store information that does not change frequently. Directories lend themselves well to query and lookup operations. Directories are hierarchical, allowing for distributed administration. Directories are designed for easy replication and distribution. Finally, directories incorporate standard schemas that can be extended, replicated, and distributed.
Relational databases, on the other hand, are designed to be transactional. They provide no standard schema. Administration and storage are centralized. Databases provide repositories for storage of historical, general-purpose data and provide query functionality for reporting and analysis (using Structured Query Language). Databases are relational, not hierarchical and they are not object-oriented in nature.
So when deciding which pieces of data to store in the directory versus a RDBMS, recall the strengths and weaknesses of each system and their suitability to the task. The directory is the ideal data store for frequently read information that needs to be distributed.
Other Advantages
Furthermore, the directory offers powerful, yet flexible security services that go beyond simple passwords. The authentication and authorization services available via the directory enable you to provide single sign-on, PKI, digital certificates, biometrics, tokens, and other advanced forms of security services.
In addition to numerous technical advantages noted in this AppNote, integrating an LDAP directory with your applications comes with marketing and sales advantages even hard-core programmers can appreciate: lots of informed potential customers for your solutions. For example, Novell currently supports over 139 million directory users in networked enterprises and directory-powered applications on the Internet.
Novell eDirectory also powers a full suite of Net services from Novell and its developer partners, including DirXML, onDemand, iChain, NetWare, Novell Modular Authentication Service (NMAS), ZENworks, and many more. The result is a growing, secure and robust technology environment for commercial application providers to deliver into. For more information about Novell Net services that leverage eDirectory, visit http://www.novell.com/products/nds.
Conclusion
The future of eBusiness is directory-enabled, which is why leading software developers are integrating Novell's proven LDAP directory today. Novell eDirectory comes with a growing marketplace of millions of customers, along with easy access to the latest LDAP-friendly programming tools, and free online developer support and training.
Through its DeveloperNet program, Novell provides tools, resources, and support for developers looking to create solutions that leverage the industry's leading LDAP directory. And to get you pointed in the right direction, DeveloperNet can also provide a full-function, 250,000-user download of Novell eDirectory for you to ship with your product, absolutely free. This valuable new download, worth over US $500,000, will help you facilitate new customer product sales.
For easy access to Novell's tools for using eDirectory in your solutions, visit the Novell Developer Kit Web site at http://developer.novell.com/ndk
For more information about developing to NDS eDirectory, visit http://developer.novell.com/nds.
To sign up for DeveloperNet at any level, including free, visit http://developer.novell.com/servlet/subscribe.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.