For the ArsDigita Community
System, by Lars Pind on July 1, 2000.
Note, this is still experimental, so it's not part of
this release. It'll be rolled in as part of the ACS 4.0 release. If
you're interested in helping us test this, please contact me at firstname.lastname@example.org, and I can provide you
with the patch.
The Big Picure
Many companies have their own LDAP directory servers where they
centrally store information on all the users of their computing
equipment, including their user ids and passwords. We want to let
users of an ACS-based web site log in using the same user id and
password as everywhere else in their computing environment.
Currently, We do not stuff users into the LDAP directory. If
a new user is to have access to the site, he must first have an entry
created in the LDAP server by some other means.
If you want to know more about what LDAP is, I've actually
written up something about it.
The Medium-Sized Picture
An ACS installation is hooked up against one specific, trusted LDAP
server. Every user of ACS has to be known to this LDAP server, and the
have to live under some agreed-on base DN (e.g.
This software builds on the assumption that you want all the users
under the base DN to have access to this ACS installation. This is not
always reasonable, but since we don't deal with authorization, you'll
have to modify this yourself. We also assume that you have some other
means of maintaining the information in the directory. We don't
provide tools for that yet.
The login process goes like this:
- We ask for email and password. Since DN's are generally tedious to
type, we still rely on emails rather than DN. Since the user might not
have a row in the users table, we won't do the old-style "email first,
then check if he exists, then ask for password" login process.
- We search the LDAP directory for a user with this email address
and get back the DN. If there's no such entry, we deny access to the
user. If there's more than one, we're in trouble, so we dump an
error. If there's exactly one entry, we grab the DN.
- We do an LDAP bind operation with the DN just found and the
password provided by the user. If it doesn't succeed we complain that
the user typed in a bad password.
- After the bind, we check to see if we already have a row in the
users table with the DN. If we don't, we pull out the person's
name from the directory and insert a row.
Important Note: We still have the two special users
anonymous around. Since their
password is still checked against the password in the local database,
they pose a security risk. However, they're needed for setting up the
site. See the section on installation
below for more info.
Under The Hood
The attributes being searched on are
You might want to add other requirements. How to do that is shown in
a comment in
mail: email as typed in by user
The attributes being retrieved and stuffed into the users table are:
attribute||Description||Column in users table|
|Distinguished name, the primary key of the entry
|The person's first name
|The person's last name (surname)
|The email address
Again, you might want to get others. How to do this is shown in
We don't want to implement an LDAP client in Tcl, so we rely on Sun's
JNDI LDAP client in Java 1.2 running inside Oracle.
There are a few Java stored procedures to handle the interfacing
between ACS and the LDAP server. Here are their interfaces:
String getDnByEmail(String url, String base, String email)
String bind(String url, String dn, String password, String securityMechanism)
String syncUsersTable(String url, String dn)
There are a few parameters you need to set up, one in the general ACS
section, the rest in the LDAP section:
- Performs an LDAP search for an
inetOrgPerson with a
mail attribute that matches the email address given and
returns the DN if successful. If there's an error, the string "Error:
explanation" is returned.
- Performs the LDAP bind operation with the DN and password
supplied. It'll use the security mechanism specified in the server
ok if the bind was successfull. If not, it
- If the DN is already in the users table, it simply returns the
user_id. If it's not, it queries the LDAP server for the
attributes and puts them into the
email columns of the users
; what authentication method we use
; possible values are: internal, ldap
; The URL of the LDAP server, including ldap://
; The base DN under which all the users of this website resides
; Preferred security mechanisms seperated by space, e.g.
; simple, CRAM-MD5, DIGEST-MD5
Important Note: You must make sure you have a login
process with email and password prompt on the same page, i.e. the
following lines in the general section of your acs .ini file:
; use the old login process where email and password are on separate pages?
There are straight-forward Tcl wrappers for both the parameters and
the Java procs in
Patched /www/register Pages
The login process has been modified to accomodate LDAP
authenticaion. The following pages are affected: user-login,
user-login-2, deleted-user, restore-user.
- We assume that you already have the LDAP server running and that
you have your directory organization decided i.e., that you know where
the users of this website will be stored.
- Make sure you have the
ldap_dn column in the
users table. Here's the DDL to put it in:
alter table users add (
constraint users_ldap_dn_unq unique
- Load the Java code
It'll give you a bunch of warnings, but it should compile
nevertheless (look out for "source needs recompilation").
$ cd /web/yourservice/www/register/java
$ loadjava -user yourservice/password -resolve -verbose LdapLogin.sqlj
- Create the JSP wrappers in the database
$ sqlplus yourservice/password < ldap-authentication-wrappers.sql
- Set up the parameters, as described above in the parameters section.
- Bootstrap yourself as administrator:
- Log in as yourself using LDAP authentication, so that you'll have
a row in the users table.
- Then login as
system using the default password
changeme), and make yourself site-wide administrator
(visit /admin/ug, group type administration,
group site-wide administrators, add member).
- Then login as yourself again, and ban the users
anonymous, so people can't log in
Obvious enhancements that would improve the usefulness without
changing the assumptions are:
Bigger things that would change the assumptions:
- Store mappings from LDAP attributes to columns in our users table
in the same configuration tool thing. We'd want each of them to have
synchronization options or 'never', 'on_login', 'regularly', etc.
- Store additional attribute requirements for giving access to the
- Synchronization of the users table with their respective LDAP
entries. It could be per x number of logins or per x number of
- Allow us to create users and add them to LDAP. This is useful for
using LDAP to synchronize the users table between two sites, without
using LDAP for figuring out who should have access or not.
- Use LDAP for authorization purposes, too, e.g. to identify
site-wide admins, or simply by storing all of our user-group info in
the directory as well.