Controlling Access to an Extranet

The only real difference today among an extranet, an intranet, and a public Web site is how and when users can access the site. Intranets are often on private networks, and extranets are occasionally, as well; but today’s robust access-control mechanisms make private networks less and less essential to providing secure access to either an extranet or an intranet. On the other hand, password-protecting portions of a public Web site is becoming more and more common, and isn’t a password-protected Web site the same thing as an extranet?

One of today’s most important access-control technologies is the Lightweight Directory Access Protocol, or LDAP. It is a standard way of storing and accessing directory-type information, such as usernames and passwords. LDAP has a hierarchical structure, which makes it easy to assign users to groups of people who are allowed to access different parts of an extranet. In this article, I will cover some of the considerations you must make when planning your extranet’s access-control strategy, and then I will outline some of the technology you might use to implement such a strategy with LDAP.

Who are your users?

You must first resolve the question of who your users are. I use the term users to mean “any human being who might use any part of your extranet.” In the case of a business-to-business extranet, your users will consist of various kinds of people at your customers’ locations — data-entry personnel, managers, executives, IT people, and so on. If you’re building a business-to-consumer extranet (say, an e-commerce site), then consumers will make up the bulk of your users. So far, so good; but don’t stop there. Be sure to consider all the users who are located at your own company: your executives and managers, customer service representatives, operators, technical support personnel, and so forth. Think of every kind of person who might need access to the extranet for any reason.

Secondly, you must think about the different roles your users might have. Which manage the user database? Who can change other people’s passwords? Who is in charge of monitoring the extranet for fraudulent activity and of excluding individuals who do not have proper access?

Here, for example, is a list of four roles and the duties each might perform:

• Internal manager: create customer service representatives (CSRs), delete CSRs, change CSR passwords.
• CSR: Create customer accounts, delete customer accounts, change customer passwords, suspend customer login privileges, assign customer privileges, monitor customer activity on the extranet.
• Customer manager: access privileged customer pages, monitor user activity for their own organization.
• Customer user: access general customer pages.

In addition, every user must be able to log in and change their own password.

Organizing your LDAP database

Once you have your roles defined, you can set up your LDAP database to support the different privileges and duties of your users. The best approach is to create groups that correspond to the people who share the same privileges. The groups we need in this example are executives, CSRs, managers, and users.

A group is an example of an organizational unit in LDAP. One other organizational unit we need is called people. You typically set up your organizational units and groups from your LDAP server-management console. In addition, you must add your executives to the LDAP database manually, if none of your users may create executive users, as in our example.

You will also need another organizational unit that contains a special entry that corresponds to your middleware component. The middleware must bind, or “log into,” the directory server as though it was a special user. In our example, this organizational unit is named “Application Server.”

Logging into your extranet

In my example I will use the Netscape Enterprise Server as my Web server and the Netscape Directory Server as my LDAP server. The Web server uses Server-Side JavaScript (SSJS) to build its pages and accesses a Java application server middleware component using LiveConnect, Netscape’s JavaScript to Java communication protocol. (Read more about using Server-Side LiveConnect in a previous article of mine.)

Fortunately, Netscape provides much of the SSJS and Java code you need to access the Directory Server from a Web page. You can find the SSJS API at Accessing LDAP from Server-Side JavaScript and the Java LDAP SDK at Netscape Directory Developer Central.

When a customer user, say, enters their userid and password and clicks “submit,” the Web server loads a page that executes the following code:

/*
* First, we must build the "distinguished name," 
  or dn, for the user who is 
* attempting to log in. This user should be a 
  member of the "people" 
* organizational unit, in the "mydomain.com" 
  organization (put your own 
* organization in here.
*/
dn = 'uid=' + request.userid + ',ou=people,o=mydomain.com';

/*
* Next, we call the connect method from the SSJS LDAP API, 
  and put a reference 
* to the LDAP connection into a variable.
*/ 
ldap = connect 
 ('ldaphost', 389, 'o=mydomain.com', dn, request.password);

if (ldap == null || !authenticate 
(ldap, request.userid, request.password))
 {
 // if we fail to connect or fail to authenticate the user, 
we redirect
 // to an error page
 disconnect (ldap);
 redirect ('errorpage.html');
 }

if (!isMember (ldap, 'o=mydomain.com', request.username,
'cn=users,ou=groups,o=mydomain.com'))
 {
  // if this user is not a member of the "users" group, 
  redirect to the 
  // error page
  disconnect (ldap);
  redirect ('errorpage.html');
 }

// if we haven't redirected yet, then user has 
successfully logged in.		
redirect ('success.html');

Creating a user

Let’s say you are a CSR, and you’ve logged in by executing code like the code above (except the group will be “csrs” instead of “users.”). You can create a user by entering the relevant information into a form and submitting to a page created with SSJS. The SSJS will, in turn, pass along your request to the Java middleware. In this example, the request will contain values for the following variables: first_name, surname, userid, and user_password. The new user will be created when the following Java code executes:

// we import the LDAP API from Netscape
import netscape.ldap.*;
...
// Since the LDAP directory is hierarchical, 
we must specify all the objects in
// the hierarchy that will contain the user.
String objectclasses [] = {"top", "person", 
"organizationalPerson",
"inetOrgPerson"};
String dn = "uid=" + uid + ",
ou=people,o=mydomain.com";
LDAPConnection ldap = new LDAPConnection (); 
 
try	{
// The application server must connect 
as a special "user"
	ldap.connect (3, "ldaphost", 389, 
	"uid=javaserver,ou=Application 
	Server,o=mydomain.com",
	"secret_password");

// Next, we create a set of attributes we want 
 the new user to have
LDAPAttributeSet attrs = new LDAPAttributeSet ();
attrs.add (new LDAPAttribute 
("objectclass", objectclasses));
attrs.add (new LDAPAttribute 
("givenname", first_name));
attrs.add (new LDAPAttribute 
("sn", surname));
attrs.add (new LDAPAttribute 
("cn", first_name + " " + surname));
attrs.add (new LDAPAttribute 
("uid", userid));
attrs.add (new LDAPAttribute 
("userpassword", user_password));

// Then we add the user to the LDAP database
LDAPEntry newEntry = new LDAPEntry (dn, attrs);
ldap.add (newEntry);

// Finally, we add the user to the "users" group, 
which identifies them
// as a user.
LDAPModificationSet mods = 
new LDAPModificationSet ();
mods.add (LDAPModification.ADD, 
new LDAPAttribute 
("uniquemember", dn));
ldap.modify 
("cn=users,ou=groups,
  o=mydomain.com", mods);			
 }

By placing the new user in the “users” group, we have given the user the ability to log into the “users” interface. Following this example, you could have a variety of different groups, each with different privileges. You can assign or remove the privileges from various users simply by reassigning them to the appropriate groups.

Conclusion

LDAP directory servers like the Netscape Directory Server give you all the power and flexibility you need to control access to your extranet or intranet. As you might expect, today’s LDAP servers are scalable, robust, and secure. The greatest advantage to an LDAP server, however, is probably the centralized nature of directory service: You can put all user information into a single database, and machines all over a highly distributed enterprise can utilize that single database.

About the author:

Jason Bloomberghas been coding, scripting, and programming Web sites since early 1995. He is now senior manager at USWeb/CKS, the leading Internet professional services firm but is best known for his JavaScript and Java games at The Rhodes Arcade. His book, Web Page Scripting Techniques, was published by Hayden Books in 1996. He has two children and lives in Atlanta, Ga.