DACS is a light-weight single sign-on and role-based access control system for web servers and server-based software. DACS makes secure resource sharing and remote access via the web easier, safer, and more efficient. DACS is particularly well suited to providing single sign-on across organizational or departmental web servers, and to limiting access to their web-based resources.
Released under an open source license, DACS gives you:
|Get Information:||Overview; What is DACS?; About DACS; Features; Versions; FAQ; Documentation|
|Get DACS:||Download DACS|
|Get Started:||Tutorial; Tips and Examples|
|Get Help:||Technical Support|
DACS works with virtually any authentication method and unifies an assortment of accounts into a single identity. You can leverage the user accounts and authentication methods that you already use, or introduce new ones easily. Out of the box, DACS lets users authenticate using: DACS username/password, X.509 client certificate, self-issued or managed Information Card, one-time password, Unix account, Apache password files, Windows NTLM, ADS/LDAP, CAS, HTTP, PAM, Basic or Digest Auth, special URLs, two-factor authentication, expressions, and more.
Our highest priority is for DACS to remain a secure, stable, and well-documented system.
Once a user has signed on through DACS, he will be recognized throughout a federation of web servers.
While it shares many of the advantages of other single sign-on systems, DACS offers some unique features and is more efficient, and simpler to understand, customize, and administer compared to the heavy-weight, enterprise-level alternatives. If your single sign-on needs are modest, or if you are not even certain what they are, you should look at DACS. DACS does the hardest parts for you - all that you need to do is configuration and "look & feel" customizations.
Why reinvent the wheel? Creating security software demands specialized expertise. It is challenging to develop and keep current. Besides offering a complete single sign-on solution, DACS includes a toolbox of components from which other single sign-on systems and web site features can be built. It supplies authorization checking capabilities and user authentication functionality that developers need to get their applications working quickly, whether web-based or not. Many kinds of server-based applications can benefit from DACS tools. Its rule processing engine can be employed in a wide variety of applications, not only to provide fine-grained authorization testing. Configuration is flexible and programmable.
|For applications:||Authorization testing can be performed from the command line, allowing scripts (Perl, PHP, shell, etc.) to make data-driven access control decisions rather than code-driven ones. Authentication functionality is also available from the command line; programs can easily reuse existing user accounts, authentication methods, and user management tools.|
|For middleware and web services:||Authentication and authorization testing can be done through simple, REST-based web service calls, the DACS Java library, or a C/C++ API. DACS web services can return XML or JSON formatted documents.|
DSS is pleased to announce the availability of DACS 1.4.31. Problems reported with the interoperability of DACS 1.4.30 (mod_auth_dacs) and recent releases of Apache 2.2 and 2.4 have been corrected in DACS 1.4.31. Download links, errata, and additional information are here. It is important to review the Post-Release Notes before building DACS. All sites are encouraged to upgrade. Please report any issues you discover.
The next release is scheduled for late December, 2014.
DACS (and Apache) can optionally use Berkeley DB to store various information, such as passwords. It is worth taking note that starting with version 6.0.x, Oracle changed the Berkeley DB license from the Sleepycat License to the GNU AFFERO GENERAL PUBLIC LICENSE. For some analysis of this change, please refer to Oracle switches Berkeley DB license, Debian, Berkeley DB, and AGPLv3, and Oracle Quietly Switches BerkeleyDB To AGPL. DACS should continue to remain compatible with Berkeley DB 5.3, which was released under the Sleepycat License.
While no incidents have been reported, DACS releases may use versions of OpenSSL that may be affected by the TLS heartbeat read overrun bug, MITM vulnerability (CVE-2014-0224), or Security Advisory [15 Oct 2014]. DACS installations are advised to upgrade to OpenSSL 1.0.1i or newer. Also see this.
In early 2011, Microsoft announced that it would not support CardSpace (aka, Infocards and Information Cards) starting with Windows 8. As CardSpace has been the most widely available identity selector for using Information Cards, and other projects related to Infocards and CardSpace have folded, future releases of DACS will likely deprecate and eventually remove support for Information Cards. Support for Infocards within DACS, is no longer being actively maintained. You may find that other Infocard and CardSpace related projects have been terminated and their web pages are out of date or no longer available. See: On the Demise of CardSpace; Open Cardspace opportunity; Personal Reflections on the CardSpace Journey; From CardSpace to Verified Claims; Change will come: the present is untenable; The Clay Feet of Giants?; RIP, Windows CardSpace. Hello, U-Prove; and U-Prove.
Several GNU/Linux-based distributions, such as Debian and Ubuntu, include DACS as a package. Although DSS helps to facilitate those packages, we do not prepare, maintain, or test them for those specific platforms. The Debian project uses DACS for its single sign-on system for web services.
Apache 2.4 is now the preferred branch for use with DACS. Apache 2.2 has been designated as a legacy branch. Apache 2.0 is no longer supported by DACS, as that branch of Apache is no longer maintained.
Information about older releases is available here.
You can use Google to search this site, including the FAQ and technical documentation.