Pages

Saturday, March 3, 2012

LDAP


LDAP use cases and alternatives
**LDAP (Lightweight Directory Access Protocol):**

LDAP is a protocol used for accessing and maintaining directory services. It is commonly employed for managing user authentication, authorization, and information lookup in various applications. Here are some use cases of LDAP:

1. **User Authentication:**
   - LDAP is widely used for authenticating users against a centralized directory. This is common in environments where a single sign-on (SSO) solution is desired, allowing users to use one set of credentials across multiple services.

2. **User Authorization:**
   - LDAP directories store information about user roles, group memberships, and permissions. This data is used for access control decisions, allowing or restricting user access to specific resources or services.

3. **Address Book and Contact Information:**
   - LDAP directories are often used as global address books within organizations. They store contact information, email addresses, and other details, facilitating easy access to this information by users.

4. **Device Management:**
   - LDAP can be used to store information about network devices, such as printers, routers, and servers. This facilitates centralized management and monitoring of devices in a network.

5. **Certificate Authority (CA) Information:**
   - LDAP can store information related to digital certificates and Public Key Infrastructure (PKI). This is particularly relevant in scenarios where certificate information needs to be looked up or managed centrally.

6. **Web Single Sign-On (SSO):**
   - LDAP is often used in conjunction with protocols like SAML or OAuth for web-based single sign-on. It allows users to authenticate once against the LDAP directory and access multiple web applications without re-entering credentials.

7. **Email Systems:**
   - LDAP is commonly used to store user account information for email systems. Email clients and servers can query LDAP directories to obtain information about users and their mail settings.

**Alternatives to LDAP:**

While LDAP is widely used, there are alternative technologies and protocols, each with its own strengths and use cases:

1. **Active Directory (AD):**
   - Active Directory is a Microsoft-developed directory service that includes LDAP among its protocols. It is commonly used in Windows environments for user authentication, authorization, and other directory-related services.

2. **OAuth and OpenID Connect:**
   - OAuth and OpenID Connect are protocols commonly used for modern web-based authentication and authorization. They provide a framework for secure identity delegation and authentication.

3. **SAML (Security Assertion Markup Language):**
   - SAML is an XML-based standard for exchanging authentication and authorization data. It is commonly used in Single Sign-On (SSO) scenarios, especially in web applications.

4. **Kerberos:**
   - Kerberos is a network authentication protocol that provides strong authentication for client-server applications. It is often used in conjunction with LDAP for secure authentication and access control.

5. **CAS (Central Authentication Service):**
   - CAS is a Single Sign-On protocol that authenticates users and provides them access to multiple applications without re-entering credentials. It is commonly used in academic and enterprise environments.

6. **Shibboleth:**
   - Shibboleth is an open-source project that provides Single Sign-On and attribute exchange based on SAML. It is widely used in higher education and research institutions.

The choice between LDAP and its alternatives depends on factors such as the specific use case, existing infrastructure, security requirements, and compatibility with other systems in the environment. Many organizations use a combination of these technologies to meet their diverse authentication and authorization needs.


LDAP, Lightweight Directory Access Protocol, is an Internet protocol that email and other programs use to look up information from a server.
The Lightweight Directory Access Protocol or LDAP is an application protocol for querying and modifying directory services running over TCP/IP.
A directory is a set of objects with similar attributes organized in a logical and hierarchical manner. The most common example is the telephone directory, which consists of a series of names (either of persons or organizations) organized alphabetically, with each name having an address and phone number attached.
An LDAP directory tree often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain name system (DNS) names for structuring the topmost levels of the hierarchy. Deeper inside the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else that represents a given tree entry (or multiple entries).

Protocol overview
A client starts an LDAP session by connecting to an LDAP server, by default on TCP port 389. The client then sends an operation request to the server, and the server sends responses in turn. With some exceptions, the client need not wait for a response before sending the next request, and the server may send the responses in any order.

The client may request the following operations:
  • Start TLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection
  • Bind — authenticate and specify LDAP protocol version
  • Search — search for and/or retrieve directory entries
  • Compare — test if a named entry contains a given attribute value
  • Add a new entry
  • Delete an entry
  • Modify an entry
  • Modify Distinguished Name (DN) — move or rename an entry
  • Abandon — abort a previous request
  • Extended Operation — generic operation used to define other operations
  • Unbind — close the connection (not the inverse of Bind)

A common alternate method of securing LDAP communication is using an SSL tunnel. This is denoted in LDAP URLs by using the URL scheme "ldaps". The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003.

 Directory structure
