MESSAGE
| DATE | 2004-04-26 |
| FROM | From: "Inker, Evan"
|
| SUBJECT | Subject: [hangout] A Standardized Open Source Network Authentication System
|
A Standardized Open Source Network Authentication System
By Van Emery - Posted on 2004-04-26 06:24:05
at OSNews [http://www.osnews.com/]
The open source community has mastered many challenges and has been
successful in numerous areas. However, there is one glaring weakness that
needs to be remedied.
FOSS Authentication System, Page 1/3
Introduction
Without progress in this area, open source in the enterprise will always
play second fiddle to Microsoft, Novell, and other corporate computing
entities. What is this critical weakness? Lack of support for Internet
Explorer and MS Office? Hardware compatibility issues? Retraining users?
No.
The critical weakness relates to a very basic function of any network
operating system. That weakness is the lack of a standardized, secure,
interoperable network authentication system. This is a very real stumbling
block to the adoption of open source in the enterprise.
"But wait!", you say. "A stock *BSD or GNU/Linux system has hundreds of
security tools! Compared to Windows XP, my open source workstation is more
secure, has more security tools, and is infinitely more flexible! What about
S/KEY Kerberos, OpenLDAP, IPSec, OpenSSL, OpenSSH, RADIUS, PAM, GnuPG, and
Samba 3?"
Big deal.
By default, your system uses flat files. It does not use secure,
network-based authentication. "But that can be installed and configured!",
you say. Sure it can, but it always ends up being a customized,
site-specific solution that requires lots of time and effort to test,
document, setup, and maintain. Making multiple Linux distributions and
Unices work together is a time-consuming nightmare. Do organizations
typically do lots of in-house development work to make sure that web
browsers and web servers on their intranets can talk to each other? Do they
develop custom routing protocols for their internal networks?
No. So why do we put up with this for network authentication?
IT managers want to be able to install servers and desktop client machines
on their network that securely authenticate users against a centralized
database. This should be a straightforward procedure. Until there is a
standardized, interoperable, community and industry supported network
authentication system included with most open source operating systems,
Microsoft will continue to rule the enterprise.
The Problem Described
There are two issues that need to be solved in a network authentication
system for Unix-like operating systems:
global naming
authentication
Global naming has to do with storing globally unique UIDs, GIDs, usernames,
groupnames, and other network-wide information such as a user's login
directory and preferred shell. This can be handled by protocols like Hesiod,
LDAP, and NIS/NIS+. This data is sometimes called directory information.
Authentication is the process of actually allowing (or not allowing) a user
to login to a host or access a resource. Authentication can be handled by
many protocols, including TACACS+, RADIUS, and Kerberos. In addition,
authentication systems should be able to log authentication transactions.
For the remainder of this article, "network authentication system" will
refer to both naming and authentication, since both are necessary to login
to Unix-like systems and to access resources.
Microsoft, Novell, Sun, and Apple already support unified network
authentication, and have been doing this for a long time. As long as you
exclusively use the vendor's proprietary system, all of your hosts will play
together nicely. Microsoft, Sun, and Apple can utilize Kerberos and LDAP in
their current systems. Novell is working on a Kerberos interface to their
successful eDirectory system, and they can already authenticate Linux hosts
to eDirectory via LDAP.
What we need is a system that is standardized to the point that any
GNU/Linux or *BSD based system can be easily configured to use a standard
network authentication scheme. I should be able to configure any common open
source operating system to use centralized naming and authentication
services after editing no more than two config files. It should just work.
In the Linux world, there is the Filesystem Hierarchy Standard (FHS) and the
Linux Standard Base (LSB). These standards help all distributions work
together nicely, and make life easier for application developers. Shouldn't
we have a standardized network authentication system? Having such a system
would give IT managers more choices, prevent vendor lock-in, and make life
easier for administrators and users.
For example, let us look at OpenSSH. OpenSSH runs on almost any Unix-like
host, binary packages are available for most operating systems, and it
allows terminal communication and file transfer between any two hosts.
OpenSSH is ubiquitous. It is used as secure transport for an amazing number
of protocols and applications. Wouldn't it be nice if you could depend on
your network authentication system to have the same amount of
interoperability and flexibility between different Linux distributions and
Unix flavors?
FOSS Authentication System, Page 2/3
Solution
If IT vendors continue to develop their own special authentication systems
and organizations using open source technology continue to "roll their own"
custom authentication schemes, only Microsoft wins. An open source
alternative is imperative.
I would like to see the open source community develop and promote a
standard, open, easy-to-deploy network authentication system. The community
should put funding, muscle, and top developers behind this effort. Obtaining
corporate support may also be a good thing. Sun, Novell, and Apple have
already done quite a bit of work in this field and could lend enormous
credibility to the project. However, the project must stay completely vendor
neutral and utilize existing open standards to the maximum extent possible.
For lack of a better term, I will call this system the Open Directory and
Authentication System, or OpenDAS.
Key protocols/applications/functions which should be able to use OpenDAS for
naming and authentication:
Host logins
Name Service Switch (NSS) lookups called by programs on the client
E-mail (POP3/IMAP4/SMTP)
Web (HTTP/HTTPS/WebDAV)
Network File Systems (NFSv4, OpenAFS)
File Transfer (FTP, SFTP, SCP, rsync)
Remote Terminal (SSH, TELNET, RLOGIN)
News (NNTP)
Chat (IRC)
Instant Messaging (XMPP/Jabber)
Printing (IPP)
These are just examples of the types of applications and protocols which
could be supported by OpenDAS.
What does an IT organization gain from a system like this?
Unified sign-on (or single sign-on if certain technologies like Kerberos 5
are used)
Centralized user and group administration
Global password and account policy enforcement
Enhanced security
Vendor lock-in avoidance
Ease of system configuration/deployment
True choice in client and server operating systems
The server side of the system should be relatively simple to install, setup,
and maintain. All the components would be integrated and work together
nicely. Excellent documentation would be included. It should be vendor/OS
independent, and allow replication and clustering for redundancy. Standard,
scriptable command-line tools should be available for administering the
servers. A standardized administrative web UI should also be developed
(think of SWAT for Samba), which would obviate the need for installing a GUI
on the OpenDAS servers. If installation and configuration is a grueling,
arcane process, expect the adoption rate to be very low. Keep configuration
simple, and standard.
It should only take a few moments to configure the client side of OpenDAS.
It should work "out of the box" with Debian, Slackware, Fedora Core, Red
Hat, SuSE, Mandrake, FreeBSD, etc. In other words, the client-side programs
should be part of the base operating system release. Documentation should be
excellent.
In addition to supporting open source GNU/Linux and *BSD operating systems,
providing clients for Windows, Mac OS X, and commercial Unix systems should
be a priority. This will speed the acceptance and adoption of standardized,
open, network authentication systems in the enterprise.
Components
Which components should OpenDAS be based on? There are many options, but we
can look at what large IT vendors are deploying and what some organizations
using open source solutions have already done. Utilizing existing open
source projects that are relatively mature should be explored first.
For example, we could construct the system from the following protocols and
components:
Kerberos 5
NTP
OpenLDAP(LDAP)
PAM
OpenSSL(TLS/SSL)
Perl
Kerberos is used for authentication, NTP is used to keep all of the client
and server clocks synchronized. LDAP is used for global naming and directory
information. PAM is used on the client to allow applications to make calls
to different authentication sources (like Kerberos) in a specific order,
rather than having to hard-code authentication calls. OpenSSL can be used to
encrypt plaintext authentication data or sensitive directory information.
Perl can be used to integrate all of the server-side
administration/configuration tools and processes.
SASL, GSS-API, and other protocols may be utilized as well. In this case,
though, fewer is better.
The design should be such that a user with root access to an OpenDAS client
machine cannot compromise the server-side authentication and naming
infrastructure. In other words, there are no shared secrets between OpenDAS
clients and OpenDAS servers.
On the OpenDAS server side, it may be wise to use some type of modular
framework, so that adding things in the future like token cards or biometric
information would be possible.
In order for OpenDAS to gain traction in the enterprise, all major open
source operating systems would need to include the client software in the
base install. On the server-side, the OpenDAS packages should be available
as easy-to-install binary packages from the OS distributor's CD or HTTP/FTP
site. Automated, dependency-checking installs would be available for FreeBSD
in the "ports" collection and for Debian in the APT repositories. RPM-based
distributions could use Yum. It should be as easy to find and install
OpenDAS as it is to find and install Samba.
Some people will argue that we can implement this type of OpenDAS today with
Samba 3, or some type of Active Directory clone. However, I believe that the
open source community can do better than simply mimicking Microsoft's
proprietary scheme, which can be changed at any time. The system should be
completely open, and designed primarily for open source operating systems.
Being an open specification, commercial Unix systems could interoperate with
the new standard. Mac OS X and Windows machines with OpenDAS client software
could easily be added to the network.
FOSS Authentication System, Page 3/3
Conclusion
If IT managers could add any Unix-like OS to the network with no
authentication interoperability worries, then enterprise adoption of
non-Microsoft platforms would accelerate.
Concerning the relative importance of this task in the hierarchy of open
source projects:
It is more important than new wireless card drivers
It is more important than adding IPv7 support to the Linux kernel
It is more important than supporting 256 CPUs
It is more important than 3D video support or gee-whiz sound
Successful completion of a project like OpenDAS would push open source into
the enterprise and the data center faster than many of the other projects
that are being funded and pursued.
In short, centralized authentication and naming would become standardized,
commoditized, and ubiquitous. This might be bad news for Microsoft and
Novell, but everyone else would benefit.
The open source community has pulled together on many projects and
standards. This particular challenge: developing, standardizing, promoting,
and commoditizing an open source network authentication system, is both
possible and practical to pursue.
This is a worthy goal. Let us join forces to accomplish it.
Links and References
Apple
OS X Server ships with OpenDirectory
[http://developer.apple.com/darwin/projects/opendirectory/], which uses
OpenLDAP and Kerberos 5. The server can also be configured to authenticate
to other systems, such as NIS, eDirectory, and Active Directory. Regular OS
X machines ship with MIT Kerberos, kerberized applications, and LDAP
support.
Sun
Included with Solaris 9 and Solaris 10:
Kerberos 5 KDC
Sun One Directory Server
LDAP Support in Solaris Management Console
Secure LDAP Client
Solaris 9 Security Features
[http://wwws.sun.com/software/solaris/sparc/solaris9_features_security.html]
Solaris 9 Manageability Features
[http://wwws.sun.com/software/solaris/sparc/solaris9_features_manageability.
html]
Novell
Novell's eDirectory [http://www.novell.com/products/edirectory/] uses LDAP
and works with Linux, Windows, Solaris, AIX, NetWare and HP-UX.
Open Group
The Open Group's DCE [http://www.opengroup.org/dce/] utilizes LDAP and
Kerberos.
OpenLDAP
http://www.openldap.org/ [http://www.openldap.org/]
MIT Kerberos 5
http://web.mit.edu/kerberos/www/ [http://web.mit.edu/kerberos/www/]
Heimdal Kerberos 5
http://www.pdc.kth.se/heimdal/ [http://www.pdc.kth.se/heimdal/]
Pluggable Authentication Modules (PAM)
http://www.kernel.org/pub/linux/libs/pam/
[http://www.kernel.org/pub/linux/libs/pam/]
About the Author:
Van Emery is a data Network Engineer/System Administrator. Currently he is
working as a system administrator at Academia Sinica in Taipei, Taiwan. His
homepage is here [http://www.vanemery.com].
( Original Story URL at http://www.osnews.com/story.php?news_id=6837 )
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
****************************************************************************
____________________________
NYLXS: New Yorker Free Software Users Scene
Fair Use -
because it's either fair use or useless....
NYLXS is a trademark of NYLXS, Inc
|
|
