|
|
Version 1.4.52
8-Dec-2024
If you are technically inclined, you can get a feel for the kinds of things that DACS can do from the Tips and Examples. And for technical information about how to use the access control rule evaluation engine from the command line, please refer to dacscheck(1); to invoke authentication from the command line, please refer to dacsauth(1). Much of the apparent complexity of DACS disappears when its access control component is used as a stand-alone tool; for example, it is decoupled from virtually all aspects of authentication and DACS configuration processing.
DACS, the Distributed Access Control System, is software that can limit access to any content served by an Apache web server. In other modes of operation, DACS can be used by other web servers and virtually any application, script, server software, or CGI program to provide access control or authentication functionality.
It is probably best used to transparently facilitate selective access to content and services provided by Apache, including static web pages, files and documents, CGI/ASP programs, Java servlets, database queries, and generated images. An administrator configures DACS to grant access to some users and deny access to others.
DACS is:
You can think of DACS as an authentication framework plus an authorization framework. The authentication framework consists of an assortment of authentication methods (plugins) that can be combined and extended, including methods that will work with the usernames and passwords that you probably already use. The authorization framework includes a general-purpose rule-processing engine. A programming language, similar to Perl but much smaller, allows run-time configuration processing and access control rule evaluation to be programmable. As a result, system configuration is highly flexible and its behaviour can be easily customized. A collection of command-line utilities and web services is supplied to administer, customize, and monitor the system. With a handful of configuration and data files, these pieces create a complete and unified system, DACS.
The authentication and authorization frameworks, and many of the other pieces, can be used on their own, separately from the larger DACS system, to solve a wide range of problems that may not have anything to do with single sign-on, authentication, web services, or authorization.
For web site administrators:
For software developers:
Our intent is for DACS to be suitable for almost any application consistent with its design philosophy.
Credentials expire at a time determined when they are created. They are destroyed when the user's browser terminates, or by request through a DACS sign-off web service.
A user can be associated with more than one identity at the same time.
Each request for a web resource causes DACS to search a set of access control rules for the best rule to apply. If that rule grants access, then the web service request will proceed normally, otherwise the request will be denied.
An access control rule can assign responsibility for deciding authorization to another set of rules. This feature lets users other than a DACS administrator manage access control rules for particular web resources.
A DACS access control rule is able to grant unauthenticated (anonymous) access, or access that depends on some other type of context, such as the IP address from which a request is sent.
DACS makes available a very wide selection of authentication methods that can be used by Apache. With each subsequent service request after authenticating, a user's identity is made available to Apache and exported in the usual way through Apache's REMOTE_USER environment variable. Temporary identities that have a limited but renewable lifetime, for example, can be created easily.
DACS makes it easy to express powerful access control rules to determine whether a particular service request should be granted or denied. Access control rules can make decisions based on the identity of the user making the service request, details about the service request, and the overall context in which the request is being made. Very complicated decisions can be punted to an external program. You can continue to use any existing Apache Basic or Digest authentication methods. Rules can easily be written to grant access to one group of users but deny access to all other users, for example.
Because web service arguments can be inspected by access control rules, the kinds of security functions to which DACS can be applied are virtually unlimited.
In many cases, DACS can be configured to "catch" various abnormal conditions, temporarily redirect a user to a different web page, and then cause the original request to be reissued. For example, a request for a web resource that requires each user to acknowledge a licensing agreement or copyright notice can be intercepted; if the notice has not already been acknowledged by the user, the user can be presented with the notice and, following acceptance, be redirected to the web resource.
Each jurisdiction is assigned a unique name within a federation, by convention a capitalized, short abbreviation (e.g., EARTH or VULCAN). Each authenticated user is identified by a DACS username consisting of the name of the authenticating jurisdiction and a username within that jurisdiction (e.g., EARTH:kirk or VULCAN:spock).
An authenticated user assumes a federation-wide DACS identity; any jurisdiction can understand credentials produced by any other jurisdiction within the same federation. Therefore, a user only needs to be authenticated once to access web services at any jurisdiction using that identity. This is known as single sign-on.
If your federation consists of many jurisdictions, DACS can also provide federation-wide identities for all users with a single sign-on capability and give each jurisdiction the ability to grant or deny access to its web services based on user identity, group membership, and so on.
In its delegated mode of operation, a DACS-enabled web server can provide single sign-on and access control for other web servers, themselves DACS-enabled or not.
DACS may also be explicitly invoked by a web service, or by applications outside of web services for that matter. This capability might be used to provide fine-grained access control or, in situations where the web server cannot be modified, as an alternative to delegated authorization. DACS provides a feature whereby it can be asked to simply test whether it would allow a given web service request if it were issued by a particular identity.
There are many ways to configure a solution, but there will be at least one authentication service and some set of web services of interest provided by one or more web servers. Let's proceed by describing the most straightforward configuration.
Each web server that provides DACS-protected web services will be a jurisdiction in the federation. Each jurisdiction will put access control rules in place, restricting access to its services to authenticated employees. Each jurisdiction providing a service remains completely in control of who it provides the service to.
Now, after being authenticated just once by any of the federation's authentication services, any employee will be able to access any web service on any of the departments' web servers. If required, it is easy to limit some employees to particular jurisdictions or services. An outsider attempting to gain access will be denied; simple changes could be made to grant unauthenticated access to public services if that is desired.
Adding a new jurisdiction is simple. Giving access to a new department may be as simple as being able to authenticate its employees and withdrawing access to an employee can be done by refusing to authenticate him or explicitly revoking his access.
Of course DACS can be used in exactly the same way in an Intranet environment and with web servers internal to an organization.
For another example, please see What is DACS?.
If in addition you want to restrict access to resources provided by your web server based on the identity of the user making the request (even at the course level of authenticated vs. not authenticated), this can be achieved by writing access control rules.
Rather than dictating policies, DACS's goal is to provide secure, flexible, extensible, and highly available mechanisms. These mechanisms are themselves invoked as web services and allow each jurisdiction in a federation to determine its own authentication and access control policies.
A DACS federation has a central, administrative authority (one or more persons to assign names to jurisdictions and manage cryptographic keys, for example) but there do not need to be any centralized web services. Information associated with a user's login is not maintained by DACS services and most DACS services can be invoked anywhere within a federation with the same effect. DACS's operation is therefore decentralized and highly available.
DACS is implemented as a collection of web services, commands, and an Apache module rather than a monolithic application. Many features must be requested at the time DACS is built and enabled in its run time configuration file. Features that are not required can easily be disabled, by not building them into DACS, by explicitly disabling them in the run time configuration, by setting file permissions to disallow access, or in the case of DACS's web services, through appropriate access control rules. It is not difficult to build and deploy a minimal DACS configuration. Disabling DACS entirely is not much harder than restarting Apache.
DACS was originally devised as a system that would:
As the design and implementation evolved, it also became necessary for DACS to be:
To the best of our knowledge, to date no other system exists that meets all of these requirements.
DACS distinguishes itself from similar software in several significant ways:
There is some additional discussion about these issues.
DACS has its own framework for federating a collection of jurisdictions. It creates federations using services and protocols specifically designed and implemented to meet the DACS requirements. As a result, interoperation among the federation's members is light-weight and efficient, and DACS includes single sign-on functionality.
Our commitment to keeping DACS as simple as possible includes working to better align DACS with the REST-based approach to web services. Most DACS web services can be directly invoked from any browser or using a simple link. We concur with Tim Bray when he says:
First, instead of trying to define APIs across networks, you specify the messages that are exchanged, and second, that XML is a decent data format for the messages. I personally believe both, and this is the only sane way to integrate applications in a heterogeneous environment. Unfortunately, the attempt to standardize this excellent idea, under the WS-* label, has gone off the rails. It is insanely complex, baroque and abstracted, and implementing it requires reading hundreds of pages of poorly written, unstable specs and dealing with ferocious inter-vendor politics. Fortunately for the future, there is a rock-solid base of proven, efficient, scalable, standardized technology: HTTP, XML and so on, and some very clear guidance on how to do things: REST. So, I expect WS-* to fall far short of expectations, but Web Services, done more simply, to be the default way of doing things in the future.
At release 1.4.23, DACS included support for Information Cards. Within that limited context, SAML formatted tokens were used for interoperability reasons. CardSpace and Information Cards were effectively killed off in 2011, and support for them within DACS was deprecated a few years later and is no longer officially supported.
In some situations it may be necessary for independent DACS federations to themselves federate so that they can recognize each others' user identities. DACS includes the notion of "affiliated federations" by which the single sign-on feature can be used among a set of cooperating federations. It defines a simple protocol, implemented by dacs_auth_transfer(8), by which a user can export his DACS identity to any other system (whether DACS or not) or import an identity from any other system (again, whether DACS or not).
Similarly, the members of a DACS federation may need to interoperate with a SAML-based federation; dacs_auth_transfer(8) or perhaps dacs_auth_agent(8) may be sufficient in some cases, but several other avenues are under consideration for SAML support in DACS.
Besides the issue of its relative complexity, as software developers we share concerns regarding potential intellectual property claims [1, 2, 3, 4, 5, 6] with respect to SAML. Although this situation may be slowly improving [7, 8], it is happening in bits and pieces.
Also, we have no interest in positioning DACS as a universal identity management system or for it to be used to provide large-scale identity representation for the Internet at large. We have fundamental concerns about the privacy implications of such a system (some related comments are here):
"You have a single place where you give everybody an identity." Indeed - provided that everyone is willing to let Microsoft own their identity.If assigning Internet users a single identity strikes you as a harmless enough idea, perhaps you should consider the downside of putting all of your eggs in one basket [9, 10].
--- Microsoft man seeks to re-engineer the Web
Group membership is determined at run time.
Roles are typically designed with an organization's structure in mind (such as: Human-Resources, Accounting, Administration/IT, and Computer-Science/IT), based on position within an organization (such as: faculty, staff, student, and guest), or both.
Access control rules can be written to grant (or deny) access depending on the requesting user having specified roles; rather than explicitly listing all staff members in access control rules, for example, staff members can be assigned the role staff and rules can simply test if the identity making a request has that role. Such rules do not need to be changed when staff members are added or leave.
A role is implemented as a special type of group. As part of the authentication architecture, roles are assigned to a user by his jurisdiction at authentication time and become part of a user's credentials. A roles module is configured to obtain a user's roles, which can be obtained in a variety of ways, such as by looking them up in a file or database, or by running a program or consulting a web service.
Here are just a few examples of policies that can be specified:
These kinds of constraints, and many others, can be combined in many ways.
Here are two very simple access control rules:
<acl_rule status="enabled">
<services>
<service url_pattern="/foo.html"/>
<service url_pattern="/bar.html"/>
<service url_pattern="/cgi-bin/dacs/public/*"/>
</services>
<rule order="allow,deny">
<allow>
user("any")
</allow>
</rule>
</acl_rule>
<acl_rule status="enabled">
<services>
<service url_pattern="/cgi-bin/dacs/baz.php"/>
</services>
<rule order="allow,deny">
<allow>
user("EARTH:kirk") or user("%VULCAN:admin")
</allow>
</rule>
</acl_rule>
The first rule applies to two specific objects (/foo.html and /bar.html) and all objects having the URL-path prefix /cgi-bin/dacs/public. Any user, whether authenticated or not, is granted access.
The second rule grants access to the script /cgi-bin/dacs/baz.php only to a particular user (EARTH:kirk) and to all members of a group (%VULCAN:admin).
At present, DACS administrators must understand and use this XML representation. A GUI-based tool is being developed to simplify DACS administration tasks, including creating and maintaining access control rules.
DACS can control access to a program that has its own authentication or authorization methods because DACS does its work before the program runs. For example, DACS can be used to filter requests to a database application. The application does not need to be changed in any way and is unaware that DACS is even being used. Requests that are denied by DACS never reach the application because the application is not executed. Requests that are granted by DACS allow the application to run and it may perform its usual authentication or authorization procedures.
DACS does not copy user account names or passwords or other material used for authentication outside of the process of authentication. DACS does not copy or cache web site content. Communication over untrusted channels is always kept secure by using SSL/TLS.
A federation is likely to require each of its jurisdictions to agree to a set of business practices to ensure that the security and integrity of the federation as a whole is maintained. Jurisdictions are required to keep encryption keys secure, for example.
Users are required to take common sense steps to ensure that their DACS credentials are kept secret and may have to upgrade their browsers from time to time. System administrators are required to upgrade software as necessary in response to security-related bugs.
While DACS takes steps to prevent DACS user identities from being appropriated or modified, it does not claim to be a "highly secure" system. It aims to provide security in line with that of banking, financial services, and Internet commerce web sites, which are also accessed using standard browsers. There is no requirement for DACS to protect user identities beyond what those kinds of systems do.
Information provided by a user to establish his identity is directed to the DACS authentication web service at that jurisdiction (the user might select the jurisdiction from a menu). The DACS authentication service then invokes an authentication module (a DACS web service configured at the jurisdiction), forwarding it the information provided by the user.
In the general case, a simple XML-based protocol is used between the DACS authentication service and an authentication module. The authentication module tells DACS whether or not the user has been successfully authenticated and it provides DACS with a name that identifies the user within the jurisdiction, perhaps an account name or email address. While the resulting credentials exist and remain valid, the user is identified throughout the federation by the combination of the jurisdiction name and the username (e.g., EARTH:kirk or EARTH:kirk@ussEnterprise.net). Each user is usually assigned a unique name but this is up to the jurisdiction.
Some authentication modules are also built-in to DACS; they are called like functions rather than web services.
The DACS architecture supports many styles of authentication:
In addition, a user can be authenticated at authorization checking time, non-interactively or interactively (using HTTP Basic authentication to obtain a username and password), with any compatible DACS authentication module, or expression evaluation. This allows DACS to work with very limited user agents, even those that cannot handle cookies or redirection.
The means by which the authentication module authenticates a user is left completely open; DACS does not care! The authentication module might consult a private table of users from a file, use standard system library functions, perform a database or LDAP query, etc. In this way, DACS authenticates a user by taking advantage of an organization's existing authentication mechanisms. No new accounts need to be created for DACS users, no new account administration is required, and lists of account names do not need to be revealed. Should accounts be created specifically for DACS, they do not need to have any other resources or configuration associated with them (e.g., there's no need for a home directory). Furthermore, there is no requirement for jurisdictions to adopt a common authentication technology, whether it be PKI or any other.
A jurisdiction is completely free to deny authentication for a particular account (e.g., root or administrator) or to create accounts specifically for use with DACS and that are otherwise invalid within its organization.
DACS includes a set of authentication modules that provide local authentication services. The DACS authentication framework allows flexible configuration of these authentication modules and can accommodate the composition of modules using configuration directives similar to that defined by Pluggable Authentication Modules (PAM) [1, 2]. For example, it's possible to configure DACS to try several authentication methods in sequence and require all of them to succeed, or to require that only one of them succeed.
Strong authentication is available using one-time password token devices, optionally with a separate DACS password (or PIN) associated with the device.
Any new authentication style that can be implemented as a web service by a jurisdiction can be added to DACS.
If a jurisdiction chooses to authenticate a user using an X.509 certificate, it must merely be able to validate a client certificate passed to it by DACS and map the certificate to a DACS username. In cases where the web server is configured to do this validation itself, DACS may not need to repeat this validation. If the jurisdiction is already using this certificate to authenticate its owner for other purposes (e.g., web access), it must also already have the necessary means of validating the certificate.
DACS obtains the X.509 certificate through its SSL/TLS connection with the user. It is possible to use self-signed certificates if a jurisdiction (or the federation) chooses to operate its own certificate authority.
Using cookies to store authentication state (credentials) is primarily a convenience and efficiency measure, so they are important even in a single jurisdiction federation.
The use of HTTP cookies and common domain name suffixes is not integral to the system architecture, however. In environments less general or with different requirements than what DACS was designed for, alternatives to HTTP cookies may be desirable or even necessary. For this reason, other methods of conveying DACS identities are supported, such as through the HTTP Authorization header (RFC 2617) or the HTTP extension-header mechanism (RFC 2616). In fact, DACS can be customized or extended to accept any secure means of associating DACS identities with incoming web service requests.
The pre-authorization checking authentication mechanisms completely eliminate cookies, although that introduces some significant limitations.
You can continue to use Apache's authentication modules if you like - DACS can import identities that they establish - together with the authentication mechanisms provided directly by DACS. DACS can happily coexist with Apache's other access control and authentication modules, so legacy configuration can remain unchanged.
DACS can use RFC 2617 HTTP authentication (Basic and Digest), which is supported by most web browsers and HTTP client libraries. A username and password obtained by DACS through this mechanism can be validated using any suitable DACS authentication method. This is done without any extra configuration of Apache and changed without having to restart Apache.
Web administrators familiar with mod_access will recognize similarities between its syntax and that used by DACS, so converting existing access control specifications to DACS should not prove difficult. We believe that equivalent DACS access control specifications are simpler and easier to understand, and it is possible to express much more complicated constraints.
DACS access control functionality is integrated with Apache through the mod_auth_dacs module, using the standard Apache module interface, but most of the work is done by a separate program (dacs_acs(8)). DACS authentication and other DACS web services are run entirely outside of Apache, and access to them is controlled by DACS. This simplifies debugging and means that if DACS malfunctions or crashes, Apache should continue to operate normally.
One idea is to use delegated authorization.
Another alternative is to employ dacscheck(1), but doing so will require some programming. Instead of accessing web resources directly, you would write a program that would perform an authorization check and then retrieve or execute the requested resource. While this may be an adequate approach in simple cases, it can be tricky to do correctly and securely in general, and results in more complicated URLs. For instance, if you wanted to apply this technique to /index.html, you would move that file to an area not accessible to the web server, and use a URL like http://example.com/cgi-bin/dacswrap/index.html for it, where dacswrap is your program. Your program would do an authorization check, and if access is permitted, retrieve /index.html from wherever you have stashed it and return it in an appropriate HTTP response. Things are much more complicated if your program must also handle executing CGI programs.
Yet another idea, applicable only to requests for programs, is to modify the program to do an authorization check itself when it starts up.
If you want transparent and secure access control for web services, without having to do any programming, you will need mod_auth_dacs. If you are only interested in fine-grained authorization checking, which inherently involves programming, then mod_auth_dacs is not used and therefore not needed.
Another possibility might be to use two hosts, one with mod_auth_dacs and one without it. Programs running on the latter host would make web service requests to DACS running on the other host.
Solaris (specifically, OpenSolaris (SunOS 5.11, x86)) is no longer officially supported and testing is not done on that platform. Note: There is uncertainty about the future of OpenSolaris [1, 2, 3, 4].
Testing with Cygwin is no longer done. DACS was being used on Solaris 8 and 10 SPARC platforms until fairly recently, but those platforms are not officially supported anymore either.
DACS is tested and run with Apache 2.4 Support for Apache 2.2, which has been designated as a legacy branch, has been terminated. Also, Apache 2.0 is no longer supported by DACS. DACS may still work with later versions of Apache 2.2 and 2.0, but they are deprecated and unsupported. Apache 1.3 and IIS have never been supported.
Design and implementation of a simple, general purpose mechanism to conduct this type of registration procedure is currently in progress.
After installing DACS, a basic DACS configuration involves:
Once the basic configuration is operational, it is not difficult to experiment with DACS and extend the configuration.
The resulting Apache/DACS configuration may even meet your immediate needs with few changes, apart from any new web pages that you may require (such as custom login/signout pages).
If you are not interested in integrating DACS with Apache, dacscheck(1) and dacsauth(1) are your best bets.
DACS can work with the neon library, for instance, so that any application based on it should be able to authenticate users using Basic Auth through DACS. Because Subversion uses neon, we are using DACS to supply authentication and authorization for it.
DACS supports "least common denominator" user agents. User agents need only support SSL/TLS and (for full functionality) the Netscape HTTP cookie standard, and be configured appropriately. Browsers without client-side certificates, applets, JavaScript, etc. are sufficient for use by DACS but it is not restricted to them. This zero-footprint approach eliminates the need to develop and maintain browser-specific support code and eases the administrative burden of instructing users on the use of the system.
In deployments where web services are invoked from browsers, each jurisdiction will typically share a common domain name suffix. Within federation federationOfPlanets.org, for example, earth.federationOfPlanets.org and vulcan.federationOfPlanets.org might be domain names for jurisdictions. This arrangement is necessary only so that HTTP cookies are automatically sent by browsers.
The two main capabilities required of the web server are:
We are willing to work with anyone interested in supporting additional web servers as an open source contributed resource for DACS.
DACS can be used to implement short links, permalinks, and smart links.
The DACS rule processing engine can be applied to tasks very different from controlling access to web services. We have used it in programs that perform rule-based document transformations (see dacs_transform(8) and dacstransform(1)). and scheduled program execution (see dacssched(1)).
Some applications may be able to access DACS through its web services interfaces, which are easily invoked and return simple XML documents or HTML.
To some extent, the current implementation of the DACS rule-processing engine trades memory usage for performance. This is exactly right when it is used by mod_auth_dacs, where it must quickly make an authorization decision and then exit, but may not be appropriate for longer-running server processes. We have not received any requests to modify the memory management policies, however.
DACS functionality is also available through a C/C++ API.
If it's possible to know whether a read-only operation or an update operation is going to occur simply by inspecting the arguments to the service request, then access control rules can be constructed to grant read-only access to one class of users and update access to another class.
Assuming that execution is initially granted by DACS, a finer degree of access control is also possible, but only with the participation of the application. Once the application is running, it needs to decide for itself whether to perform a particular operation; only the application can know at what points in its execution it needs to check if a particular operation should be performed. There are several ways of doing this.
In one method, the matching access control rule can specify additional information that is passed to the application. The application can then use this information to behave in an appropriate way; for example, for a user assigned to the read-only class of user, the information might look like "access=read-only" and users of the more privileged class might be associated with information of the form "access=update". Code within the application would then disallow certain kinds of operations if "access=read-only" is passed.
In another method, the application can invoke DACS (via an API or web service request) to test whether a particular operation is allowed for the user - a set of application-specific access control rules would be consulted by DACS and a yes/no decision returned to the application.
Lastly, dacscheck(1) will sometimes provide the best and simplest solution.
URL filtering software, sometimes called content-control software or Internet filtering software, runs on a host interposed between browsers and the Internet. At least in theory, each outgoing web request addressed to the Internet is directed to the URL filtering software. Those requests that are approved by the software are forwarded to the Internet, while all other requests are not allowed. Because this application uses DACS to look at outgoing rather than incoming service requests there are some subtle differences in its operation (consider DACS cookies, for instance), but its rule-processing engine is still highly-suited to this task.
This error message could be caused by any of several reasons. Maybe the item type has not been defined by a VFS directive, or the directive is incorrect. File permissions may be incorrect. Check the DACS log file for clues.
To programmatically determine the latest version of DACS and obtain a direct link for downloading, you may use this URL (https://dacs.dss.ca/cgi-bin/dacs/latest_dacs). There are typically two or three releases of DACS annually.
DACS Version 1.3.2 has been phased out of production use and is not supported.
The open source license is essentially the same as the Sleepycat license, an OSI-approved license originally used for Berkeley DB that is GPL compatible.
Speaking of Berkeley DB, DACS (and Apache) can optionally use Berkeley DB to store various information, such as passwords. 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 will continue to be compatible with Berkeley DB 5.3, which was released under the Sleepycat License, for as long as practical. Other DBM-type databases are supported by DACS.
You can also contribute just by sending us suggestions, ideas, or questions.
If you have an especially new and interesting application for DACS, we would be happy to discuss it and the possibility of working together to develop it. In some cases we may be willing to offer a reward.
For instance, we have experimented with the popular HAProxy high-performance TCP/HTTP Load Balancer by adding support for DACS authentication. For background information and instructions, see README.DACS. To get the patches and example configuration files, download haproxy-dacs-1.5.11.tgz.
Words of encouragement are welcome.