The protocol accesses LDAP directories, which follow the 1993 edition of the X.500 model:
  • A directory is a tree of directory entries.
  • An entry consists of a set of attributes.
  • An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below).
  • Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full filename and the RDN as a relative filename in a folder.
Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might be provided in the set of the entry's operational attributes.
An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (LDAP itself is a binary protocol):
 dn: cn=shiva kumar ,dc=pamplona5, dc=com
 cn: shiva
 given Name: shiva
 sn: kumar
 telephone Number: 123456
 telephone Number: 123456
 mail: shiva@pamplona5.com
 manager: cn=vasanth kumar, dc=pamplona5, dc=com
 ObjectClass: inetOrgPerson
 ObjectClass: organizational Person
 objectClass: person
 ObjectClass: top
dn is the name of the entry; it's not an attribute nor part of the entry. "cn= shiva kumar" is the entry's RDN, and "dc=pamplona5,dc=com" is the DN of the parent entry, where dc denotes Domain Component. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.
A server holds a subtree starting from a specific entry, e.g. "dc= pamplona5, dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=department, dc=pamplona5, dc=com" could return a referral or continuation reference to a server which holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.

LDAP rarely defines any ordering: The server may return the values of an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions - an entry is defined as a set of attributes, and an attribute is a set of values, and sets need not be ordered.

Bind (authenticate)

The Bind operation authenticates the client to the server. Simple Bind can send the user's DN and password in plaintext, so the connection should be protected using Transport Layer Security (TLS). The server typically checks the password against the user Password attribute in the named entry. Anonymous Bind (with empty DN and password) resets the connection to the anonymous state. SASL (Simple Authentication and Security Layer) Bind provides authentication services through a wide range of mechanisms, e.g. Kerberos or the client certificate sent to TLS.
Bind also sets the LDAP protocol version. Normally clients should use LDAPv3, which is the default in the protocol but not always in LDAP libraries.
Bind had to be the first operation in a session in LDAPv2, but is not required in LDAPv3 (the current LDAP version).

Search and Compare

The Search operation is used to both searches for and read entries. Its parameters are:
base Object 
The DN (Distinguished Name) of the entry at which to start the search,
scope 
Base Object (search just the named entry, typically used to read one entry), singleLevel (entries immediately below the base DN), or wholeSubtree (the entire subtree starting at the base DN).
filter 
How to examine each entry in the scope. E.g. (&(objectClass=person)(|(givenName=shiva)(mail=shiva*))) - search for persons who either have given name John or an e-mail address starting with john.
derefAliases 
Whether and how to follow alias entries (entries which refer to other entries),
attributes 
Which attributes to return in result entries.
size Limit, timeLimit 
Max number of entries, and max search time.
types Only 
Return attribute types only, not attribute values.
The server returns the matching entries and maybe continuation references (in any order), followed by the final result with the result code.
The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains that attribute with that value. 

Update Data

Add, Delete, and Modify DN - all require the DN of the entry that is to be changed.
Modify takes a list of attributes to modify and the modifications to each: Delete the attribute or some values, add new values, or replace the current values with the new ones.
Add operations also can have additional attributes and values for those attributes.
Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag which says whether to delete the value(s) in the entry which match the old RDN. The server may support renaming of entire directory subtrees.
An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the meantime. Servers may implement extensions which support this, however.
Usage

Applications

One reason to choose LDAP for a service is that it is quite widely supported, and data presented in LDAP is thus immediately available to many clients and libraries including web applications like Joomla & PHPBB. Another is that LDAP is very general and includes basic security, and can support many types of applications.
Thus, if one chooses a few general protocols like LDAP and HTTP for various services, one can focus on these few protocols instead of having to maintain and upgrade many specialized protocols.
Two common applications of LDAP are for computer user/group data, and for address book information (persons, departments etc). Many e-mail clients support LDAP lookups.
Tasks LDAP does not handle well include modeling relational databases and preserving the order of data. (However, an extension does exist for the latter.)

Naming structure

Since an LDAP server can return referrals to other servers for requests the server itself will not/can not serve, a naming structure for LDAP entries is needed so one can find a server holding a given DN. Since such a structure already exists in the Domain name system (DNS), servers' top level names often mimic DNS names.
If an organization has domain name test.example, its top level LDAP entry will therefore typically have the DN dc=test,dc=example (where dc means domain component). If the LDAP server is also named ldap.test.example, the organization's top-level LDAP URL becomes ldap://ldap.test.example/dc=test,dc=example.
Below the top level, the entry names will typically reflect the organization's internal structure or need rather than DNS names. This is also a descendant of the X.500 series. ..
Terminology
The LDAP terminology one can encounter is rather cumbersome. Some of this is due to misunderstandings, other examples are due to its historical origins, others arise when used with non-X.500 services that use different terminology. For example, "LDAP" is sometimes used to refer to the protocol, other times to the protocol and the data. An "LDAP directory" may be the data or also the access point. An "attribute" may be the attribute type, or the contents of an attribute in a directory, or an attribute description (an attribute type with options). An "anonymous" and an "unauthenticated" Bind are different Bind methods that both produce anonymous authentication state, so both terms are being used for both variants. The "uid" attribute should hold usernames rather than numeric user IDs.

Types of LDAP Servers:-


Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)