Why ISP's need LDAP.
What is a LDAP?
LDAP is the Internet protocol for accessing a directory. LDAP also defines the "information model" of the directory being accessed. The core of this is very simple:
* It is hierarchical, with directory entries arranged in a "tree".
* Entries contain typed attributes, such as "phone number" or "email address",
* Entries represent objects that have a defined type such as "Organization" or "Person". This type is known as the "object class", which is itself represented as a special attribute of the entry.
* Entries are named relative to their parent entry using a special attribute known as the "Relative Distinguished Name". This allows a flexible approach to naming objects. For example:
* A hierarchy such as "Country=GB", "Organization=Isode", "Role=CEO".
* A hierarchy representing an Internet domain, such as isode.com represented by "Domain Component=com", "Domain Component=isode".
* A core schema, comprising a set of attribute types and object classes, is defined by LDAP. This helps ensure that disparate LDAP users build directories with a common core.
* The LDAP Schema is easily extensible, so users can add information to core objects or create new objects as needed. The two really important things about LDAP are that it has a flexible and extensible information model, meaning that an LDAP directory is a good database for holding information about a range of generic objects, and that its inherent structure makes it straightforward to build a distributed directory, using the hierarchy of the directory to distribute data into different servers.
There are two further characteristics which are key for ISPs. These are not inherent to LDAP, but are central features of any high quality LDAP product, including lsode's M-Vault that an ISP should consider:
1. An LDAP server is a fast, efficient and sealable way to store, manage, search and retrieve data on lots of moderately complex objects.
2. Data in an LDAP server can be efficiently replicated, so that multiple servers can participate in providing an LDAP service.
Customer and Account Data
While LDAP can be used for many purposes, the primary ISP use is to hold information on customer accounts. This paper will focus on this usage. For each customer, an ISP needs to manage a range of "front end" data that is needed by the services and applications that the ISP provides to the customer. Examples of this are:
* Account name.
* Information on services subscribed to by customer (explicit or implicit).
* Authentication information (e.g., password information), so that services can authenticate the customer.
* Electronic contact information (e.g., email address; instant messaging addresses).
* Parameters needed by the services (e.g., quota for a Web service).
This is straightforward information. In a real deployment, the amount of information needed per account might be 50 or 100 attributes. An LDAP directory is an ideal reposito for this type of data. The core LDAP schema provides for many of the attributes that are typically needed. LDAP's . schema extensibility makes it straightforward to extend to core, to include any additional information needed.
It is also straightforward to extend schema in an operation directory, which is important when ISPs add in new applications with additional data requirements. For some database technologies, changing the schema in an operational system has significant operational implicatication A typical ISP application will use account data in two
An LDAP Directory can be used to authenticate the user shown above, Central authentication is important, as it allows a customer to have a single password and to chan it in one place for all applications. An application will achieve this by:
* Searching the directory using the supplied account nan in order to identify a single account.
* Binding to the directory, using this identified name, in order to verify the supplied credentials.
Obtaining application configuration information
Obtaining necessary per application configuration information needed by the application to operate. The application can use the established connection to the directory in order to obtain this information. The diagram above shows how a mail system running on multiple servers can use the LDAP directory to verify, route and deliver email.
ISP customers will do this every time an application is run or a message routed, and so lookup volumes are high. The next section describes why LDAP is particularly well suited to support this usage.
Why LDAP is good for accessing Customer and Account Data
There are a number of reasons why LDAP is a good choice for this application:
A good LDAP server will be well optimized for this type of operation, where there are likely to be high volumes of lookups. For small deployments, this will lead to efficient use of system resources. For very large deployments, LDAP is likely to be the best or only viable option.
Good LDAP servers can be efficiently replicated. This means that an LDAP solution is straightforward to deploy over multiple locations, it also means that is has good "horizontal scaling", and it is straightforward to increase throughput simply by adding more replica servers.
LDAP Schema extensibility makes it easy to add in new applications and to update the capabilities of existing ones. Good application support. Many products and open source solutions designed for ISP deployment, such as Radius servers and Messaging servers have built in LDAP support, and so use of LDAP simplifies application integration. Authentication systems, such as PKI (Public Key Infrastructure) generally use LDAP for information storage. Using LDAP enables ISPs to efficiently integrate and make use of external authentication technologies.
Accounting Data and Provisioning
The description so far has focused on "front end" data, which is needed by applications and ISP services. ISPs also need to maintain "back end" data associated with each customer, typically related to billing and accounting. ISPs are advised to manage this data separately, as:
* No single system is well optimized for both tasks. While customer billing data could be held in an LDAP server, it is not a good choice; While an accounting system could be used to hold Radius and FTP information, it is not designed to provide application access to this information.
* It makes sense to keep the back end data well protected, as it will contain business critical information, and customer payment data. Front end data must be accessed by many services, and is less sensitive. Therefore it makes sense to use separate systems.
As part of the ISP's provisioning system, customers and operators will need to access both front end and back end data, from a common interface, which will generally be a Web front end. There are two basic approaches that an ISP can take:
Drive everything through the back end system (see diagram above). In this model, provisioning is completely associated with the back end system, and all customer parameters and managed information are stored there. The LDAP directory is "loaded" from the back end system, and effectively acts as a high performance replicated mechanism for applications to access necessary data.
* Integrated management (see diagram above), in this model, there will just be a single key that relates front end and back end account information. When accounts are created and deleted, the LDAP Directory and back end system will be managed in parallel. Data is stored in the 'right' place. This approach has the advantage of not duplicating information in the back end system, at the expense of a slightly more complex overall structure.
What does an ISP Need from an LDAP Server?
The paper so far has looked at the reasons an ISP would use an LDAP server, and why LDAP servers are a good choice. This section looks at features which an ISP should look for in an LDAP server:
* Scaling and Performance. This is critical for ISP deployments, and should be verified carefully.
* Replication. A good managed and efficient approach to data replication. It is important to verify that replication scales as well as the core server.
* Management tools. An appropriate set of graphical and scripting tools should be available.
* Online backup. ISPs will need to back up directory servers, without taking them offline. This backup should be appropriate for disaster recovery.
* Schema propagation. An ISP will generally make schema changes infrequently. The changes will typically be designed carefully on a test system. It is important that it is easy to update operational servers with new schema.
* Delegated administration. An access control schema, which enables the ISP to delegate management of portions of the DIT, can be useful where the ISP offers managed services.
* Appropriate character set support, for the target customer base.
* Support for storing X.509 certificates is necessary if PKI (Public Key Infrastructure) services are needed.
|Printer friendly Cite/link Email Feedback|
|Publication:||Database and Network Journal|
|Date:||Dec 1, 2005|
|Previous Article:||4c v 3.0s. Next generation preview technology.|
|Next Article:||MP3 players causing mayhem for company IT.|