Research and Design of LDAP-based Web Identity Authentication Mechanism

Guidance:
　　AbstractThis article introduces some basic knowledge about LDAP Lightweight Directory Protocol and a possible architecture and implementation of LDAP-based Web application system security.
　　KeywordsLDAP, Web authentication, and information security
　　1 Overview
In a computer world, information can be shared, and standards supported by all parties must be defined. The X.500 standard is a Directory Access Protocol developed and released by ITU (International Telecommunication Union) in 1988 for standardized distributed directory systems. However, due to the complexity of X.500, the rule setting is too dead and the implementation is not very flexible. Therefore, IETF (Internet Engineering Task Force) designs the LDAP protocol based on X.500.
The short name of LDAP is Lightweight Directory Access Protocol, which is generally referred to as LDAP. The Lightweight Directory Access Protocol is directly translated into Chinese. The core specifications of the LDAP protocol are defined by a series of RFC files. Rfc3377 details that the third version of the Lightweight Directory Access Protocol (ldapv3) is composed of a group of nine RFC files. Including:
(1) [rfc2133]-Lightweight Directory Access Protocol 3: insecure LDAP specifications
(2) [rfc2252]-Lightweight Directory Access Protocol 3: attribute syntax definition
(3) [rfc2253]-Lightweight Directory Access Protocol 3: Express distinguished names with UTF-8 strings
(4) [rfc2254]-use strings to express LDAP search filters
(5) [rfc2255]-ldap url format
(6) [rfc2256]-Introduction to X.500 (96) User outline, in order to use ldapv3
(7) [rfc2829]-LDAP authentication method
(8) [rfc2830]-Lightweight Directory Access Protocol (3rd): Extended features of Transport Layer Security and RFC 3377 file itself.
　　2 basic LDAP knowledge
LDAP organizes directory information in a tree structure. Each branch is called an entry. Of course, this branch structure can be nested, that is, the branch can have its own Subbranch structure. The entry itself is only a name used to identify the name of the current branch. All information exists through the atrristmname and attribute value pairs under the entry.
LDAP uses text files to store information. You can use notepad in Windows or VI in Linux to edit the information. The LDAP configuration information and directory entries in this file must be organized in the ldif (LDAP Interchange Format) format defined in RFC 2849. Generally, in windows, "ldif" is used as the file suffix.
An ldif file contains a set of entries separated by empty rows. These entries are composed by mapping between attribute names and attribute values. For example, the directory structure in Example 1 is as follows, the possible content of the ldif file is:
　　
　　
Figure 1
# Ldif sample
DN: DC = Dhu, Dc = Edu, Dc = Cn
Objectclass: Top
Objectclass: Organization
DN: ou = computerdept, Dc = Dhu, Dc = Edu, Dc = Cn
Objectclass: organizationalunit
Ou: computerdept
Telephonenumber: 021-62378888
Description: container for all teachers and students within
Computerdept.dhu.edu. cndomain
DN: ou = mathdept, Dc = Dhu, Dc = Edu, Dc = Cn
Objectclass: organizationalunit
Ou: mathdept
In the preceding example, all the attributes on the left of the colon are the attribute names, such as DN, objectclass, ou, telephonenumber, and description. The values on the right of the colon are the attribute values corresponding to this attribute, the first line starts with a well number as a comment statement, and each segment separated by blank lines falls into an entry.
It is worth noting that the objectclass attribute. Each entry in the LDAP directory must have an objectclass attribute. This attribute can be assigned multiple values, but at least one value must be assigned. The objectclass in each entry acts as a template definition to specify and limit which attributes must be included in the entry and which attributes are allowed. That is to say, when an entry uses the objectclass attribute value to define which attributes must be described under the entry and which optional attributes are descriptive or not described. For example, in the preceding example, In the ldif document, DN: ou = computerdept, Dc = Dhu, Dc = Edu, Dc = Cn, The objectclass attribute value is organizationalunit, according to the definition of the objectclass organizationalunit in RFC 2256, the entry must have the ou attribute, you can have 21 attributes, including userpassword, searchguide, telephonenumber, and description. For a detailed list, see RFC 2256 ).
　　3. LDAP authentication mechanism
LDAP is a connection-oriented message-based protocol. Therefore, an authentication process must be used in an LDAP directory. This authentication process is used to establish the client's permissions for each conversation. All search, dialog, and other operations must be controlled by the permission level obtained by the authorized user.
Figure 2 shows the definition of another object class person, which we will use to further discuss the LDAP authentication mechanism.
　　
　　
　　
Figure 2
DN: Cn = Anfernee Wang, ou = computerdept, Dc = Dhu, Dc = Edu, Dc = Cn
Objectclass: person
CN: Anfernee Wang
SN: Wang
Telephonenumber: 201-1234
Userpassword: {MD5} xr4ilozq4pcoq3aq0qbuaq =
Here there is a userpassword attribute. Stores information used to verify a user. The prefix {MD5} indicates the algorithm used to encrypt the information. The information in this example is obtained by the 64-encoded MD5 Hash function.
The process of verifying through the LDAP directory becomes the state. Most users are used to logging on to a system using their usernames and passwords. When an LDAP client needs to be verified, the user name is specified as a DN. Here, the user name is Cn = Anfernee Wang, ou = computerdept, Dc = Dhu, Dc = Edu, Dc = cn. The input data used for verification will be compared with the userpassword attribute value.
LDAP v3 defines four client verification mechanisms: Anonymous Authentication, simple authentication, SSL/TLS-based authentication, and sasl-based authentication.
Anonymous Authentication uses an empty password in the binding operation. This authentication does not require user identity confirmation, so that the directory content is open to all users. For example, anonymous authentication can be used for querying public phone books and email addresses.
Simple authentication is a plaintext user name (DN)/password pair submitted to the client to the LDAP server during the binding operation. The server end and the Stored User Name (DN) /compare the password pairs. If they match, user identity authentication is successful. This authentication method is less secure because its password is transmitted in plain text on the network.
SASL-based authentication is to introduce SASL into LDAP as an Extended Authentication mechanism. SASL is an extensible security policy defined by rfc2222 and can be used as an additional authentication mechanism for connection-based protocols (such as IMAP and LDAP. SASL allows clients and servers to negotiate security mechanisms before transmitting any trust. With SASL, LDAP can support any type of authentication mechanism negotiated between the LDAP client and the server. The selected authentication mechanism depends on the required security level. An LDAP client can execute a search operation on the Root des of the LDAP server to obtain the "supportedsaslmechanic isms" attribute, so that it can know which SASL mechanisms the server supports. This attribute has been defined in the access control list ACLs to be read anonymously.
SASL-Based Authentication includes the following SASL mechanisms: SASL authentication using DIGEST-MD5, SASL authentication using CRAM-MD5, SASL authentication using certificates and external mechanisms defined by rfc2222.
SSL/TLS-based authentication. SSL is a protocol designed by Netscape for secure web transmission. This Protocol is widely used on the web. IETF standardizes SSL to form an rfc2246 file and converts it into TLS. Technically speaking, the difference between tls1.0 and SSL3.0 is very small. Their basic process is as follows: the SSL/TLS client sends a "clinethello" to initiate a handshake after the TCP link is established, this message contains a list of algorithms that you can implement and other required messages. The SSL/TLS server responds to a "serverhello" message ", determine which algorithm in the list is used for this communication, and then send your identity and public key. After receiving the message, the client generates an encrypted message, which is encrypted by the Public Key provided by the server. After the server decrypts the message with its own key, the session key negotiation is successful, both parties can use the same session key for communication. SSL/TLS must start an SSL/TLS session by sending an extendedrequest before the client sends a binding request. SSL/TLS must start an SSL/TLS session by sending an extendedrequest before the client sends a binding request.
　　4. Web Authentication.
When developing a web application system, it is best to leave the Security Authentication part to the Web server for processing. There are several reasons for doing so. An important reason is that Web servers usually have a solution that has been tested in practice to solve the authentication problem. If an additional chain ring is added to the security chain, developers are more likely to create a weak ring. Another reason is that it makes everyone's application systems more open. Generally, Web servers are tightly integrated with operating systems and security protocols on which they depend. By allowing the Web server to process identity authentication, your application system will be able to effectively utilize the close integration of the operating system and the web server.
　　5. Authentication for Apache Web Server
Assume that the Apache web server and tomcat have been installed on the computer, and Apache has been configured, You can correctly use Tomcat as the Apache Servlet and JSP server. Using LDAP to authenticate Apache users is free of charge. On the http://modules.apache.org/website, you can find the region registered with apache. We use the popular mod_ldap.c module, which is based on the achievements of lyonel Vincent and Norman Richard DS and is currently maintained by Jeff Morrow.
The mod_ldap.c source file must be compiled into a dynamic connection library file mod_ldap.dll, which is then used by Apache to communicate with the LDAP database. The DLL file should be placed in the modules directory installed in Apache. Add necessary LDAP configuration information to the configuration file httpd. conf of the Apache Web server. You can add the following information at the end:
# LDAP authenticatin Module
Loadmodule ldap_module C:/Apache/modules/ldap_module.dll
Addmodule mod_ldap.c
# We protect/Examples
　　
Authtype basic
Authname authenticationlable
Ldapauth on
Ldapserver "LDAP: // localhost: 389 /"
Ldapbindname uid = initiate, ou = people, Dc = Dhu, Dc = Edu, Dc = Cn
Ldapbindpass initial
Ldapuseridattr uid
Ldapbase Dc = Dhu, Dc = Edu, Dc = Cn
Ldapsearch modesubtree
Require valid-user
　　
If everything is normal, when a Web user accesses the application under the examples directory, a dialog box is displayed, asking the user name and password to be entered for verification. After the verification is successful, the JSP program under examples can run normally.
　　6 Summary
This article outlines some basic LDAP knowledge and discusses why LDAP is a feasible solution that can be used to handle security and personalization. The openness and distributed features of LDAP make it suitable for storing infrequently used data in distributed application systems.
It should be noted that security is a chain, and its strength is equal to its weakest chain ring. Correct implementation of an LDAP system is not a trivial task. The introduction to LDAP in this article is not enough to deploy a complete LDAP-based security system. However, this article will provide you with sufficient knowledge to use an existing LDAP implementation to design and deploy your web service system.
　　References:
[1] Gerald carter. LDAP system administration, o'reilly, 2003
[2] M. Wahl T. Howes. Lightweight Directory Access Protocol (V3). rfc2133, 1997
[3] Lu Kening, Zhou huiyong. Research and Implementation of directory service. School of Electronic Information Engineering, Tianjin University
[4] Henry bequet, translated by Wei Haiping. Java soap programming guide. E-Industry Press, 2002

This article is transferred from
Http://www.jsjlw.cn/(igtcdyrzsppnyj550t0dht55)/n1128c13. aspx