Using Acegi to protect Java applications, part 2nd: Using LDAP directory servers

Implementing access control using ApacheDS and Acegi

Having learned the basics of the Acegi security System (ACEGI), we will introduce more advanced applications of the system. In this article, Bilal Siddiqui shows you how to combine the use of Acegi and an LDAP directory server to achieve the security of a flexible, high-performance Java™ application. You will also learn how to write access control policies and store them in ApacheDS, and then configure ACEGI to interact with the directory server for authentication and authorization purposes.

This three-part series describes how to use the Acegi security system to protect Java enterprise applications. In the first article in this series, I introduced Acegi and explained how to use a security filter to implement a simple URL-based security system. In the second article, I'll discuss the more advanced application of Acegi, first I'll write an access control policy and store it in ApacheDS, ApacheDS is an open source LDAP directory server. I'll also show you how to configure Acegi so that it interacts with the directory server and implements your access control policies. The end of this article provides a sample application that uses ApacheDS and Acegi to implement a secure access control policy.

Implementing an access control policy typically consists of two steps:

Store data about the user and user roles in the directory server.

Write security code that defines who is authorized to access and use data.

Acegi will ease code writing, so in this article, I'll show you how to store user and user role information in ApacheDS, and then implement access control policies for that information. In the final article in this series, I'll show you how to configure Acegi to secure access to Java classes.

LDAP Basic Knowledge

The Lightweight Directory Access Protocol (lightweight) is probably the most popular protocol for defining data formats, for common directory operations, such as read, edit, and execute information that is stored in a directory server Search and delete operations. This section provides a brief explanation of why a directory server is the first choice for storing security information for a property file, and shows how to organize and host user information in an LDAP directory.

Why should I use a directory server?

The first part of this series introduces you to an easy way to save user information in the form of a property file (see part 1th, listing 6). The property file saves the user name, password, and user role in text format. For most real-world applications, using a property file to store security information is far from enough. There are various reasons to suggest that directory servers are usually a better choice. One reason is that real enterprise applications can be accessed by a large number of users-typically thousands of users-especially if the application exposes some of its functionality to users and vendors. It is not efficient to search frequently for information that is randomly stored in text files, but the directory server optimizes this type of search.

The property file in Listing 6 of part 1th illustrates another reason, which combines users and roles. In a real access control application, you typically need to define and maintain user and role information separately, which simplifies the maintenance of the user library. Directory servers provide great flexibility to change or update user information, for example, to reflect job promotions or new recruits.

LDAP Directory Settings

If you want to store user information in an LDAP directory, you need to understand some of the contents of the directory settings. Instead of providing a complete introduction to LDAP, this article describes some of the basic concepts you need to know before trying to combine the Acegi and LDAP directories.

The LDAP directory stores information in the form of a node tree, as shown in Figure 1:

Figure 1. The tree structure of the LDAP directory

In Figure 1, the name of the root node is org. The root node can encapsulate data related to different enterprises. For example, the manufacturing enterprise developed in the 1th part of this series is shown as a direct child node of the org node. The manufacturing enterprise has two child nodes named departments and the partnership.

The partners child nodes encapsulate different types of partners. Figure 1 shows the three customers, employees and suppliers respectively. Note that these three types of partners behave like enterprise system users. Each type of user has different business roles to play, so the rights to access the system are different.

Similarly, the Departments node contains data from different sectors of the manufacturing enterprise-such as engineering and marketing byte points. Each departmental node also contains one or more groups of users. In Figure 1, the engineers group is a child node of the engineering department.

Suppose a child node for each department represents a group of users. Therefore, the child nodes of the departmental node have different user members. For example, all engineers in the design department are members of the engineers group within the engineering department.

Finally, note the last child node of the departments node in Figure 1. Specialuser is a user, not a group of users. In the directory settings, users like Alice and Bob are generally included in the nodes. I included this particular user in the Departments node to demonstrate the flexibility of Acegi allowing users to be located anywhere in the LADP directory. Later in this article, you will learn how to configure Acegi to apply Specialuser.