LDAP

  

LDAP is a simplified front end to the X.500 Directory Access Protocol. LDAP reduces the complexity of using X.500 directory services and extends the services from a client and server perspective. Some of the communications that were established between the client and server are defined as an SDK. The LDAP SDK establishes secure transactions between the client and server. In early versions of LDAP, many client-side SDKs were developed to talk to previously defined X.500 servers.

The preliminary LDAP SDK that most LDAP services used as a starting point was the OpenLDAP implementation from the University of Michigan. The LDAP SDK requires that the client authenticate itself before accessing any of the services in the LDAP server. Other noticeable differences were the structure of the internal tables to search not only from top to bottom, but from bottom to top. Other enhancements to the internal tables included global searches, virtual views of a tree, and sorting on a path in the tree. The client differences also included transactional actions, such as rollbacks and commits to be performed on objects.

A lot of these enhancements are very database centric. The X.500 was too OSI network oriented, and it was not optimized for a data store and secure client/server implementation. LDAP decreased the processing time of an X.500 to only 10% of what it was by applying database techniques on top of the network techniques. Searching and sorting the tree was optimized to follow the X.500 schema. LDAP servers are enhanced to follow the X.500 schema, and for that reason they are the mechanism for storing certificates preferred by most certificate vendors .

If a relational database is to be used with the X.500, a lot of the LDAP functionality for managing the certificates will have to be replicated in the database. The X.500 schema is not only recommended for certificates, but it follows most security models in an organization's enterprise. An ACL system, permission system, or any object entry system could easily follow the X.500 schema. The schema also centralizes security information into one central directory for an entire organization. Because it is not directory specific, LDAP has also found its way into various environments, enhancing its interoperability. The LDAP SDK provides a rich API for interfacing into an LDAP server and client.

Many organizations still do not find a need to use LDAP and use relational databases instead to organize security data. This creates a proprietary implementation to an organization that will not communicate with the LDAP SDK. Using a custom implementation inside a Relational Database Management System (RDBMS) sometimes limits the applications that organizations can use. Some LDAP servers are becoming more and more tightly coupled to the LDAP SDK. If an organization is ever planning to use protocols or services that are tightly coupled to LDAP, it would be far cheaper to buy an LDAP server than to try to re-invent all of its functionality in an RDBMS. Some developers see building an LDAP server as an intellectual challenge. From an organizational perspective, building an RDBMS to simulate LDAP services could be very costly in maintenance alone.

As mentioned earlier in this section, the LDAP service provides its own authentication mechanisms through its SDK. The authentication types can be anonymous, simple, none, and SASL. SASL is the most secure, and it stands for Simple Authentication and Security Layer. RFC 2222 defines SASL ( http://www.ietf.org/rfc/rfc2222.txt ). LDAP uses this protocol to identify and authenticate a user in the server. The SDK's connection to the LDAP server requires a principal, credentials, and the SASL authentication type.

When the LDAP client tries to authenticate the server, the LDAP server can challenge the authentication. The LDAP client sends responses to the LDAP server, which can challenge as many times as it deems necessary. If the authentication succeeds, it will get a SUCCESS message, otherwise the client will receive an INVALID CREDENTIALS error. SASL is part of the JAAS product and further information can be found in the javax.security.sasl package. If all client and security information is stored in an LDAP server, the LDAP server and SASL protocol can be used as a central choke point for accessing this information. Using LDAP and SASL to handle most of the security namespaces can also limit the information that the development and production teams need to understand and contain the technological scope.

Some of the benefits of the LDAP server are the ability to manage the X.500 schema from an administrative console. The X.500 can manage a group by changing a node on a tree. To accomplish the same task in a RDBMS schema representation would require SQL database calls. The administration console that manages the groups and users is not built in the RDBMS; administration consoles are, however, built-in through an interactive tool like the LDAP administrative console of an LDAP server. Figures 25-6 and 25-7 demonstrate some of the out-of-the-box consoles in the Netscape Directory Server 5.1.

click to expand
Figure 25-6: Netscape Directory Server 5.1 Users and Groups console
click to expand
Figure 25-7: User console for the Netscape Directory Server 5.1

Looking at Figures 25-6 and 25-7, you may notice that there is a lot of predefined management information for security that comes out of the box from the Netscape Directory Server 5.1. To replicate the same amount of GUI interaction an X.500 schema requires a lot of work and maintenance. Using the out-of-the-box functionality of a Directory Service provides the out-of-the-box functionality of a Certificate Store. The Certificate Store is used to store certificates in the organization.

  


Java Security Solutions
Java Security Solutions
ISBN: 0764549286
EAN: 2147483647
Year: 2001
Pages: 222

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net