Re: LDAP and Single Sign-on

["Mark Wilcox" <mark@mjwilcox.com>]

At the University of North Texas, we may not be a corporation in the sense
we don't end in ".com", but our user base is a lot larger than your average
corporation (I have in the neighborhood of 30-60,000 user accounts) & also
distributed (I have a few thousand users who never visit campus).

 we use LDAP for three things currently:

1) as our depository for electronic identity
        When a student or faculty/staff has a record created into our
mainframe systems, they have a record created in LDAP which generates their
enterprise userid. This userid can be fed to different applications that
need user data, in particular an user's electronic identity. While not truly
single signon, this does allow us to give a user a single electronic
identity across multiple systems (including Novell NDS, WebCT distance
learning software, UNIX NIS, Remedy Helpdesk and a few other disparate
systems). This is our "master" server for whether a person should have any
type of electronic access at UNT or not.

2) as an user authentication system
       Currently we use LDAP for our library's restricted Website (using
Netscape's Enterprise server's LDAP capabilities) servicing around 30,000
unique users.  I also use LDAP for authentication system for a few Web
database applications including one that services 1000 unique users per
semester. We will be adding LDAP authentication support to WebCT by end of
spring. We are investigating using it as our replacement for NIS as well as
our authentication system for our Web enabled mainframe applications.   Even
if we don't use LDAP as the exact authentication system (for example we use
Kerberos instead), it will be our primary electronic identity system & will
still serve an important function as a directory service.

3) directory service for our bulk mail system
     Of course we use LDAP for our traditional directory services (e.g.
email white pages). Starting in Spring 2000 our university will begin to use
e-mail as an official communication system (as in possibly sending grades
via email instead of snail mail). While sending mail to all students is
relatively easy, we need to control exactly who can send mail and also
provide a query mechanism (e.g. send to all freshmen who are majoring in
biology or to allow faculty to send mail to the students in the classes they
teach). We are using LDAP for both the query system (e.g. name, mail
address, major, college, classification, courses they are enrolled in, etc
are stored in a student's LDAP entry) and for access control (based on LDAP
groups & also mimicing our university heirarchy in a branch of the server).
Currently this done only via a Web interface, but eventually we will have an
email interface, so that the chancellor (well more likely, his secretary)
could look up a particular group from his mail client & send a message.

I've had our library using LDAP user authentication for at least 18 months
(maybe 2 years, time flies when you're having fun ;).

We use Netscape Directory server running on Solaris for our primary LDAP
server (and I've been using Netscape's LDAP servers since late alpha of
version 1). I've used openLDAP for some testing but would wait for version 2
before doing anything else. NDS 8 is probably a good choice for user
authentication if you already have a large NDS base installed (which we do
as well, but there are a variety of political/sociological reasons why I
don't want to use it at UNT).

You probably noticed in step 2 that I said investigating LDAP for
authentication. Well we know LDAP pretty well at UNT, but you have to way
all of the pros and cons for your user authentication system. LDAP is not
really an authentication system, it's a directory access protocol, which we
happen to kludge an authentication system using LDAP's security mechanism.
At the very least an LDAP authentication system uses at least 2 TCP/IP
connections for every user authentication request. It also by itself doesn't
provide things like encryption, password expirations, etc. Some LDAP servers
(like Netscape's) provide things like password expirations, but you're LDAP
clients have to know to access that information.

That's not a knock for or against LDAP, but just the way it is. :) However,
I should point out though that LDAP can manage X.509 digital certificates
which is an important consideration since I think in the near future
digitial certificates will play a bigger role in user authentication.

The important concept is to first build a commonly accessible directory
service.

One thing you probably noticed between my post and some others is the
concept of using it first as a datastore for an unique user identity. That
is a very key step for an organization contemplating single signon because
for you to have single signon you need to know who's supposed to have access
in your organization & then determine what they are authorized for & for how
long.

And well you're basically looking at my public documentation so far of what
we've done. This is a relatively new field and with Y2K now really knocking
at our door, I doubt much new development has gone within the past year.
Post Y2K I think you'll see a lot more development in this area.

Mark



-----Original Message-----
From: Tod Thomas <tthomas@chubb.com>
To: openldap-general@OpenLDAP.org <openldap-general@OpenLDAP.org>
Date: Tuesday, November 09, 1999 10:01 AM
Subject: LDAP and Single Sign-on


>I am interested in getting an idea of how many organizations have
>implemented LDAP as well as those that may be using it for single sign
>on.  I have the following questions:
>
>* Has anybody implemented LDAP in a production corporate environment ?
>* If so what was its introduction expected to accomplish? How many users
>does it serve?
>* Has anyone used it to provide corporate wide single sign-on?
>* If so, was that a success and how heterogeneous was the login
>environment you started with?
>* And lastly, are there any sites that have this kind of information
>documented already that anyone can point me to ?
>
>Thanks in advance for any input.
>
>Tod Thomas
>
>
>
>
>