Authentication & Login sessions

[David Nugent <davidn@austel.net>]

I am currently working on a project to integrate LDAP directory
functionality into the FreeBSD operating system. The directory server will
be an integral part of the OS, providing a generic directory solution for
system tables currently maintained in flat files or specialist databases
(/etc/{master.}passwd, /etc/group, /etc/networks, /etc/protocols,
/etc/services etc. etc). The idea is that ultimately, a UNIX box with an
LDAP-based core will be easily configured as part of a cluster, by either
pointing the system or parts thereof at an external LDAP server, or the
machine's LDAP server is integrated into an existing DIT. There are other
benefits as well stemming from the fact that access controls in the
directory are independant from native UNIX credentials, so you may no
longer require root access to a machine to, for example, create a user or
change a password.

All of this solves the problems usually handled by NIS, but in a more
elegant and generic way. However, there are a number of hurdles to get
over first.

The primary problem is authentication. All processes are owned by a user,
as is the usual model in UNIX. Since authentication comes from the
directory, login sessions can therefore be tied to the specific object
against which the user was authenticated. The problem is, during that
session, the user will be accessing the directory (albiet hidden under the
libc API bonnet), and since we don't want to make the directory world
readable, the user requires *authenticated* access to the directory until
the login session terminates. However, I doubt whether reserving a tcp
connection for the life of each session is desirable, so a connectionless
protocol, or at least a pre-authenticated tcp network connection is
needed.

The problem can be solved using AF_UNIX type sockets instead of network
transport, which solves a lot of issues so far as credentials go. This
requires modification to the server to support of course, but this assumes
that the server is running locally which it may not, so I do not consider
this a viable option. I also looked at connectionless LDAP, but since it
(understandably) does not support authenticated access, it too is not a
suitable mechanism. The only option I can think of is to use kerberos, but
before requiring kerberos as part of this equation I thought I'd ask to
see if anyone has done any development along these lines, or perhaps
someone has other helpful comments.

Any thoughts or points will be appreciated.

David