User Management In Distributed Systems

Studienarbeit von

Nguyen-Thinh Le

Tel. 0177-7374359

Email:

vorgelegt am 06.12.1999 bei

Prof. Dr. Winfried Lamersdorf

Arbeitsgruppe Verteilte Systeme

Fachbereich Informatik

Universität Hamburg

1.The problem of a decentralised user management system......

2.LDAP – Lightweight Directory Access Protocol......

2.1.A brief history of LDAP......

2.2.Introducing the Lightweight Directory Access Protocol......

2.2.1.LDAP - The Data Model......

2.2.1.1Data hierarchy......

2.2.1.3Object classes......

2.2.1.4Attributes......

2.2.1.5Distinguished Names......

2.2.1.6Schemas......

2.2.2.LDAP: The Protocol......

2.2.2.1LDAP Operations......

2.2.2.2Other Protocol Services......

2.2.3.LDAP: The APIs......

3Java Naming and Directory Interfaces......

3.1JNDI Overview......

3.2JNDI Architecture......

3.3Naming Service versus Directory Service......

3.4JNDI Class Structure......

3.4.1javax.naming......

3.4.2javax.naming.directory......

3.5Operating JNDI......

3.5.1Binding......

3.5.2Searching an LDAP Server......

3.5.3LDAP Server Modifications......

3.5.3.1Adding Entries......

3.5.3.2Modifying Entries......

3.5.3.3Deleting Entries......

4User Management In Distributed Systems......

4.1Formulation of the problem......

4.2Securing LDAP......

4.2.1Access Control Lists......

4.2.2LDAP for Authentication......

4.3User management with LDAP......

4.3.1Designing LDAP Tree......

4.3.2Vision......

5Implementing User Interfaces......

5.1The First User Interface: Servlet Authentication......

5.2The Second User Interface: Changing Password Servlet......

6Summary......

Bibliography......

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]:

  • Entry and management of personal data, such as name and address, is centralised. This information is entered and stored in one place.
  • 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.
  • 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.
  • 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- 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.
  • 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.
  • 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:

  • 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.
  • 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.
  • 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:

  • Vendor-derived
  • 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.

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:

  • The data model
  • The name space
  • The modes of operation
  • Authentication framework
  • 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 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 RFC[2] 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.

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.

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.de

cn: Nguyen-Thinh Le

sn: Le

givenname: Nguyen-Thinh

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: intOrgPerson

ou: Students

uid: NLe

mail:

telephonenumber: 0049 177 7374359

The attribute dnabove 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:

  • Domain objects
  • Organisational Unit objects
  • Group objects
  • 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 organizationalUnitand 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:

  • Full name (called common name or cn)
  • Last name (called surname or sn)
  • First name (called givenname)

They often include extra attributes like:

  • User ID
  • Telephone number
  • Fax number
  • Location
  • 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.