1. LDAP Introduction 4
1.1. What is LDAP 4
1.2. LDAP is the phone book 4
1.3. Is LDAP a database? 42. Characteristics of LDAP 5
2.1. LDAP advantages 5
2.1.1 cross-platform 5
2.1.2 cost and maintenance 5
2.1.3 replication technology 5
2.1.4 use of ACI 5
2.2. What data does LDAP store 6
2.3. When should I use LDAP to store data? 6
3. basic LDAP Model 7
3.1 Information Model: Describe LDAP Information Representation 7
3.2 naming model: describes how data in LDAP is organized 7
3.3 Functional Model: Describe data operation access in LDAP 7
3.4 Security Model: Describe the security mechanism in LDAP 8
3.4.1 Identity Authentication 8
3.4.2 Communication Security 8
3.4.3 access control 84. LDAP Data Structure 9
4.1 Tree Structure 9
4.2 entry and entry authentication 9
4.3 Data style (schema) 9
4.4 object type (objectclass) 9
4.5 filters and syntax 10
4.6 tree transplantation 10
4.7 ldif swap file 10
4.8 Java or CORBA object serialized storage 10
1.1. What is LDAP?
LDAP is a Lightweight Directory Access Protocol, which is short for Lightweight Directory Access Protocol. It is based on the X.500 standard, but it is much simpler and can be customized as needed. Unlike X.500, LDAP supports TCP/IP, which is required for Internet access. LDAP core specifications are defined in RFC. All LDAP-related RFC can be found on the ldapman RFC webpage.
In short, LDAP is a quick way to obtain centralized and static data about people or resources.
LDAP is a protocol used to publish directory information to many different resources. It is usually used as a centralized address book, but it can be more powerful according to the organizer's needs.
1.2. LDAP is the phone book
LDAP is actually a phone book, similar to the network directories we use, such as NIS (Network Information Service) and DNS (Domain Name Service), and similar to the trees you see in the garden.
1.3. Is LDAP a database?
Many LDAP developers prefer to consider LDAP as another storage method compared with relational databases, and then compare the reading performance. In fact, the basis of this comparison is incorrect. LDAP and relational database are two different levels of concept, the latter is the storage method (the same level, such as grid database, object database), the former is the storage mode and access protocol. LDAP is a storage concept that has a higher level than the abstract level of relational databases. It is at the same level as the query language SQL of relational databases. The most basic form of LDAP is a standard method for connecting to the database. The database is optimized for read queries. Therefore, it can quickly obtain the query results, but it is much slower in other aspects, such as updates.
In another sense, LDAP implements the storage of the specified data structure, which is a special database. But LDAP is different from general databases. It is very important to understand this point. LDAP optimizes the query performance, which is much better than the Write Performance of LDAP.
Just as Sybase, Oracle, Informix, or Microsoft's database management system (DBMS) is used to process queries and update relational databases, the LDAP server is also used to process queries and update LDAP directories. In other words, the LDAP directory is also a type of database, but it is not a relational database. Note that LDAP is usually used as a hierarchal database instead of a relational database. Therefore, its structure is better to represent in a tree than in a table. Because of this, you cannot use SQL statements.
2. LDAP features
2.1. LDAP advantages
2.1.1 cross-platform
The biggest advantage of LDAP is that it can access the LDAP directory with an easy-to-obtain and increasing number of LDAP client programs on any computer platform. It is also easy to customize the application to add LDAP support to it.
LDAP is a cross-platform and standard protocol. Therefore, applications do not have to worry about the servers on which the LDAP directory is stored. In fact, LDAP is widely recognized in the industry because it is the internet standard. Developers are willing to add LDAP support to their products because they do not have to consider what the other end (client or server) is like. The LDAP server can be any development source code or commercial LDAP directory server (or a relational database with an LDAP interface ), because you can use the same protocol, client connection software package, and query commands to interact with the LDAP server. Different from LDAP, if software vendors want to integrate DBMS support in software products, they usually have to customize each database server separately.
2.1.2 cost and Maintenance
Unlike many commercial relational databases, you do not have to pay for each LDAP Client connection or protocol.
Most LDAP servers are easy to install and are easy to maintain and optimize.
2.1.3 replication technology
The LDAP server can use the "push" or "pull" method to copy part or all of the data. For example, you can push the data to a remote office to increase data security. Replication Technology is built into the LDAP server and is easy to configure. If you want to use the same replication function in the DBMS, the database producer will have to pay additional fees and it is difficult to manage them.
2.1.4 enable ACI
LDAP allows you to use ACI (generally called ACL or access control list) as needed to control the read and write permissions on data. For example, the device administrator can change the employee's work location and office number, but cannot change other domains in the record. ACI can control data access based on who accesses the data, what data is accessed, where the data exists, and others. Because these are all completed by the LDAP directory server, you do not have to worry about whether to perform security checks on the client applications.
2.2. What data does LDAP store?
LDAP is most useful for storing such information: data needs to be read from different locations, but it does not need to be updated frequently. For example, the information stored in the LDAP directory is very effective:
L telephone number book and organization structure of company employees
L customer contact information
L information required for computer management, including NIS ing, email Kana, and so on
L configuration information of the software package
L public certificate and Security Key
2.3. When should I use LDAP to store data?
Most LDAP servers are specially optimized for read-intensive operations. Therefore, reading data from an LDAP Server is an order of magnitude faster than reading data from a relational database specially optimized for OLTP. This is also because it is specially optimized for read performance. Most LDAP directory servers are not suitable for storing data that needs to be changed frequently. For example, using an LDAP server to store phone numbers is a good choice, but it cannot be used as a database server for e-commerce sites.
If the answer to each of the following questions is "yes", it is a good idea to store data in LDAP.
L do I need to read data on any platform?
L does each individual record item have only a few changes each day?
L can I store data in flat databases instead of relational databases? In other words, no matter what paradigm is not normal, put everything in a record (almost as long as the first paradigm is satisfied ).
The last problem may be confusing. In fact, it is common to use a flat database to store relational data. For example, a company employee's record can contain the manager's login name. It is convenient to use LDAP to store such information. A simple judgment method: If you can store data in a card, you can easily store the data in the LDAP directory.
3. basic LDAP Model
3.1 Information Model: Describe LDAP Information Representation
In LDAP, information is organized in a tree-like manner. The basic data unit in the tree-like information is an entry, and each entry is composed of attributes, which store attribute values. Information Mode in LDAP, similar to the object-oriented concept, each entry in LDAP must belong to one or more object classes. Each object class consists of multiple attribute types, each property type has corresponding syntax and matching rules. The definition of object classes and property types can all use the concept of inheritance. When creating an entry, you must define the object class to which it belongs. You must provide the attribute values of the required attribute type in the object class. In LDAP, an attribute type can correspond to multiple values.
In LDAP, object classes, attribute types, syntaxes, and matching rules are collectively referred to as schema. In LDAP, there are many system object classes, attribute types, syntaxes, and matching rules, these System schemas are defined in the LDAP standard, and their own schemas are also defined in different application fields. You can also customize the schema as needed during application. This is similar to XML. In addition to the XML definition in the XML standard, each industry has its own standard DTD or DOM definition, and users can also customize it. It is also similar to XML, in LDAP, users are also encouraged to use standard schema whenever possible to enhance information interconnection.
Matching rules are the most difficult to understand in the schema. In LDAP, to speed up the query, different matching methods can be provided for different data types, for example, you can set matching rules for equal, fuzzy, or greater than or less character string types.
3.2 naming model: describes how data is organized in LDAP
The naming model in LDAP, that is, the entry Locating Method in LDAP. Each entry in LDAP has its own DN and rdn. The dn is the unique name of the entry in the entire tree. The rdn is the unique name of the entry under the parent node. In the file system, the path file name is the DN, and the file name is the rdn.
3.3 Functional Model: Describe data operation access in LDAP
There are four types of 10 operations in LDAP: query operations, such as search and comparison; update operations, such as adding, deleting, modifying, and modifying an entry name; authentication operations, such as binding and unbinding; other operations, such as giving up and scaling. In addition to extended operations, the other nine types are LDAP standard operations. extended operations are a standard extension framework provided by LDAP to add new functions, currently, it has become an extension operation of the LDAP standard, including password modification and starttls extension. Some new extension operations are being added in the new RFC standard and draft, different LDAP vendors also define their own extension operations.
3.4 Security Model: Describe the security mechanism in LDAP
The security model in LDAP is mainly implemented through identity authentication, Security Channel, and access control.
3.4.1 Identity Authentication
LDAP provides three authentication mechanisms: Anonymous, basic authentication, and SASL (simple authentication and secure layer) authentication. Anonymous Authentication does not authenticate users. This method is only applicable to fully public authentication. Basic Authentication uses the user name and password for identity recognition, which is divided into simple password and digest password authentication; SASL authentication is an identity authentication provided by LDAP based on SSL and TLS security channels, including digital certificate authentication.
3.4.2 Communication Security
LDAP provides communication security assurance based on SSL/TLS. SSL/TLS is a security service widely used on the Internet based on PKI information security technology. LDAP starts the TLS service in starttls mode to provide data confidentiality and integrity protection in communications. It is a TLS service that enforces client certificate authentication, at the same time, the client and server identity can be verified in two ways.
3.4.3 Access Control
Although LDAP currently does not have access control standards, it is not difficult to see from some drafts or in fact the access control situation of LDAP products: LDAP access control is flexible and rich, in LDAP, access control is implemented based on access control policy statements. Unlike existing relational database systems and application systems, access control lists are used to implement access control, the group mode or role mode cannot be used.
When developing applications using a relational database system, the database is often accessed through several fixed database usernames. For the access control of the application system, a special user table is usually required to develop the access control authorization code for different users in the application system. Once the access control policy is changed, code changes are often required. In a word, user data management and database access identification are separated in relational database applications, and complex data access control needs to be implemented through applications.
For LDAP, user data management and access identity are integrated, so applications do not need to care about the implementation of access control. This is because the access control statements in LDAP are implemented based on policy statements, whether it is the data object of access control or the subject object of access control, these are related to the location of these objects in the tree and the data features of the objects themselves.
In LDAP, authorization can be performed by using the entire directory and directory subtree, specifying entries, specific entry attribute sets, or entries that meet certain filtering conditions as control objects; users in a specific group or all directories can be authorized as authorization subjects. Finally, they can define access to a specific location (such as an IP address or DNS name. 4. LDAP Data Structure
LDAP implements the storage of a specified data structure. It includes the following structural requirements that can be implemented by relational databases: Tree organization, entry authentication, type definition, and permission tree-like record copy.
4.1 Tree Structure
Both x500 and LDAP record data in a tree. Each tree directory has an entry to the root of the tree, and all the sub-records are the child of the root. This is the biggest difference between a directory and a relational data type (the application structure of a relational database can also achieve tree-like records ). Therefore, it is impossible to regard the directory as a more advanced tree database, except that it cannot implement the important functions of relational storage.
4.2 entry and entry Authentication
LDAP uses entries as the basis for authentication. Root permission authentication has nothing to do with the directory itself, but the authentication permissions except for all entries are authenticated by the password of the entry. LDAP can be configured with a variety of permission inheritance methods for parent and child entries.
Each entry is equivalent to a single flat text record, which is accessed by the entry itself or specified entry authentication. Therefore, the storage structure defined by LDAP is equivalent to a batch of tree-structured flat databases and provides access control.
Records in an entry exist in the form of name-value pairs. Each name-value pair must be predefined by the Data style schema. Therefore, LDAP can be seen as a set of records stored in a series of tree-organized flat databases in the form of a specified value type in name-value pairs.
4.3 Data style (schema)
Data style schema is intended for different applications. It is pre-defined by the user's specified (Design) class and attribute type, and the class (objectclass) in the entry) and attributes must be loaded into the memory schema when the LDAP server is started. Therefore, the entries in the Active Directory must comply with the schema of Active Directory. If the definition in the provided schema is not enough, you can define a new schema.
You can see common schemaas in http://ldap.akbkhome.com/index.php.
4.4 object type (objectclass)
Because the LDAP directory can be customized to store any text or binary data, it is up to you to decide what to save. The LDAP directory uses the object type (objectclass) to define which type of objects to run and what attributes to use. In almost all LDAP servers, you need to expand basic LDAP directory functions as needed, create new object types, or expand existing object types.
Records in an entry are classified using objectclass. objectclass is an inherited class definition, which specifies the required attributes. If an entry must meet a certain type, it must have the attributes specified by the superclass.
By using objectclass classification, records in scattered entries actually create an index structure, laying the foundation for High-Speed Read queries. Objectclass is also the main query object of the filter.
4.5 filters and syntax
LDAP is a query-based record structure. No matter what query method is used, it is ultimately based on the filter defect query conditions. The filter is equivalent to the WHERE clause in SQL. All LDAP class filters and strings must be placed in parentheses. For example, (objectclass = *) indicates to list all types of records (not classified ).
You can use =, >=, <= ,~ = (Approximately equal to) for comparison, such as (number <= 100 ). The condition for merging is the most strange. operators must be placed before two operation objects rather than in the middle. A single operation object is enclosed in parentheses. For example
L a and B, Not A & B, but (& (a) (B )).
L or use "|" to indicate;
L not used "! .
L for "and", "or", after the operator, multiple conditional expressions can be followed, but if not, only the parameter is a single expression.
For details, see rfc1558.
4.6 tree transplantation
The most important features and requirements of LDAP are not read performance, but extensibility. This feature is implemented through tree transplantation and tree replication. According to the RFC requirements of LDAP, the LDAP directory should be connected, merged, automatically copied, and automatically synchronized between different directories. This means that the user can access entries in any LDAP, regardless of whether a part of the entries are copied from another directory in the world, and the records in the other directory are also working properly.
If this feature is implemented in a relational database, it means that you need to use programmatic non-standardized pre-replication. Similar to the design of summary accounts.
4.7 ldif file exchange
Ldif is the record exchange format agreed by LDAP. It exists in the form of flat text and serves as the basis for most LDAP content exchanges. operations such as copying, adding, and modifying are performed based on ldif files.
4.8 Java or CORBA object serialized Storage
Efficient Network Access and cross-platform Java capabilities. When Java or CORBA objects are serialized and stored in the LDAP directory, they can produce extraordinary integration results-in fact, this is exactly what EJB and. net network positioning technology.
When using Java or CORBA for Object Storage, you must first enable the LDAP service to support the object definition, that is, including Qmail. schema or CORBA. schema.
Java must be stored in the objectclass = javacontainer entry and must have the CN attribute. This means that unless the Java class specifically implements the dircontext interface, for most Java classes, you can only use dircontext instead of context to add bind. It is much easier to retrieve the Java class. You only need to use context. Lookup () to obtain the handle of this object, and then forcibly shape it into the desired object, for example:
Person P = (person) contex. Lookup ("cn = Elvis, Dc = daifu, Dc = com ");
This syntax is often used in EJB programs.
By using the cross-language nature of CORBA, it is more attractive to store objects using CORBA than Java, which means that the stored objects can be accessed by clients written in any language. In fact, Microsoft's. net is also very simple in the end, it is nothing more than to store COM objects in Microsoft's own directory ActiveDirectory, so that the network can use any language on the Microsoft platform for object access. As we all know, COM is the Microsoft specification relative to CORBA.
Using Object serialization technology, you can store common objects such as a printer and a customer directly in LDAP, and then quickly obtain the reference of the object, it is much more efficient than storing the object information in a relational database, taking out the attributes separately, and then initializing the object operation. This is a better place for LDAP than normal relational database storage, and the object database is not mature yet.
|
