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 1/3"
- "FOSS Authentication System, Page 2/3"
- "FOSS Authentication System, Page 3/3"
