LDAP Intro

LDAP is standardized. The body of LDAP standards, including the network protocols, the directory structure, and the services provided by an LDAP server, are all available in the form of RFCs (Requests For Comments).

LDAP was designed to be a general-purpose directory server. It has not been designed with the purpose of capturing a specific type of data (like telephone numbers or email addresses). Instead, it was designed to give implementers the ability to define—clearly and carefully—what data the directory should store.

Such a generic directory server ought to be able to store many different kinds of information.

Let's continue with our comparison of a directory server and a phone book. A phone book contains a very specific type of information, organized in a very specific way, and designed to fulfil a very specific purpose. Here's an example phone book entry:

Acme Services
123 W. First St.
Chicago, IL 60616-1234
(773) 555-8943 or (800) 555 9834

As mentioned earlier, this sort of directory has specific information, organized in a specific way, designed to fulfill a specific purpose: it is information about how to contact a specific organization (Acme Services) organized in a familiar pattern (address and phone number). And it is designed so that a person, having a particular name in mind, can quickly scan through the directory (which is ordered alphabetically by organization name), and find the desired contact information.

But there are a few things to note about the phone book entry:

* The data is arranged for searching by only one value: the name of the organization. If you should happen to have the phone number of the organization, but not the name, searching the phone book for the matching telephone number in order to ascertain the name would be a taxing, and probably futile task.
* The format of the entry is sparse, and requires that the reader will be able to recognize the format and supply auxiliary information required for making sense of the data. One accustomed to reading phone book entries will be able to extrapolate from the previous entry, and identify the information this way:

Organization Name: Acme Services
Street Address: 123 West First Street
City: Chicago
State: Illinois
Postal Code: 60616-1234
Country: USA
Phone Number: +1 773 555 8943
Phone Number: +1 800 555 9834

In this example, the meaning of the information is made more explicit. Each value is preceded by a name that identifies the type of information given. Acme Services is now identified as the name of an organization. Information is also broken up into smaller chunks (city and state on separate lines), and some information which was implicit in the previous entry (such as the country) has been made explicit. And where two pieces of information (the two phone numbers) were initially compressed onto one line, they have now been separated, making the information more explicit.

This form of entry is closer to the way a record would look in an LDAP directory. But there is still another issue to address. How can we distinguish between two very similar records?

For example, say we have a telephone directory for the entire state of Illinois. And in Illinois, we have a company called Acme Services located in the city of Chicago, and another company named Acme Services located in the city of Springfield.

Simply knowing the company name alone is not sufficient information to isolate just one entry in the phone book. To do that, we would need some sort of unique name—a name that exists only once in the entire directory, and which can be used to refer to one specific entry.

A Unique Name: The DN
One way of distinguishing between two very similar records is to create a unique name for each record in the directory. This is the strategy adopted by LDAP; each record in the directory has a distinguished name. The distinguished name is an important LDAP term; usually it is abbreviated as DN.

In an LDAP directory, the directory designer is the one who decides what components will make up a DN, but typically the DN reflects where the record is in the directory (a concept we will examine in the next part), as well as some information that distinguishes this record from other near records.

A DN then, is composed of a combination of directory information, and looks something like this:

dn: o=Acme Services, l=Chicago, st=Illinois, c=US

This single identifier is sufficient to pick it out from the Springfield company by the same name. The DN of the Springfield company named Acme Services would, according to the previous scheme, look something like this:

dn: o=Acme Services, l=Springfield, st=Illinois, c=US

Some parts of LDAP records are case sensitive, and others are not. DNs, for example, are not case sensitive.

Let's take a specific look at what an LDAP entry looks like.

A LDAP entry is composed of a DN and one or more attributes. The DN serves as a unique identifier within an LDAP directory information tree. Attributes provide information about that entry. Let's convert our previous telephone directory entry into an LDAP record:

dn: o=Acme Services, l=Chicago, st=Illinois, c=US
o: Acme Services
postalAddress: 123 West First Street
l: Chicago
st: Illinois
postalCode: 60616-1234
c: US
telephoneNumber: +1 773 555 8943
telephoneNumber: +1 800 555 9834
objectclass: organization

The first line is the DN. All other lines in this record represent attributes.

These attribute names, like o and postalAddress, refer to well-defined attribute definitions contained in an LDAP schema. They cannot be "invented" on the fly, or made up as you go. Creating new attributes requires writing a schema.

An attribute describes a specific type of information. There are eight attributes here in our example, representing the following:

1. Organization Name (o)
2. Mailing address (postalAddress)
3. Locality (l), which may be the name of a city, town, village, and so forth
4. State or Province (st)
5. Postal Code or ZIP Code (postalCode)
6. Country (c)
7. Telephone Number (telephoneNumber)
8. Object Class (objectclass), which specifies what type (or types) of record this entry is

An attribute may have one or more attribute names, where these names are synonyms. For example c and countryName are both names for the attribute type that identify a country. Both identify the same information, and LDAP will treat the two names as describing the same type of information.

In any given record, an attribute may have one or more values (assuming the attribute's definition allows more than one value). The record above has only one attribute that contains more than one value. The telephoneNumber attribute has two values, each representing a different phone number.

Attribute names are not case sensitive. The attribute name o is treated as synonymous with the name O. Likewise, GivenName, givenname, and givenName are all evaluated as the same attribute name.

As for the values of attributes, case sensitivity depends on the attribute definition. For example, the values of DNs and objectclass attributes are not case sensitive, but a URI (labeledURI) attribute value is case sensitive.

The Object Class Attribute

The last attribute in the given record is the objectclass attribute. This is a special attribute that provides information about what type of record (or entry) this is.

An object class determines what attributes may be given to a record.

ADF security

Whenever one enables the security in an ADF web application one must always cross verify if jdev has generated "adf-config.xml" in the folder "web-project/.adf/META-INF"

from the docs "To enable Oracle ADF Security authorization, you create a configuration file named adf-config.xml that sets the application's container to use Oracle ADF Security. The file initializes the ADFContext and SecurityContext."

more details of ADF xml can be found here.