Embed Size (px)
Citation preview
User Management In Distributed Systems
Studienarbeit von
Nguyen-Thinh Le
Tel. 0177-7374359Email: [email protected]
vorgelegt am 06.12.1999 bei
Prof. Dr. Winfried LamersdorfArbeitsgruppe Verteilte Systeme
Fachbereich InformatikUniversität Hamburg
1. The problem of a decentralised user management system........................................3
2. LDAP – Lightweight Directory Access Protocol......................................................5
2.1. A brief history of LDAP........................................................................................52.2. Introducing the Lightweight Directory Access Protocol.......................................6
2.2.1. LDAP - The Data Model..............................................................................72.2.1.1 Data hierarchy...........................................................................................72.2.1.3 Object classes............................................................................................92.2.1.4 Attributes.................................................................................................102.2.1.5 Distinguished Names...............................................................................112.2.1.6 Schemas...................................................................................................12
2.2.2. LDAP: The Protocol....................................................................................122.2.2.1 LDAP Operations....................................................................................132.2.2.2 Other Protocol Services...........................................................................15
2.2.3. LDAP: The APIs.........................................................................................16
3 Java Naming and Directory Interfaces....................................................................18
3.1 JNDI Overview....................................................................................................183.2 JNDI Architecture...............................................................................................183.3 Naming Service versus Directory Service...........................................................193.4 JNDI Class Structure...........................................................................................19
3.4.1 javax.naming...............................................................................................203.4.2 javax.naming.directory................................................................................21
3.5 Operating JNDI...................................................................................................213.5.1 Binding........................................................................................................223.5.2 Searching an LDAP Server.........................................................................233.5.3 LDAP Server Modifications........................................................................27
3.5.3.1 Adding Entries.........................................................................................273.5.3.2 Modifying Entries....................................................................................283.5.3.3 Deleting Entries.......................................................................................29
4 User Management In Distributed Systems..............................................................30
4.1 Formulation of the problem.................................................................................304.2 Securing LDAP...................................................................................................30
4.2.1 Access Control Lists....................................................................................304.2.2 LDAP for Authentication............................................................................32
4.3 User management with LDAP.............................................................................324.3.1 Designing LDAP Tree.................................................................................334.3.2 Vision..........................................................................................................36
5 Implementing User Interfaces.................................................................................37
5.1 The First User Interface: Servlet Authentication.................................................375.2 The Second User Interface: Changing Password Servlet....................................40
6 Summary..................................................................................................................41
Bibliography....................................................................................................................41
2
1. The problem of a decentralised user management system
As a student of University Hamburg we can get an account to access computers of the computer labor. The first time we work with Unix workstations we have to think up a password. The same we have to do when we want to work with PC or Macintosh on Novell network at the first time. Of course, we can think up for the Novell network the same one we use for the Unix workstations. But they are different. After a set time interval we are required to change our password on the Novell network. So we have to remember two distinct passwords. Have you ever complained about that?
Imagine we work in a company with an Intranet that provides many services for certain groups of employees. So people have to authorise themselves before they want to access to these services. In addition to the two user information databases above there is another one for Intranet. This company could have some offices located anywhere on the globe. The users of these offices are allowed to communicate using the Internet as a Virtual Private Network or VPN. The VPN will require that all traffic will be encrypted and secured using user ID and passwords and client-side certificates. Now the administration of networking would be complex, because to get everyone access to the VPN will require all system administrators to issue user IDs and passwords to the jerk in the other locations and that they themselves will have to manage the certificate database somehow.
The life of network users and network administrators would be easier if there were a central directory service that manages the user information. Anyone wants to access to the network he has to type his user ID and password, all the Novell, Unix or Microsoft systems draw his user ID and password from the central directory service. He has separate rights on each system, but the base authentication scheme is centralised. The directory server also manages his client-certificate, so that when someone must work on the VPN to the other offices, he is able to do so. The session are encrypted and trusted.
Following is the list of some benefits of a centralised directory service that Mark Wilcox concerned in his book “Implementing LDAP” 1 :
o Entry and management of personal data, such as name and address, is centralised. This information is entered and stored in one place.
o Information on user ID and password locations for computer systems is centralised. This way, security is improved because users only have to worry about one set of user Ids and passwords. This makes it easier to create a strong password, because they only need to remember one.
o The procedure for determining the status and role of an individual in the organisation is standardised. In a large organisation, there will be a number of people that will come and go. It is important to determine the exact status or relationship to the company they represent. This is important for business and security purposes, because employees and guests are not likely to have the same access rights to all areas of the organisation.
o Lookup of names, address, and phone numbers is standardised. Employees need to contact each other for a variety of reasons. In a large organisation, the numbers can be in the thousands. The means of contacting an individual a numerous too-
1 Wilcox, Mark: Implementing LDAP, Wrox Press Ltd. 1999, p.24, 25.
3
telephone, fax, email. This information will change over time, so centralising the management of it makes it easier to find people in the organisation. Effective communication is still one of the most efficient ways to run a company.
o Lookup of network resources like printers, servers, and certificates is standardised. Network resources are multiplying faster than people in an organisation. It is imperative that we have a way to manage all the network resources in a standardised fashion. Making it easier for users to find the resources will make them more productive and reduces the workload of network administrators. It also increases security and reliability, because you can keep tabs on the status of all of your devices.
o Management of the system is distributed. Centralising the management of the system will increase reliability and make it easier to keep it up to date. However, the type of information a directory system keeps is very fluid, that is, it changes constantly. To help keep the information current, it is important that the people who are closest to the source of information be given the ability to keep it up to date. By having all systems draw their information from a centralised resource will make it easier to encourage people to use the system, instead of trying to maintain their own separate systems. So, the data itself is centralised, but that management of that data can be distributed.
The best possible solution to our current information problems is through a centralised directory service with a standardised mechanism. The standardised solution should meet some basic goals:
o Multi-Platform – Most organisations have multiple-platforms in use. The platforms we would want to reach would include all versions of Windows, Apple Macintosh, Linux/Unix and IBM mainframes.
o Multi-Vendor support – Multi-vendor support is important because it can help keep prices low and also lessens the blow if a vendor should go out of business.
o Common standard –It should be a known standard and recognised by many others as a standard (i.e. ANSI/ISO recognition)
When we are talking about standards, it is important to realise that there are a variety of ways a standard can be generated. Essentially there are two types of standard:
o Vendor-derivedo Open
In this work we will learn a directory services solution that fulfil the open standards and answer all our issues, LDAP – the Lightweight Directory Access Protocol.
4
2. LDAP – Lightweight Directory Access Protocol
2.1. A brief history of LDAP
The idea behind an open standards based directory service is not new. The first attempt was called X.500, the Directory Access Protocol (DAP). This technology was proposed by the International Telecommunications Union (ITU), which is another international group like the IETF. The ITU prefers to use the OSI communications stack as opposed to the TCP/IP communications stack that the Internet runs on.
DAP is divided into five basic functions:
o The data modelo The name space o The modes of operationo Authentication frameworko Distributed access methods
The data model is one made up of records called entries that have data fields called attributes. Each attribute in an entry is of a particular type and can contain one or more values. Each attribute has a particular syntax for data entry, in either text or binary format.
The namespace is the mechanism used to access the data contained in an X.500 server. The namespace allows us to import data into an X.500 system so that each entry is unique. The key to this strategy is the concept of the Distinguished Name (DN), which is made up of attributes of the entry. The namespace is divided up into a hierarchy, so that the relationships of one entry can be compared to another.
The modes of operation define what actions we can perform against an X.500 server. These operations would be in the form of a bind (which is like authenticating to the server), a search, a comparison of entries, modification of an entry, the addition of an entry and the removal of an entry.
The authentication framework helps define how clients should be able to identify themselves to the server, which helps determine what kind of access the client has. For obvious reasons, you would want to allow anyone to search the directory.
X.500 shows a lot of promise. It gives us a global namespace, a platform and data-independent way of describing our directory information. . This is very important, as the computing world we live in is not a homogenous one. X.500 is also an open based standard, agreed by many companies and countries in the world, and has been proven to work over the past decade, so X.500 has had a good run. Unfortunately, it runs on the OSI communications stack, which is hard to implement, especially on standard PCs and Macintoshes that make up the majority of the networking infrastructure. However, OSI is not the most widespread communication model.
As we know, TCP/IP runs on just about anything, which is why the Internet is everywhere. Also the necessary technical expertise for managing OSI networks was not that widely distributed because OSI was found mostly in Europe and the US
5
government. In contrast, TCP/IP networks were very common in academic institutions. In addition, building directory services is a difficult job, even if we do have a standard network to build on.
After the difficulty of implementing X.500 was realised, some people at the University of Michigan looked into ways of improving the situation. This came at a time, when the Internet was beginning to make ist transformation from academia to the world at large. They came up with an intermediary protocol – the Lightweight Directory Access Protocol, or LDAP.
LDAP was not originally designed to be the directory service itself, but rather to act as a gateway protocol to a directory service underneath. The first directory service chosen was X.500, because that was the most common directory service for the world-wide network community. Because X.500 servers did got gain that large of a foothold even with the invention of LDAP, the University of Michigan developers decided to put a database back-end with LDAP so that a LDAP server itself could act as a directory service. The first version to be widely used was LDAP version 2, which was specified in RFC2 1777 in 1995.
LDAP has continued to develop and mature. In December of 1997, RFC 2252, which specified version3 of the LDAP protocol, was ratified. Members participating included Sun, Netscape, Microsoft, Novell and Critical Angle (now Innsoft). The members of this group comprise the largest providers of networking operating systems, and employ all of the key members of the original LDAP implementation team. LDAP version 3 has now made it possible to give us the power we need to finally synchronise all of our networking and directory information into a manageable system.
2.2. Introducing the Lightweight Directory Access Protocol
Actually, LDAP means many different things. We can summarise as following :
Parts of LDAP Description
The Data Model
The Protocol
The API
Defines how the directory information is stored and recalled.
Defines how clients and servers interact with each other.
Defines how to programs that can interact with an LDAP server.
Before we break into the components of LDAP, we have to be acquainted with the terminology.
2 RFC stands for “Request For Comment”. RFCs provide a way towards the standardization of Internet protocols. Standardization is achieved only after rigorous reviewing and multiple interoperable implementations. However, some widely used protocols are only detailed in RFCs and yet are they not official standards. In fact, there are relatively few protocols that have made it right the way through the standards process. An RFC can be viewed as a de facto standard of sorts. The web address for RFC 2252 is : http://.ietf.org/rfc/rfc2252.txt
6
One of the terms we will work with all the time is an entry. An entry is what we call a record in the LDAP server. It is akin to record in a traditional database. An LDAP entry can also be called an object or an object entry.
A LDAP entry is made up of attributes. Attributes are divided into name/value(s) pairs. These attributes are similar to fields in a traditional database. An attribute will only have one name, but it can have more than one value. The values of an attribute can be either text or binary, depending upon the definition of the attribute.
Each entry is uniquely identified by it’s distinguished name (DN). The DN is made up of components, each of which is called a relative distinguished name (RDN). The components that make up the RDN are taken from attributes in the entry. We will see an example of a DN later.
Object classes determine what attributes are available to an entry. They are akin to tables in traditional databases. However, object classes differ from traditional database tables in that they are extensible. What this means that if we can have an object class that allows a set of attributes (such as last name, email address, etc.) and we want to add extra attributes to this object class, we can declare a new object class that extends from the earlier one. This new object class would have the ability to recognise the older object class’s attributes as well as the new ones we added.
Each server will have a schema. The schema is the blueprint of the server and it specifies all of the object classes and attributes that are available to be searched and stored in an LDAP server.
The directory service is accessed like a tree and is referred to as a Directory Information Tree (DIT). The directory server itself is called a Directory Service Agent (DAS). But normally some books prefer the terms “directory server” or “LDAP server”.
2.2.1. LDAP - The Data Model
2.2.1.1. Data hierarchy
The data in an LDAP server is organised in a hierarchical format. Every entry in the server, apart form the root entry, is below another entry. For example, the organisation structure of the department of computer science of University Hamburg can be illustrated as a hierarchy below .
In LDAP, the top level is called the domain. There can be several domains in an LDAP implementation. This is because, like X.500, LDAP is designed to help provide a global directory service. Typically, the top-level domain will just be the root of the organisation(s) that a particular company manages.
The branches are in the form of organisational units, which are usually departments in an organisation, but can be any convenient sub-division of that organisation. Each entry that is not a domain and not an organisational unit is called a leaf.
Domains, organisational units and every other type of information that is contained in the LDAP server must have a unique entry, and these entries must be a member of a particular object class.
7
2.2.1.2. Objects and object types
LDAP entries are like records in a traditional database. An entry is treated as an object. In the programming world, we refer to objects as having data and methods that act on the data. For LDAP however, we are only concerned with the data. Each object has one or more attributes, which are in form of name and value. Each attribute can have one or more values. The object paradigm was chosen because it allows any form of data to be stored in an LDAP server. Also, objects can be extended without having to be completely redefined.
When we need to reference one object from another, we must name the object. We name an object because we must have a way to refer to that object when we are talking about it. Each object will have a unique name called a Distinguished Name (DN), that will be different from any other name in the entire LDAP tree (which could span the entire world).
An example for an entry that represents a person might look something like the following:
dn: udi=NLe, ou=Students, ou=VSYS, ou=People, o=informatik.uni-hamburg.decn: Nguyen-Thinh Lesn: Legivenname: Nguyen-ThinhobjectClass: topobjectClass: personobjectClass: organizationalPersonobjectClass: intOrgPersonou: Studentsuid: NLemail: [email protected]: 0049 177 7374359
8
O = informatik.uni-hamburg.de
ou = People ou = Ressource
ou = VSYS ou = KOGS
ou = Assistants
uid=Frank
ou = SWT
ou = Students
uid=Thinh
The attribute dn above stands for Distinguished Name and is the identify of the entry throughout the directory tree. Others attributes will be explained later in the next sections.
There are four LDAP objects types that are in common used:
o Domain objectso Organisational Unit objectso Group objectso Person objects
Domain objects are root level objects. These include the object class domainObject. They are called root level objects because they form the root of a Directory Information Tree and are the base of all Distinguished Names for entries contained in the server. These include the attributes of organisation, country, location and domain.
Organisational Unit objects are used to branch the directory information tree. We can identify an organisational unit by form such as “Accounting” or “Printers” or by function such “People” and “Groups”. Organisational units are defined by the object class organizationalUnit and by the attribute name of ou. The attribute ou is often included in object classes outside of organitionalUnit such as the inetOrgPerson class.
Group objects are objects which contain an attribute called uniquemember. This attribute contains one or more values that are distinguished names of member entries. Normally groups will be group of people but we can group any type of entry together, including other groups. The group object class is called groupOfUniqueMembers.
Person objects are records that are used to describe people in an organisation. They can take the form of organizationalPerson or InetOrgPerson. The following attributes are typically required in a person object:
o Full name (called common name or cn)o Last name (called surname or sn)o First name (called givenname)
They often include extra attributes like:
o User IDo Telephone numbero Fax numbero Locationo City
2.2.1.3. Object classes
Object classes define the types of attributes an entry can contain. Most object classes define a set of required and optional attributes. This attribute list represents both required and allowed data that we can store on the entry.
9
For example, if we define an entry to use the organizationalPerson object class, then the commonName (cn) and surname (sn) attributes are required for the entry . In addition, there is a fairly long list of attributes that you can optionally use on the entry. This list includes such descriptive attributes as telephoneNumber, uid, streetAddress, and userPassword.
Object classes can use inheritance to define the total list of attributes that are either required or allowed on the entry. This inheritance is defined in the form of an object class structure. The structure begins with objectClass top and proceeds through a series of object class definitions, each of which adds to the list of required or allowed attributes. An object class that is meant to be at a lower end of the structure cannot be placed on an entry until all of that object class’s antecedent object classes have also been defined on the entry.
For example, a person entry is usually defined with the following object class structure:
objectClass: topobjectClass: personobjectClass: organizationalPersonobjectClass: intOrgPerson
objectClass top is what allows additional object classes to be placed on the entry. ObjectClass person defines two required attributes (commonName and surname), and then a few optional attributes. Organizationalperson and inetOrgPerson, in turn, add more attributes to the list of optional attributes. Further, we can put inetOrgPerson on the entry, you must first put object classes top, person, and organizationalPerson on the entry.
2.2.1.4. Attributes
Attributes hold information about a specific descriptive aspect of the entry. Each attribute consists of an attribute type and one or more attribute values. The attribute type identifies the class of information given by that attribute (for example, telephone number). The attribute value is the particular instance of information appearing in that entry (for example, 0177-7374359).
Attributes generally have short, mnemonic names. For example, cn is the abbreviation for commonName.
Object class definitions usually contain at least one required attribute, and they always contain one or more optional attributes. If an object class requires an attribute, then we cannot add an entry using that object class to the directory unless the required attribute is also defined for the entry. Doing so results in an object class violation, and the add operation for the entry fails.
Optional attributes are attributes that we are allowed, but not required, to add to the directory entry. If we attempt to add an attribute to an entry that is neither required nor allowed according to the entry’s object class definition, then the directory server returns an object class violation.
The attributes contained in the sample entry for udi=Nle in the section 2.2.1.2 will be explained below:
10
Root Entry Record Meaning
dn: uid=Nle, ou=Students, ou=VSYS, ou=People, o=informatik.uni-hamburg.de
cn: Nguyen-Thinh Le
sn: Le
givenname: Nguyen-Thinh
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou:Students
uid: Nle
mail: [email protected]
telephonenumber: 0049 177 7374359
Distinguished Name
Common Name
Surname (last name)
Given name (first name)
Object class of type top
Object class of type person
Object class of type organizationalPerson
Object class of type inetOrgPerson
Organizational unit value of StudentsUser ID
E-mail address
Telephone number
Another kind of attributes are the operational attributes. They are defined for use by the server. These attributes are used by the server to perform special actions, on either the attribute or entire entry. For example, an operational attribute might let the server know that it should encode all userpassword attributes using the SHA-1 algorithm. Another example of an operational attribute is the modifytimestamp used to show the time when the entry was last updated.
The following attributes are maintained automatically by the server and are not modifiable by clients:
o CreatorsName – the distinguished name of the user who added this entry to the directory
o CreateTimestamp – the time this entry was added to the directoryo ModifiersName – the distinguished name of the user who last modified this
entryo ModifyTimestamp – the time this entry was last modifiedo SubschemaSubentry – the distinguished name of the subschema entry (or
subentry) which controls the schema for this entry
2.2.1.5. Distinguished Names
Just as a file path uniquely identifies a file within a file system, a directory entry is uniquely identified within the directory tree using a distinguished name (DN). A DN identifies the entry by using a series of comma-separated attributes and attribute values. However, the path specification for DNs is in reverse order from a traditional file system. That is, where a file system typically traces the path to the file from left to right
11
with the file’s actual name specified in the right-most component, and specifies the left-most component as being the actual directory object and the right-most value as being the directory root point.
Thus, a DN might be
udi=NLe, ou=Students, ou=VSYS, ou=People, o=informatik.uni-hamburg.de
This DN represents the entry named Nle in the subdirectory named Students, which is subdirectory of VSYS, which is again subdirectory of People in the directory named informatik.uni-hamburg.de.
The DN’s left-most value is known as the Relative Distinguished Name (RDN). Following this value are subsequent attributes that represent a branch point above the entry. The final, or the right-most, attribute represents the conceptual root point of the directory tree.
2.2.1.6. Schemas
A directory schema specifies, among other rules, the types of objects that a directory can have and the mandatory and optional attributes of each object type. The LDAP v3 defines a schema based on the X.500 standard for common objects found in the network, such as countries, localities, organizations, users/persons, groups, and devices. In the LDAP v3, the schema is available from the directory. That is, the schema is represented as entries in the directory, and its information as attributes of those entries.
The LDAP v3 specifies that each directory entry may contain an operational attribute that identifies its subschema subentry. A subschema subentry contains the schema definitions for the object classes and attribute type definitions used by entries in a particular part of the directory tree.
Every LDAP server must use a particular schema, which defines what attributes can be stored in what types of object. There is even kind of a ‘super-schema’ that the RFCs defined by describing what the basic LDAP object classes are and how they should be used. Every LDAP server supports this ‘super-schema’.
A basic LDAP schema defines:
o The server’s nameo The port(s) it operates ono The Directory Manager of the servero The root domain of the object tree that the server will reference.
2.2.2. LDAP: The Protocol
The extract below from RFC 2251 (the LDAP v3 standards track) explains the LDAP protocol model:
„The general model adopted by this protocol is one of clients performing protocol operations against servers. In this model, a client transmits a protocol request describing the operation to be performed to a server. The server is then responsible for performing the necessary operation(s) in the directory. Upon completion of the
12
operation(s), the server returns a response containing any results or errors to the requesting client.
In keeping with the goal of easing the costs associated with use of the directory, it is an objective of this protocol to minimize the complexity of clients so as to facilitate widespread deployment of applications capable of using the directory.“3
LDAP is a efficient protocol that is designed to put most of the work on the server. This makes it easier both to write less complex clients and to deal with the results. LDAP can be used in bandwidth limited environments, and multiple operations can share a single connection. Also LDAP data is primarily text based and text does not take up a great deal of space and is easily compressed. Each operation is considered to be unique unto itself. They just happen to use the single shared TCP connection.
When a client interacts with an LDAP server it goes through three basic steps:
1. Connects to the server2. Performs a series of operations with the server3. Disconnects from the server
2.2.2.1. LDAP Operations
LDAP defines six possible operations that can be performed:
Binding to the server Searching the server Compare entries and attributes Adding an entry to the server Modifying existing entries Removing an entry from the server
1. Binding to the server
Binding to the server is akin to authenticating to the server. It is not the same as connecting to the server. A bind must match a given entry in the server, in most cases this entry will be a personal entry. When we bind to the server, we are telling the server that all operations that occur over this connection will be performed as that particular user. We do have the option to not bind as a specific user, at which point the server will bind our connection as an anonymous user. All access rights to LDAP data is based upon how the connection is bound.
Many of the access controls to the data are based upon how a client is bound to the server. Access controls are special attributes that define how users can interact with LDAP data including searching, reading and modifying the data contained in a directory server. During a single connection, a client can bind and rebind several different times, while still maintaining a single open connection to the server. We might rebind if we need extra privileges (e.g. we might initially search as an anonymous user, but rebind to gain rights to modify or add a new entry). However, a client often binds once for a particular session and then disconnects.
3http://www.ietf.org/rfc/rfc2251.txt, download on 28th October 1999, page 4.
13
Most services providing directory lookup as their only option often bind as anonymous users. As with anonymous operations in many services, the options open to these clients are often severely limited because an anonymous user has fewer privileges.
Most servers provide for some form of anonymous searching, but modification of the server requires that a client be found as a non-anonymous entry in the database. In the current version of the protocol, we can specify granular control over the entries stored in the LDAP server, and so can cover access on a global or by entry status. For example, we can enable the directory server so that individuals can modify their passwords, but that only their department’s administrative assistants can change their addresses and phone numbers.
2. Searching the server
A key function of any directory service is the ability to look up information. LDAP provides a very sophisticated lookup operation in the form of its search functions and search filters.
Entries in the database are objects and objects have attributes with particular values. In order to search for a particular object, you can specify a value for one or more particular attributes. The search string we send to the server is called a search filter.
Shown below is an example filter where we are looking for all of the entries that are named Sam Carter: (cn=Sam Carter)
The cn stands for common name, which is basically an entry’s identity tag.
We can specify the search filter by using more than one attribute. For example:
(&(cn=*Carter)(|(ou=Engineering)(ou=Accounting)))
In the above line, the & means AND, | means OR, the * is the wildcard character, and ou is the attribute label for organizational unit. This search filter looks for all of the Carter’s that work in Engineering or Accounting.
If we wanted to look for all entries and not include a particular series, we would use something like: (&(!(cn=Sam Carter)) (cn=*Carter))
Here, we would be looking for anyone with the name of Carter, except Sam Carter. Note that the ! means NOT.
All search will return the distinguished name of the entry plus a series of attributes. A distinguished name, is the unique name of the entry in the LDAP server, and corresponds to the primary key in a relational database.
3. Compare entries and attributes
A compare tests to see if an attribute value specified in a search matched that of an attribute contained within a particular entry on the LDAP server. The compare succeeds if there is such a match and fails if there is not one.
14
4. Adding an entry to the server
When we add a new entry, we must tell the server what type of entry it will be by specifying its object class. These object classes have two kinds of attributes: required attributes, which must be present, and optional ‘allowed’ attributes. Any new entry must have all of the required attributes filled with values before the entry can be added. In order to execute the ‘add’ operation, the client must have permission to write to the server.
5. Modifying existing entries
When we make modifications to an existing entry, we have the option of adding an extra value to an attribute or replacing an existing value. To complete a modification, we supply the DN of the entry to the server along with all of the new or changed attributes. The server then carries out the operation (e.g. adds the new value, changes a value for an attribute or deletes an a value).
Alike the ‘add’ operation, modifications are dependent upon the current binding of the client having the requisite permissions to write to the server in a particular part of the server’s data tree. For example, the server administrator has the ability to make the server read-only, in which case it will not accept any entries. All servers have a entry called cn=directory Manager, and if a client is bound as this entry, then it can modify any record in the database.
6. Removing an entry from the server
Removing an entry is similar to modifying the database.
Removing an entry is as simple as supplying the server with the DN of the entry you want to remove and having the necessary rights to do so. The rights to remove of an entry should only be granted to a few unique entries, directory Administrators for example, in order to prevent accidental or malicious deletes.
2.2.2.2. Other Protocol Services
There are some other services that version 3 of the LDAP protocol defines:
o Referralo Replicationo Encryption / Security
1. Referral Service
Referrals are a redirection mechanism that your directory service returns when a directory client requests a directory entry that does not exist on the local server. The directory server determines whether a referral should be returned by comparing the DN of the requested directory object against the directory suffixes supported by the local server. If the DN does not match the supported suffixes, the directory server will return a referral.
15
For example, if a directory client requests the directory entry uid=bjensen, ou=people, o=airius.com and the local machine is configured to manage only entries stored under the o=netscape.com tree, then a referral is returned to the client.
2. Replication Service
Replication is the mechanism by which directory data is automatically copied from one directory server to another. Using replication, you can copy everything from entire directory trees to individual directory entries between servers. Replication provides several important benefits to the directory service:
o Fault tolerance—By replicating directory trees to multiple servers, you can ensure your directory is available even if some hardware, software, or network problem prevents your directory clients from accessing a given directory server instance.
o Higher performance—By replicating directory entries to a location close to your users, you can vastly improve directory response times.
o Load balancing—By replicating your directory tree across servers, you can reduce the access load on any given machine, thereby improving server response time.
o Local data management—Replication allows you to own data locally and share it with other directory servers across your enterprise.
3. Security Service
The LDAP v2 supported three types of authentication: anonymous, simple (clear-text password), and Kerberos V4.
The LDAP v3 supports Secure Socket Layer (SSL) encryption uses the Simple Authentication and Security Layer (SASL)4 authentication framework to allow different authentication mechanisms to be used with the LDAP protocol. SASL specifies a challenge-response protocol in which data is exchanged between the client and the server for the purposes of authentication. There are several SASL mechanisms currently defined: DIGEST-MD5, CRAM-MD5, Anonymous, External, S/Key, GSSAPI, and Kerberos V4. An LDAP v3 client can use any of these SASL mechanisms as long as the LDAP v3 server supports them. Moreover, new SASL mechanisms can be used without changes to the LDAP protocol.
The data in the server is protected through the use of Access control Lists and client binding, regardless of server vendor. By default, all of the data in the server is protected from any action. The administrator of the LDAP server must specifically grant read, write, search, compare and delete access to the user before anyone can access the data.
2.2.3. LDAP: The APIs
An API (Application Programming Interface) is a standard interface that programmers use to write their applications. This relieves the programmer from having to worry about the implementation of LDAP itself because the APIs will work against any LDAP compliant directory server.
4 More about Simple Authentication and Security Layer (SASL) in RFC 2222
16
The University of Michigan, who led the development of LDAP, created their own C API that has even been referenced in RFC 1823, not as a standard but as an informational document. Due to its widespread distribution and the fact that it is free, it is now the de facto standard API. The University of Michigan API has now been ported to DOS, Windows 95/NT, all versions of Unix and IBM mainframes. It is a solid and ubiquitous API.
In addition, Netscape has released their own C, Java and Perl LDAP Software Developments Kits (SDKs), all of which are released as open-source projects. With the Netscape SDKs, the developer only needs to learn how to communicate via the LDAP API and an LDAP compliant server. It is up to the server vendor to worry about how to handle the communication from LDAP server to its back-end such as NDS5 or to a Windows NT domain.
Sun’s Java Naming and Directory Interfaces (JNDI) and Microsoft’s Active Directory Service Interfaces (ADSI) enable the programmer to connect with a variety of network and directory services. The other services include Sun’s NIS/NIS+, Novell’s NDS and Microsoft’s original networking technologies like windows NT domains. The goal is to enable the programmer to connect to any directory-like service from either JNDI or ADSI from a protocol neutral API/SDK. The diagram below and above will help demonstrate the difference between the Netscape LDAP SDKs view of directory services and the Sun JNDI / Microsoft ADSI point of view.
5 NDS is abbreviation of NetWare Directory Services, a product of Novell to manage user accounts in a NetWare environment.
17
client
DNS
NT domain
NDSLDAP
client
LDAP
NDS
DNS
NT domain LDAP
3 Java Naming and Directory Interfaces
3.1 JNDI Overview
In the last section some SDKs have been briefly introduced. One of them is JNDI, the Java Naming and Directory Interfaces form the Sun company.
The JNDI SDK is conceptually different from the Netscape directory SDK for Java. The latter is designed to provide low-level access to the LDAP protocol. It forces the server to speak LDAP, which means that the server developer has to worry about how to translate from a different protocol to a standard one. On the other hand, JNDI is designed to make the application developer responsible for the protocol used to communicate between the client application and the server. It does try to make things easy by creating a specific set of methods that the application can use, regardless of the underlying protocol used. The way all this is accomplished is through the use of service providers.
The diagram below shows the relationship between an application, JNDI, JNDI providers and directory servers.
Source: Implementing LDAP written by Mark Wilcox, published by Wrox Press 1999
3.2 JNDI Architecture
The JNDI architecture consists of an API (Application Programming Interface) and an SPI (Service Provider Interface). Java applications use the JNDI API to access a variety of naming and directory services. The JNDI SPI enables a variety of naming and directory services to be plugged in transparently allowing the Java application using the JNDI API to access their services.
18
Client Application
JNDI
LDAP Provider NIS Provider Novell Provider
LDAP NIS Novell
Source: The JNDI Tutorial6
3.3 Naming Service versus Directory Service
A fundamental facility in any computing system is the naming service. The means by which names are associated with objects, and by which objects are found given their names. In using almost any computer program or system, we are always naming one object or another. When we use an electronic mail system, for example, we must provide the name of the recipient to whom we want to send mail. When we want to access a file in the computer, must supply its name.
Many naming services are extended with a directory service. While a naming service allows us to look up an object given its name, a directory service also allows such objects to have attributes. Therefore, in addition to lookup, we can also get an object’s attributes or search for objects given their attributes.
A candidate for a typical directory service is the Domain Naming Service (DNS) that resolves domain names into IP addresses so that every IP address is unique over the network.In summary, we can have a naming service without a directory service, but we cannot have a directory service without a naming service.
3.4 JNDI Class Structure
The JNDI is a Java Standard Extension. It is divided into three packages:
o Javax.naming – this package that allows applications to interact with naming services.
o Javax.naming.directory – this allows applications to interact with both directory and naming services. It is derived from the javax.naming package.
6 The JNDI Tutorial written by Rosanna Lee, online http://java.sun.com/products/jndi/tutorial/
19
Java Application
JNDI API
Naming Manager
JNDI SPI
LDAP DNS RMI CORBA
o Javax.naming.spi – this is the package JNDI service providers use to interact with javax.naming.* packages. It enables different providers to be plugged in with an overlying JNDI API.
We will be using the javax.naming and javax.naming.directory packages, so it would be useful to have a quick reference to the interfaces and classes that these packages contain.
3.4.1 javax.naming
This package contains classes and interfaces for accessing naming services.Interfaces
o Context – defines the methods needed to access and modify the JNDI environment a particular application might be in (e.g. items such as hostname, port, user ID, ect)
o Name – defines methods for providing for a standard name for an object
o NameParser – defines methods that can break a hierarchal name (such as an LDAP entry’s DN) into it constituent parts
o NamingEnumeration – defines methods that are used to provide a back list of objects by the classes in the java.naming.* packages
o Referencable – only implemented by classes that can provide references back to themselves (that is they can provide an address to a storage location that is not bound to the directory server)
Classeso BinaryRefAddr – provides a binary data type that represents the location of an
object such as the BER7 encoded LDAP location of an object or a handle to a serialized Java object
o Binding – allows the association of a name, such as cn=MyJavaObject, ou =Java, o=airius.com, to a specific object
o CompositeName – enables the creation of an object name from multiple namespaces (e.g. attributes of an object might be stored in LDAP and on a file system)
o CompoundName – supplies a hierarchal namespace such as that of LDAPo InitialContext – represents the initial environment (e.g. LDAP, NIS, file
system, ect.) that the application will be accessingo LinkRef – represents a Reference object which has a value that is a name,
called the link name, that is bound to a single name inside a context (in the case of LDAP, the value of a link name would be an entry’s DN)
o NameClassPair – represents a name which is associated with a fully qualified package name of an object, e.g. cn=String -> java.lang.String
7 Communications that occur during LDAP transactions also occur in a text based format. This means that all the information that is transferred must all be converted into text. The conversion format that they followed is called the Basic Encoding Rules (BER) and is defined by IETF. BER is a standard format for the transmission of data across the Internet.
20
o RefAdrdr – represents a Reference object that contains a name and address of an object that represents communications protocol such as “NT Printing Service”
o Reference – an object that is stored outside the naming and directory serviceso StringRefAddr – denotes the string form of an address necessary for a
communications system, such as a hostname or a URL
3.4.2 javax.naming.directory
This package extends the javax.naming package to provide functionality for accessing directory services in addition to naming services. This package allows applications to retrieve attributes associated with objects stored in the directory and to search for objects using specified attributes.
Interfaces
o Attribute – defines a single attribute of an objecto Attributes – defines a collection of Attribute objectso DirContext – an interface to a directory service
Classes
o BasicAttribute – represents a simple implementation of the Attribute interface
o BasicAttributes – stores a collection of BasicAttribute objectso InitialDirContext – represents the initial context for directory server
operationso ModificationItem – represents controls we can present to the server to extend
the standard directory service functions, such as sorting the search resultso SearchResult – represents the results of a directory service search operation
Exceptions
The JNDI defines a class hierarchy for exceptions that can be thrown in the course of performing naming and directory operations. The root of this class hierarchy is NamingException. Programs interested in dealing with a particular exception can catch the corresponding subclass of the exception. Otherwise, programs should catch NamingException.
3.5 Operating JNDI
Before we get started with some examples in this sections, first we have to make sure that we have the required software:
o Java Platform Softwareo JNDI Softwareo Service Provider Software o Naming and Directory Server Software
21
For our examples, we will use the LDAP service provider and set up the Netscape Directory Server 4.0 with a sample database, the data for which is contained in the airius.ldif file.
3.5.1 Binding
Before performing any operation on a naming or directory service, you need to acquire an initial context, the stating point into the namespace. This is because all methods on naming and directory services are performed relative to some context. To get an initial context, we must:
o Select the service provider of the corresponding service we want to accesso Specify any configuration the initial context needso Call the InitialContext constructor
This is best illustrated using an example.
// create a Hashtable object to store our environmental variablesHashtable env = new Hashtable();
// Specify which class to use for our JNDI providerenv.put(Context.INITIAL_CONTEXT_FACTORY,
”com.sun.jndi.ldap.LdapCtxFactory”);
// Specify host name and port numberenv.put (Context.PROVIDER_URL, “ldap://localhost:389”);
// Get a reference to a directory contextDircontext ctx = new InitialDirContext(env);
In the example above we are bound as anonymous. For some operations, however, we will need to be bound as a particular user. Recall that access rights to the directory tree are controlled by how we are bound.
We can specify authentication by including the Context.SECURITY_AUTHENTICATION, Context.SECURITY_PRINCIPAL, and Context.SECURITY_CREDENTIALS keys in the hash table passed to the InitialDirContext objects.
Here is some example syntax, illustrating a authenticated bind:
// create a Hashtable object to store our environmental variablesHashtable env = new Hashtable();
// Specify which class to use for our JNDI providerenv.put(Context.INITIAL_CONTEXT_FACTORY,
“com.sun.jndi.ldap.LdapCtxFactory”);
// Specify host name and port numberenv.put (Context.PROVIDER_URL, “ldap://localhost:389”);
// Security Information will be send as plain text over the wireenv.put (Context.SECURITY_AUTHENTICATION, “simple”);env.put (Context.SECURITY_AUTHENTICATION, “myDN”);env.put (Context.SECURITY_CREDENTIALS, “myPassword”);
// Get a reference to a directory contextDircontext ctx = new InitialDirContext(env);
22
Once again we create a Hashtable object and specify which JNDI provider we will be using. To specifically bind to the server we must provide the environment with the method for our authentication (e.g. “simple”, SSL, or SASL). Then we must specify the DN and the password of the entry we wish to bind as.
3.5.2 Searching an LDAP Server
One of the most useful features a directory offers is the search service. We can specify a query comprising attributes of entries that we are looking for and submit that to the directory. The directory returns a list of entries that satisfy the query.
The DirContext interface provides several methods for searching the directory, with progressive degrees of complexity and power. We perform a search using the search() method of an object that implements the DirContext interface. The minimum number of parameters which must be supplied the search base a search filter. With a SerachControls object we can set other optional parameters to specify the scope whether the search should be performed in the entire directory , in the subtree or only in the named object.
Our first example will show a very simple search example, where the search filter is sn=Carter. This will return all entries that have a surname, that is the attribute specified by sn, of Carter. This first example is an anonymous search.
//standard anonymous search
import java.util.Hashtable;import java.util.Enumeration;
import javax.naming.*;import javax.naming.directory.*;
public class JNDISearch{ // initial context implementation public static String INITCTX = "com.sun.jndi.ldap.LdapCtxFactory"; public static String MY_HOST = "ldap://localhost:389"; public static String MY_SEARCHBASE = "o=airius.com"; public static String MY_FILTER = "(sn=Carter)";
public static void main (String args[]) { try {
//Hashtable for environmental information Hashtable env = new Hashtable(); //Specify which class to use for our JNDI provider env.put(Context.INITIAL_CONTEXT_FACTORY, INITCTX); //Specify host and port to use for directory service env.put(Context.PROVIDER_URL, MY_HOST);
//Get a reference to a directory context DirContext ctx = new InitialDirContext(env);
//Specify the scope of the search SearchControls constraints = new SearchControls(); constraints.setSearchScope(SearchControls.SUBTREE_SCOPE);
23
//perform the actual search //we give it a searchbase, a filter and a the constraints //containing the scope of the search NamingEnumeration results = ctx.search(MY_SEARCHBASE, MY_FILTER, constraints);
//now step through the search results while (results != null && results.hasMore()) { SearchResult sr = (SearchResult) results.next(); String dn = sr.getName(); System.out.println("Distinguished Name is "+dn);
Attributes attrs = sr.getAttributes();
for (NamingEnumeration ne = attrs.getAll(); ne.hasMoreElements();)
{ Attribute attr = (Attribute)ne.next(); String attrID = attr.getID();
System.out.println(attrID+":"); for (Enumeration vals = attr.getAll(); vals.hasMoreElements();)
{ System.out.println("\t"+vals.nextElement()); } } System.out.println("\n"); } } catch(Exception e) { e.printStackTrace(); System.exit(1); } }}
The search above is a anonymous search. In every LDAP server, there are certain attributes that are not going to be available to anonymous users because of the access controls on the server. There are also certain attributes that may only be available to certain privileged users – pay scale, for example, may only be visible to human resources. If we want to see these attributes, we must first bind as authenticated users (see authenticated bind in the last section).
The output from this code example is shown in the screenshot:
24
The search filter syntax is basically a logical expression in prefix-notation. For example: (|(&(sn=Carter) (mail=*)) (sn=L*)) , this expression is asking for entries that have both a sn attribute of “Carter” and have the mail attribute, or entries whose sn attribute begins with the letter L. The following table lists the symbols used for creating filters.
Symbol Description& conjunction (i.e., and -- all in list must be true) | disjunction (i.e., or -- one or more alternatives must be true) ! negation (i.e., not -- the item being negated must not be true) = equality (according to the matching rule of the attribute) ~= approximate equality (according to the matching rule of the attribute) >= greater than (according to the matching rule of the attribute) <= less than (according to the matching rule of the attribute) =* presence (i.e., entry must have the attribute but its value is irrelevant)
* wildcard (indicates zero or more characters can occur in that position). This is to be used when specifying attribute values to match.
\ escape (for escaping '*', '(', or ')' when they occur inside an attribute value value)
Source: The JNDI Tutorial
In the last example we have once used the Searchcontrols object to select the attributes that are returned with entries in a search operation. We can use the search controls argument to control other aspects of the search.
We can set the search controls argument to select the attributes that should be returned, not all of the attributes that the results entries have. We create an array of attribute identifiers that we want to include in the result and pass it to
25
SearchControls.setReturningAttributes(). Here is an example that returns the attributes surname (sn), phone number (telephonenumber), golfhandicap, and e-mail address (mail) of entries that have an attribute mail and have the surname sn=Carter.:
// Specify the ids of the attributes to returnString[] attrIDs = {"sn", "telephonenumber", "golfhandicap", "mail"};SearchControls constraints = new SearchControls();constraints.setReturningAttributes(attrIDs);
// set the search filterString filter = "(&(sn=Carter)(mail=*))";
// perform the actual search. NamingEnumeration enum =ctx.search("o=Airius.com",filter,constraints);
The default SearchControls specifies that the search is to be performed in the named context (SearchControls.ONELEVEL_SCOPE). In addition to this default, we can also specify that the search be performed in the entire subtree, or that the search be performed only in the named object.
Searching the entire subtree means that the named object and all of its descendants are searched. To make the search behave this way, pass SearchControls.SUBTREE_SCOPE to the SearchControls.setSearchScope()method as follows:
SearchControls constraints = new SearchControls();constraints.setSearchScope(SearchControls.SUBTREE_SCOPE);
We can also search the named object. This is useful, for example, if we want to test whether the named object satisfies a search filter. To search the named object, pass SearchControls.OBJECT_SCOPE to setSearchScope():
SearchControls constraints = new SearchControls();constraints.setSearchScope(SearchControls.OBJECT_SCOPE);
String filter = "(&(sn=Carter)(mail=*))";
// Search subtree for objects using filterNamingEnumeration enum = ctx.search("cn=Sam Carter, ou=People, o=Airius.com", filter, consttraints);
Sometimes, there are queries we know that might produce too many answers, and we would like to limit the number of answers that we get back. we can do this by using the count limit search control. By default, a search does not have a count limit, which means that it will return all the answers that it finds. To set the count limit of a search, pass the number to the method SearchControls.setCountLimit(). This example sets the count limit to 1:
// Set search controls to limit count to 1SearchControls constraints = new SearchControls();constraints.setCountLimit(1);
When we set a time limit on a search, that places an upper bound on the amount of time that the search operation will block waiting for the answers. This is useful when we don't want to wait too long for an answer. If the time limit specified is exceeded before the search operation can be completed, a TimeLimitExceededException is thrown.
26
To set the time limit of a search, pass the number of milliseconds to the method SearchControls.setTimeLimit(). This example sets the count limit to 1 second:
// Set search controls to limit time to 1 second (1000 ms)SearchControls constraints= new SearchControls();constraints.setTimeLimit(1000);
3.5.3 LDAP Server Modifications
We can also use JNDI to add new entries to the server, delete entries as well as modify existing entries.
3.5.3.1 Adding Entries
To store an entry in an LDAP server using JNDI, we must first bind an object to a DN. This means that each object (whether this is a simple person entry or a serialized Java class) we store in the server must have a DN associated with it. This is not an entirely new concept to us because every entry in an LDAP server must have a DN.
To store even a simple entry in the LDAP server, we must create a class that implements the DirContext interface. Our next code sample shows a very simple Person class that implements the Dircontext interface.
public class Person implements DirContext { String type; Attributes myAttrs;
//Person("mewilcox", "Mark", "Wilcox", "ou=Accounting", [email protected] ); public Person(String uid,String givenname,String sn,String ou, String mail) { type = uid;
myAttrs = new BasicAttributes(true); // case ignore
Attribute oc = new BasicAttribute("objectclass"); oc.add("inetOrgPerson"); coward("organizationalPerson"); oc.add("person"); oc.add("top");
Attribute ouSet = new BasicAttribute("ou"); ouSet.add("People"); ouSet.add(ou);
String cn = givenname+" "+sn;
myAttrs.put(oc); myAttrs.put(ouSet); myAttrs.put("uid",uid); myAttrs.put("cn",cn); myAttrs.put("sn",sn); myAttrs.put("givenname",givenname); myAttrs.put("mail",mail); } public Attributes getAttributes(String name) throws NamingException
27
{ if (! name.equals("")) { throw new NameNotFoundException(); } return myAttrs; }...}
Source : Implementing LDAP
In the example above, first we use the BasicAttributes class to store our attributes and their values. The BasicAttributes class stores attributes using the BasicAttribute class. By specifying “true” in the BasicAttributes constructor we are telling it to ignore the case of attribute names when doing attribute name lookups.
Then, we need to create a new BasicAttribute object which requires the name of the attribute in its constructor and add its values with the add() method.
Finally, we add all of our attributes to the BasciAttributes object with the put() method.
Now, we can add an entry of type Person to the server. First we must have connected and bound as an authenticated user and created a DirContext object. Then we must create a new Java object that implements the DirContext interface such as our Person class like this:
Person p = new Person(“mewilcox”, “Mark”, “Wilcox”, “ou=Accounting”, “mewilcoxairius.com”);
Then we associate a name, specifically the DN of the entry, with this object (in this case its name is ctx)in our current context with the bind() method of the DirContext interface like this:
Ctx.bind (“uid=mewilcox, ou=People, o=airius.com”, p);
The InitialDirContext class will then perform the LDAP addition operation. It will retrieve all of the attributes we have stored in our entry and add them to the server. But we have to ensure that new objects must conform to the LDAP server’s schema, or entries will not be added.
3.5.3.2 Modifying Entries
LDAP is used mainly for search service, but there are some situations where LDAP entries need to be updated, for example:
o A user needs to change his passwordo Someone changes his or her nameo People switch jobs, and change his offices
To modify an entry first create an array of two ModificationItem objects. The ModificationItem takes a modification type (add, replace or delete) and an attribute object such as BasicAttribute. Here is a simple example that does two things. First it
28
changes the telephonenumber, i.e. replaces an old value with a new one, as specified by the dirContext.REPLACE_ATTRIBUTE flag. Secondly, it adds a new attribute to the entry, a locality ( the l attribute), with a value of “Hamburg”. The DirContext.ADD_ATTRIBUTE flag allows this to take place:
ModificationItem[] mods = new ModificationItem[2];
Attribute mod0 = new BasicAttribute("telephonenumber","+49-177-2555");Attribute mod1 = new BasicAttribute("l", "Hamburg");
mods[0] = new ModificationItem(DirContext.REPLACE_ATTRIBUTE,mod0);mods[1] = new ModificationItem(DirContext.ADD_ATTRIBUTE,mod1);The actual modification is performed by the DirContext method, modifyAttributes(), as follows:
ctx.modifyAttributes("uid=NLe, ou=Special Users ,o=airius.com", mods);
The modifications above can only be performed by an authenticated user who has the permission granted in the access controls lists.
3.5.3.3 Deleting Entries
Deleting entries is easily accomplished by calling the destroySubContext() method of the DirContext interface, with the distinguished name of the entry that needs to be removed. Delete operation is restricted to privileged users, e.g. database administrators.
ctx.destroySubcontext("uid=NLe, ou=Special Users ,o=airius.com");
29
4 User Management In Distributed Systems
4.1 Formulation of the problem
User management in distributed systems is always followed with many problematical aspects, although the idea of user management is not new. Over years, since Unix was published, many concepts were found to be the solution patterns. Here we will discuss about two aspects of this problem. The first one is how to store the user information in a distributed system of an enterprise. Another one is the security aspect, how the users of a system could access to the information resources.
Storing user information of an enterprise is related to the problem of modeling the structure of the enterprise. It is meant that an employee is in relation with the departments he belongs to, and a department is again in relation with other organization units and with the enterprise. Normally, the structure of a enterprise is designed by the managers of the enterprise. Database administrators do not have any influence on this work. So, if there is any changes of the enterprise structure, database administrators must design their database again, and it is a hard work, especially in the relational database system. If a database contains over hundred tables and their relationship has to be changed, it would be not simple. As we have seen in the last sections, LDAP provides a centralized directory service. With LDAP, it is also possible to store employee data in a manner so that the structure can be flexibly changed.
The aspect of security can also be supported with LDAP. With access controls we can set access rights for certain users or certain groups of users. For example, an intranet is developed to provide services to the employees to improve the productivity of a company. But certain service is only available to definite persons or a group of persons, e.g. intranet service for human resources is only available to employees of this department and to the managers of the company. With LDAP we can not only manage user data and others resources like device or intranet but also protect securely anonymous access to these data. The next section will introduce some security features LDAP v3 provides.
4.2 Securing LDAP
4.2.1 Access Control Lists
With Access Control Lists (ACL), we can give one user the ability to see and modify all of an entry, and restrict another user to just being able to read an entry, and we can limit the number of possible attributes of an entry an anonymous user can see. By default, all of the data in the tree is restricted so that the only user that can see, compare, read or modify it is the Directory Manager (that is the super-user account of the database). When we use ACLs, we are in fact giving abilities to certain entries or group of entries. For example, we might specify that end-users can modify their passwords and telephone numbers, but only their area’s database manager can add or move an end-user from the LDAP server. We can also give rights to an entire group of users.
30
In LDAP, ACLs are built using the aci8 attribute. The actual syntax can vary from server to server. Because there is not a standard sysntax for ACLs, this does pose some problems in exchanging data between LDAP servers. Every compliant sever can accept LDIF, the LDAP Data Interchange Format 9, that means that it is possible to share data between LDAP servers, regardless of the differences in implementation or a replication standard.
Here is an example that shows a Netscape ACL in LDIF:
Aci: (target =”ldap:///ou=People, o=airius.com”) (targetattr !=”cn || sn || uid”) (targetfilter =”(ou=Accounting)”) (version 3.0; acl “Accounting Managers Group Permissions”; allow (write) (groupdn = “ldap:///cn=Accounting Managers, ou=groups, o=airius.com”);)
The following table explains the part of a Netscape ACL:
ACL Label ACL Value
targettargetattrtargetfilterVersionaclallowbind DN
A DN in LDAP URL format (without the hostname)A search filter of attributes this ACL affectsThis ACL only affects entries that match this filterThe version of the ACLA comment A list of modifications (e.g. write, read, search, compare, ect.)This ACL is only effective for bound entries that match this DN
Source: Implementing LDAP
We can have a look in some ACLs of the example airius.ldif file that comes with Netscape Directory Server 4.0
This ACL for the o=airius.com entry gives the anonymous user read-only access to every attribute under the airius.com base, except for userPassword, which an anonymous user cannot see at all:
dn: o=airius.comobjectclass: topobjectclass: organizationo: airius.comaci:(target ="ldap:///o=airius.com") (targetattr!="userPassword") (version 3.0;acl "Anonymous read-search access";allow (read, search, compare) (userdn = "ldap:///anyone");)
The next ACL also for the o=airius.com entry allows members of the group Directory Administrators full access to every attribute and entry in the tree:
aci: (target="ldap:///o=airius.com") (targetattr = "*")(version 3.0; acl "allow all Admin group"; allow(all) groupdn = ldap:///cn=Directory Administrators, ou=Groups, o=airius.com";)
And now let us have a look at the ou=People, o=airius.com entry:
8 Aci: Access Control Information9 LDIF is a text-based format that displays entry information by using mnemonic named attributes and text values.
31
dn: ou=People, o=airius.comobjectclass: topobjectclass: organizationalunitou: People
This ACL says that each user can change their password, telefone number and fax number:aci: (target ="ldap:///ou=People, o=airius.com") (targetattr="userpassword || telephonenumber || facsimiletelephonenumber")(version 3.0;acl "Allow self entry modification"; allow (write)(userdn = "ldap:///self");)
4.2.2 LDAP for Authentication
Beside providing directory lookup information, another common use of LDAP is for user authentication . As we will see, this can range from simple user IDs and passwords to encrypted personal certificates. An authentication example will be shown later, we will learn how to provide authentication in a Java servlet.
The LDAP v3 supports anonymous, simple and SASL authentication. SASL is the Simple Authentication and Security Layer. It specifies a challenge-response protocol in which data is exchanged between the client and the server for the purposes of authentication and establishment of a security layer on which to carry out subsequent communication. By using SASL, the LDAP protocol can support any type of authentication agreed upon by the LDAP client and server. The two most important SASL mechanisms are :
o Kerberos V410
o MD5
The simple authentication consists of sending the LDAP server the fully qualified distinguished name of the client (user) and the client’s clear-text password. There are security problems with this mechanism because the password can be read from the network. To avoid exposing the password in this way, we can use the simple authentication within an encrypted channel such as SSL if that is supported by the LDAP server.
The simple and MD5 authentication mechanisms authenticate the LDAP client to the LDAP server. They do not provide any other security features, such as ensuring that requests sent to the server on that authenticated connection are from the same client, or protecting the privacy of the data exchanged between the client and the server. To provide higher levels of security for communicating with clients, most LDAP servers allow their services to be accessed through secure sockets, or SSL. Such servers support SSL ports in addition to normal (unprotected) ports.
4.3 User management with LDAP
Before we can try to solute the user management problem with LDAP, first we should have an overview of our requirements. We will attempt to develop for the Computer
10 More information about Kerberos can be found at http://nii.isi.edu/publications/kerberos-neuman-tso.html
32
Science department of University Hamburg an intranet. For each organization unit there are some own services, and only employees of this organization unit are allowed to use these services. But some people who do not belong to any organization unit, e.g. the dean of department, should be able to have access to all of services. Some people should perhaps only be able to read some data but not to modify, for example all students have right to see the result of their exams on intranet but only their professors have full access right to this service.
4.3.1 Designing LDAP Tree
The purpose of this directory is to maintain user and group information as well as service data in support of an intranet. We can step by step design our directory tree as follows:
o First we root the directory tree in an Internet domain name. We use the organization attribute to root the directory: o=informatik.uni-hamburg.de
dn: o=informatik.uni-hamburg.de objectclass: top objectclass: organization
o: informatik.uni-hamburg.de
o At the root point of the directory tree, we define some general access-control privileges, such as anonymous access for read, search, and compare, or authenticated read, search ,and compare access.
aci: (target ="ldap:///o=informatik.uni-hamburg.de")(targetattr !="userPassword")(version 3.0;acl "Anonymous read-search access";allow (read,search, compare)(userdn = ldap:///anyone");)
o Create two primary branch points in the directory, one for people and one for Intranet Services: ou=people and ou= Intranet Services
dn: ou=People, o=informatik.uni-hamburg.deobjectclass: topobjectclass: organizationalunitou: People
dn: ou=Inranet Services, o=informatik.uni-hamburg.deobjectclass: topobjectclass: organizationalunitou: Intranet Services
o Under ou=people, we will create all of our sub organizations, and under each sub organization the people entries and appropriate groups. Here we have two sample sub organizations under the ou=people:
dn: ou=SWT, ou=People, o=informatik.uni-hamburg.deobjectclass: topobjectclass: organizationalunitou: swtou: People
dn: ou=VSYS, ou=People, o=informatik.uni-hamburg.deobjectclass: topobjectclass: organizationalunitou: VSYS
33
ou: People
Under the ou=VSYS we have two person entries. The person or inetOrgPerson object class can be used :
dn: uid=NLe, ou=VSYS, ou=People, o=informatik.uni-hamburg.decn: Nguyen-Thinh Lesn: Legivenname: Nguyen-Thinhobjectclass: topobjectclass: personobjectclass: organizationalPersonobjectclass: inetOrgPersonou: VSYSou: Peopleuid: Nletelephonenumber: +1 408 555 3232mail: [email protected]: thinh
dn: uid=FGriffel, ou=VSYS, ou=People, o=informatik.uni-hamburg.decn: Frank Griffelsn: Griffelgivenname: Frankobjectclass: topobjectclass: personobjectclass: organizationalPersonobjectclass: inetOrgPersonou: VSYSou: Peopleuid: FGriffelmail: [email protected]: 0049 40 userpassword: Frank
Under the ou=VSYS we also would like to create two groups, one for students and another one for assistants of the organization VSYS. Of course we can create more in order to manage the users, for example a group for professors of VSYS, a group for secretary. But here we have a small example:
dn: cn=VSYS-Students, ou=VSYS, ou=People, o=airius.comobjectclass: topobjectclass: groupOfUniqueNamescn: VSYS-Studentsou: VSYSou: Peopleuniquemember: uid=NLe, ou=VSYS, ou=People, o=informatik.uni-hamburg.dedescription: students of VSYS
dn: cn=VSYS-Assistants, ou=VSYS, ou=People, o=airius.comobjectclass: topobjectclass: groupOfUniqueNamescn: VSYS-Assistantsou: VSYSou: Peopleuniquemember: uid=FGriffel, ou=VSYS, ou=People, o=informatik.uni-hamburg.dedescription: students of VSYS
34
o At the point ou=intranet services, we create a sub tree with many branches, each for one service, for example:
dn: ou=Exam Results, ou=Intranet Services, o=informatik.uni-hamburg.deobjectclass: topobjectclass: organizationalunitou: Exam resultsou: VSYSou: Intranet Services
dn: ou=lecture evaluation, ou=Intranet Services, o=informatik.uni-hamburg.deobjectclass: topobjectclass: organizationalunitou: ou=lecture evaluationou: VSYSou: Intranet Services
o At each point of each intranet service, we define some access controls information that allow the user groups the appropriate directory permissions. For example, for the group cn=VSYS-Assitants, ou=VSYS, ou=People, o=informatik.uni-hamburg.de , we can grant the permission to write the exam results.
aci: (target ="ldap:///ou=Exam results, ou=Intranet Services, o=informatik.uni-hamburg.de")(targetattr =*)(version 3.0;acl "Permissions for VSYS-Assistants"; allow (write)(groupdn = "ldap:///cn=VSYS-Assistans,ou=VSYS,ou=People,o=informatik.uni-hamburg.de");)
The following shows a sample directory tree designed as described above:
4.3.2 Vision
35
O = informatik.uni-hamburg.de
ou = People
ou = VSYS
cn = VSYS-Assistants
uid=FGriffel
ou = SWT
cn = VSYS-Students
uid=NLe
ou=Exam results ou=Lecture evaluation
ou=Intranet services
Entry1 Entry2 Entry3
We will implement one user interface for the administrator and one for users. The administrator would be able to register new user into LDAP tree. There are two options, one for special persons and one for normal persons.
If the administrator choose the option for special persons then the existing groups in the tree will be listed. He now choose an group the special user should be belong to. This special person will have all permissions this group owns. In addition, the administrator could specify other values for this special person.
If the administrator choose the option for normal persons then he will get a list of existing groups. He now can pick a group for this normal user. The user will inherit all the access rights this group is granted.
On the user side, before he can use any intranet service he must authenticate to the LDAP server. He will enter his user ID and his password. The LDAP server will look up in the tree if these values exist. If yes, he can then use any intranet services that are for him visible. If one of the user ID or password value is not correct, he will be requested to enter new values.
36
5 Implementing User Interfaces
As we have seen in the Java Naming and Directory Service (JNDI) section that with JNDI we can build clients working with LDAP server. The representing LDAP server we have chosen is the Netscape directory Server 4.0 and we will use sample data from the airius.ldif file that is included in the server package to demonstrate our examples. We will build two user interfaces for the user side. The first one is used to authenticate to the server. The second one is useful for the users to change their password.
5.1 The First User Interface: Servlet Authentication
In earlier section, we have covered to topic of using authentication with LDAP, but in this section, we will look at a more real example, using Java servlets.
In the example that follows, we are going to look at how to use standard web authentication (BASIC authentication), which is already built in to all of the common web browsers and is the easiest one to manage. BASIC authentication is the mechanism being used whenever we go to a web site and a little box pops up askin for user ID and password. To get that box to pop up, we must tell the servlet to request the “Authorization” header, like this:
// Get Authorization headerString auth = req.getHeader(“Authorization”);)
When the boxes are filled in and the user clicks OK, the browser will return back the Authorization header, which will contain the word BASIC immediately followed by the Base64 encoded user ID and password. When decoded, the user ID and password will be separated by a colon.
Here is an example screenshot of the window asking for user ID and password:
37
Base64 encoding is not an encryption mechanism. It is just a scheme so that we can send information across the Internet. Usually it is used to send binary information, but it has other uses as well.
Shown below is the full code listing for the LDAPAuth example:
import java.io.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*;
import java.util.Hashtable;import java.util.Enumeration;
import javax.naming.*;import javax.naming.directory.*;
public class LDAPAuth extends HttpServlet{ Hashtable users = new Hashtable(); public void init(ServletConfig config) throws ServletException { super.init(config); }
public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/plain"); PrintWriter out = res.getWriter();
//Get Authorization header String auth = req.getHeader("Authorization");
//Do we allow that user if (!allowedUser(auth)) { //Not Allowed, so report he's unauthorized res.sendError (res.SC_UNAUTHORIZED); res.setHeader("WWW-Authenticate", "BASIC realm=\"users\""); //Could offer to add to user list } else { //User is allowed in out.println("This space for rent"); } } /* This method checks to see if the user is in the LDAP database */ protected boolean allowedUser(String auth) throws IOException { String dn = null; String pwd = null; String INITCTX ="com.sun.jndi.ldap.LdapCtxFactory";
String MY_HOST = "ldap://localhost:389"; String MY_SEARCHBASE = "o=airius.com"; boolean status =false;
try { if (auth == null) return false; // no authentication
38
if (!auth.toUpperCase().startsWith("BASIC")) { return false; // only do BASIC } // Get encoded user and password, comes after BASIC String userpassEncoded = auth.substring(6); //Decode it, using any base64 decoder sun.misc.BASE64Decoder dec = new sun.misc.BASE64Decoder(); String userpassDecoded = new String(dec.decodeBuffer(userpassEncoded)); StringTokenizer st = new StringTokenizer(userpassDecoded,":"); String uid = st.nextToken(); pwd= st.nextToken();
String MY_FILTER = "uid=" + uid;
//Hashtable for environmental information Hashtable env = new Hashtable();
//Specify which class to use for our JNDI provider env.put(Context.INITIAL_CONTEXT_FACTORY, INITCTX);
//Specify host and port to use for directory service env.put(Context.PROVIDER_URL, MY_HOST);
//Get a reference to a directory context DirContext ctx = new InitialDirContext(env);
//Specify the scope of the search SearchControls constraints = new SearchControls();
constraints.setSearchScope(SearchControls.SUBTREE_SCOPE); constraints.setCountLimit(1);
//perform the actual search NamingEnumeration results = ctx.search(MY_SEARCHBASE, MY_FILTER, constraints);
if (results !=null && results.hasMoreElements()) {
SerachResult sr = (SearchResult) results.next(); String dn = sr.getName();
System.out.println("dn is "+dn); //prevent anonymous connections if ((dn == "") || (pwd == "")) {return false;} else
{status = true;}
} else {
System.out.println("getCount is " +results.getCount()); status = false;
} } catch(Exception x) { x.printStackTrace(); }
39
return status; }}In order to run this example we first need a web server that can run the Sun standard Java servlets or we can use servletrunner utility, which is included in the Servlet API.
Before we can start servletrunner, we have to specify the properties of the servlet. The default name of the property file is servlet.properties. For our servlet example we must name our servlet like following:
Servlet.LDAPAuthServlet.code=LDAPAuth
The servlet.name.code property names our servlet by associating a name (in this example, LDAPAuthServlet) with a class (in this example, LDAPAuth.class).
We will call our servlet from Browsers. The URL for a servlet has the following general form, where servlet-name corresponds to the name we have given our servlet: http://machine-name:port/servlet/servlet-name
For example, to see our LDAPAuthServlet, we type the following URL into our browser: http://localhost:8080/servlet/LDAPAuthServlet
5.2 The Second User Interface: Changing Password Servlet
The next user interface provide a user possibility to change his password. But first the user must authenticate to the server. If he has enter the right user ID and correct password then he is able to change his password. The user interface can look as below:
After the send check button has been pressed, another servlet is called to do check. In our example, it is checkLDAPAuth servlet. Our checkLDAPAuth first will compare the values of the two input boxes if they are the same. If yes it will bind with the server and
40
then change the password with new value. If no, it will request the user new inputs. We will see how the code of our checkLDAPAuth servlet performs this work:
import LDAPAuth5;import java.io.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*;import java.util.Hashtable;import java.util.Enumeration;import javax.naming.*;import javax.naming.directory.*;
public class checkLDAPAuth extends HttpServlet{
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/plain");PrintWriter out = response.getWriter();
String DN_ = null;String newpwd_ = null;String confirmpwd_ = null;
DN_ = request.getParameter("distinguishedName");newpwd_ = request.getParameter("newpass");confirmpwd_ = request.getParameter("confirmpass");
//check if the input values are the sameif (!newpwd_.equals(confirmpwd_) )
{out.println ("your confirm password is not similar to your
new password");}
else {doCheck(DN_, newpwd_);out.println ("your password has been changed");}
}
public void doCheck (String DN, String newpass) throws IOException {
//initial context implementation
String INITCTX = "com.sun.jndi.ldap.LdapCtxFactory" ; String MY_HOST = "ldap://localhost:389"; String MGR_DN = DN; String MGR_PW = LDAPAuth5.pwd ; String MY_SEARCHBASE = "o=Airius.com";
try {
//Hashtable for environmental information Hashtable env = new Hashtable();
//Specify which class to use for our JNDI providerenv.put (Context.INITIAL_CONTEXT_FACTORY, INITCTX);env.put (Context.PROVIDER_URL, MY_HOST);env.put (Context.SECURITY_AUTHENTICATION, "simple");
41
env.put (Context.SECURITY_PRINCIPAL, MGR_DN);env.put (Context.SECURITY_CREDENTIALS, MGR_PW);
//Get a reference to a directory context DirContext ctx = new InitialDirContext(env);
ModificationItem[] mods = new ModificationItem[1] ; Attribute mod0 = new BasicAttribute("userpassword",newpass);
mods[0] = new ModificationItem (DirContext.REPLACE_ATTRIBUTE, mod0);
ctx.modifyAttributes ( DN , mods); } catch (Exception e) { e.printStackTrace(); System.exit(1); } }}
In the example above the first line imports the class LDAPAuth5, which is the class that creates user interface above.
42
6 Summary
As the example showed, LDAP is very useful to manage directory services. But can LDAP server replace Relational Database Management Systems (RDBMS)?
The answer is no. An RDBMS is good for applications which will have as many writer as they do reads. An RDBMS is also good in applications where we need sophisticated transaction control. LDAP does not have this transaction control feature. LDAP is only good for applications that will be read more than written to. While we could use either an RDBMS or LDAP to implement an address book applications (e.g. to look up email addresses and phone numbers ), LDAP is a better choice because more email-clients can query LDAP than can query an RDBMS.11
Actually, the LDAP is being supported by most major players like Microsoft, Novell, Sun and Netscape in their core products.
According to the book Implementing LDAP of Mark Wilcox12, Netscape has made LDAP the key part of its entire overall product strategy. All Netscape products – from organization-wide browser management, and central server management (which include web, mail and newsgroup servers) through to certificate management for secure transaction – are all managed by their LDAP server, the Netscape Directory Server. Netscape has even licensed the Directory Server to other vendors to be included in other products.
Novell’s Netware 5 includes an LDAP interface to provide LDAP access to the NDS tree including the GroupWise address book. This means that NDS networks can now be exposed through a public interface, enabling a wide range of Internet applications.
Sun is working on a similar product for NIS+. For now, the focus is on improving LDAP for use in storing network data, including Java objects and using LDAP to manage their mail servers. There is an open source program, called ypldap, which facilitates the use of an LDAP server to manage NIS+ systems without replacing all the NIS+ clients.
Microsoft’s Active directory, which is going to be an integral part of Windows 2000, will have LDAP as its central protocol. Once this happens, all of the major networking vendors will have LDAP accessible directories in place
We can see from the above discussion that LDAP use is widespread and has a great deal of vendor support. With several common APIs, it is now very straightforward to write LDAP applications and with Netscape’s and Microsoft’s visible commitment to LDAP clients, LDAP is definitely here to stay.
11 http://www.stanford.edu/~hodges/talks/EMA98-DirectoryServicesRollout/Steve_Kille/index.html12 Wilcox, Mark: Implementing LDAP 1998
43
Bibliography
Wilcox, Mark : Implementing LDAP , Wrox Press 1999.
Lee, Rosanna:The JNDI Tutorial online http:// java.sun.com/products/jndi/tutorial/
Netscape Communication Corporation : Deployment Guide Netscape Directory Server Version 4.0Installation Guide Netscape Directory Server Version 4.0
Campione, Mary; Walrath, Kathy; Hulm, Alison and the Tutorial Team:The Java Tutorial Continued, the Rest of the JDK, Addison-Wesley, 1998.
Howes, Tim; C. Smith, Mark; S.Good, Gordon; A. Howes, Timothy:Understanding and Deploying LDAP Directory Services (MacMillan Network Architecture and Development Services)
Request For Comment about LDAP v2, v3www.ietf.org/rfc/rfc2251.txtwww.ietf.org/rfc/rfc2252.txtwww.ietf.org/rfc/rfc2253.txt
44
![[MS-OXLDAP]: Lightweight Directory Access Protocol (LDAP ...download.microsoft.com/download/5/D/D/.../[MS-OXLDAP].pdf · Lightweight Directory Access Protocol (LDAP) is an industry-standard](https://img.pdfslide.us/doc/110x75/5ca08e0188c9931c188d5769/ms-oxldap-lightweight-directory-access-protocol-ldap-ms-oxldappdf.jpg)
![[MS-OXLDAP]: Lightweight Directory Access Protocol (LDAP ...interoperability.blob.core.windows.net/...OXLDAP/[MS-OXLDAP]-1503… · Lightweight Directory Access Protocol (LDAP) Version](https://img.pdfslide.us/doc/110x75/5e9cfc232f1beb086967dff0/ms-oxldap-lightweight-directory-access-protocol-ldap-ms-oxldap-1503-lightweight.jpg)
![[MS-OXLDAP]: Lightweight Directory Access Protocol (LDAP](https://img.pdfslide.us/doc/110x75/616af42d408c03592c4da9ce/ms-oxldap-lightweight-directory-access-protocol-ldap-.jpg)
