DACS DACS - The Distributed Access Control System


DACS Frequently Asked Questions

Version 1.4.50
22-Jul-2023

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.

  1. General Questions
  2. Technical Details
  3. Security Issues
  4. Authentication
  5. DACS and Apache
  6. Implementation and Installation
  7. Using DACS
  8. Common Problems
  9. Other Stuff
  1. General Questions
    1. What is DACS?

      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:

      • a complete, light-weight, open source single sign-on system
      • a flexible and powerful attribute-based access control system, based on expressive rules (similar to access control lists), to perform authorization processing
      • a set of feature-rich authentication methods
      • an Apache 2.4 module and suite of CGI programs
      • a collection of web services that can provide access control, authentication, and authorization services to your middleware
      • able to apply coarse-grained access control to web service requests made using standard web browsers;
      • able to provide fine-grained access control functionality to almost any program or script;
      • a C/C++ toolkit for building new authentication and access control functionality into programs, whether web-based or not
      • for Unix-type platforms (currently), such as GNU/Linux, FreeBSD, and macOS
    2. Huh? Could you try that again?
      Authentication is about identifying people (or other things) within some context. Authorization testing or access control is about checking whether a person (or something else) is permitted to do something. Authorization does not require authentication, but it is usually necessary to know who is trying to do something when deciding if permission should be granted. Authentication can be performed even if no access control is being applied to the resulting identities. (See the What is DACS? section.)

      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.

    3. How might I apply DACS?
      There are an endless number of applications of DACS.

      For web site administrators:

      • keeping web pages private to an individual or list of users
      • giving some users of a wiki, event calendar, bulletin board, or similar hosted application add/update rights, while having everyone else limited to read only access, or be denied access
      • restricting access to a CGI program or servlet to an individual user or list of users, or controlling access to the data files that they use, create, or update
      • controlling file uploading and downloading rights on a per-user basis
      • limiting the right to post and administer a mailing list
      • providing the main controlling logic for a building's electronic access control system

      For software developers:

      • access control functionality is available through the command line, allowing scripts (Perl, PHP, shell, etc.) to make data-driven access control decisions rather than program-driven ones
      • authentication functionality is available through the command line, allowing scripts to reuse existing authentication methods and user accounts
      • middleware support through web services and commands in support of single sign-on
    4. Our intent is for DACS to be suitable for almost any application consistent with its design philosophy.

    5. How does DACS facilitate accessibility and sharing?
      Simply put, DACS lets a system administrator create areas on a web site for which access is restricted to particular users. DACS achieves this by managing users' identities and by enforcing access control specified by an administrator. Users may prove their identity to DACS in a variety of ways, depending on how DACS has been configured for the web site.
      1. Identities and Authentication
        A user who wants to access a web service that is protected by DACS (called a DACS-wrapped service) must usually first identify and authenticate himself to DACS; that is, he must provide the name of an identity and then "prove" that he is permitted to assume that identity. A user typically does this by providing a username and password, a digital certificate, or through two-factor authentication. Regardless of the authentication method employed, DACS gives a successfully authenticated user cryptographically protected credentials that represent the authenticated DACS identity and which have a limited lifetime. Credentials are usually, but not necessarily, returned as an HTTP cookie.
      2. 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.

      3. Access Control
        Access control rules are specified by a DACS administrator. Each rule specifies three things:
        • Who (which users or identities) the rule applies to;
        • What resources the rule applies to; and
        • How a web service is being used.

        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.

    6. How can I use DACS?
      DACS can help you to manage access to web resources in many situations, whether you have just one web server, several web servers at one site, or many web servers spread across the Internet. You may find it to be useful simply as a universal authentication or authorization mechanism for a single Apache server or as a complete multi-server, single sign-on and access control system. Your web services will usually be totally unaware that DACS is being used.
      • Federating
        DACS makes it straightforward to federate a set of web servers. The main benefit of this is that each server recognizes users that have authenticated themselves at any of the servers. Access control rules can then be written to grant, deny, or restrict a particular user's access to resources.

      • One Server
        Whether you are interested in federating a collection of web servers or not, there are various ways of configuring DACS on a single Apache server.
      • 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.

      • Web Clients
        Command-line based web clients and custom web clients that already work with Apache authentication and access control can often be made to work with DACS quite easily.

      • Non-web Based Applications
        By using DACS web services or the DACS toolkit, non-web based applications can take advantage of DACS. For example, a database, firewall, or other application that needs to make coarse or fine-grained access control decisions might benefit from using DACS.

    7. What do you mean by coarse-grained and fine-grained access control?
      By fine-grained access control in DACS, we mean authorization decisions for resources that are best made (or that must be made) from within a program that uses those resources. That is, this form of access control does not decide whether a particular user should be allowed to run a program or access a resource - that type of authorization checking is addressed by coarse-grained access control and can be performed using the context that is available with an incoming request. Rather, fine-grained access control checks whether or not a running program should allow its current user to do something: for instance, execute a program function from a menu, read a piece of data, see an RSS item, or view an area of an image (such as a secret location) that may depend on complex computations based on the contents of a database. In some cases it may not be impossible to perform fine-grained access control tests prior to execution of the program, but it will often be inefficient or involve a large amount of programming. Fine-grained access control is typically necessary when simple inspection of a web service's arguments prior to access is insufficient for authorization purposes.
    8. Does DACS stand for Discretionary Access Control?
      No. It is neither a discretionary access control system nor a mandatory access control system. It might be described as a combination of attribute-based access control, role-based access control, and context-based access control, with programmable run-time rule evaluation.
    9. What is a DACS federation? What are jurisdictions?
      A DACS federation consists of one or more jurisdictions, each of which authenticates its users, provides web services, or both. Jurisdictions coordinate information sharing through light-weight business practices implemented as a requirement of membership in a DACS federation.

      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.

    10. Why might we use a system like DACS?
      If your federation consists of just one jurisdiction, DACS can provide a highly flexible and feature-rich replacement for Apache authentication modules and access control mechanisms.

      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.

    11. Can you give a simple example of DACS usage?
      Suppose your company has several departments at different locations, with each having Internet access. Some departments operate web servers, with at least one department wanting to make information or computational resources available to the others through its DACS-protected web server. Your company does not want outsiders to gain access to these web services. At least one department is willing to authenticate employees by providing a DACS authentication service for the federation. Alternatively, each department might authenticate its own employees.

      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?.

    12. Can one organization or web site host multiple jurisdictions or federations?
      Yes. DACS makes it easy for a single web server to be responsible for many jurisdictions, even if they belong to different federations.

    13. My organization has just one web site. Might DACS be of interest to me?
      Yes. If you have a need to simply authenticate users of your web site (for logging purposes, customizing behaviour based on user profiles or preferences, or identifying users to CGI programs or servlets), DACS can help. DACS currently supports many popular styles of authentication and it can easily be extended to interoperate with any method that can be implemented as an authentication module.

      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.

    14. My organization has several web sites. Might DACS be of interest to me?
      Yes. Like the case of just one web site, DACS can authenticate users of your site; optionally, it can also provide access control for your web services. Each of the web sites would be configured as a DACS jurisdiction. Any or all of your jurisdictions could provide authentication services and any or all could provide access controlled web services.

    15. What is the architecture of DACS like?
      The architecture of DACS reflects the observation that an effective security system must be powerful but also as simple as possible. For organizations and their system administrators to have confidence in a security system, they must understand how it works and have confidence in it. It is said that complexity is the enemy of security. Towards this end, the DACS architecture and implementation use mature, conservative, and standard technologies and algorithms. For instance, very simple XML documents are used for communication between DACS components. Most DACS web services are REST-oriented, meaning that they are easy to call from a browser, script, or middleware.

      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.

    16. Why is the HTML produced by DACS web services so... basic?
      The HTML produced by DACS web services is very plain because it is sufficient in many cases (and it can be customized somewhat using CSS). Perhaps more importantly, in enterprise deployments, interaction with DACS must accommodate a web site's look and feel (including "branding" and language issues), and any stylistic choices made by DACS would almost certainly be wrong and difficult to adapt or configure. Most DACS web services can therefore output simple XML documents; by writing middleware or JavaScript, you can call these web services and emit the requisite HTML. For the same reason, DACS does not include an out-of-the-box sign on page (other than some demos) - you will almost certainly want to embed a sign on form that calls dacs_authenticate(8) within a web page that looks exactly the way you want.
    17. Why is DACS called a distributed access control system?
      Many of the pieces that make up a working DACS federation can be located on different computers. Jurisdictions can be assigned to different computers, a jurisdiction can authenticate its users by invoking programs on other computers, and configuration and data files can be retrieved from remote computers. Not all of the computers need to be able to communicate with each other. As mentioned earlier, DACS does not require or assume that there are any centralized web services or special computers - all jurisdictions are created equally.
    18. How would we create a DACS federation?
      Creating a DACS federation involves a small amount of administrative effort and configuring at least one jurisdiction (see below).
      • Establishing a federation will flow from an external shared business requirement. The creation of a DACS federation will occur as part of defining how secure sharing of information will be implemented by the organizations with the business requirement.
      • Get the latest DACS distribution.
      • Appoint an administrator who will be responsible for coordinating the jurisdictions.
      • A short name for the federation must be chosen.
      • A domain name must be chosen and reserved for use by the jurisdictions in the federation.
      • A DACS utility is run to generate encryption keys for use by the jurisdictions in the federation.
      • Operational requirements and business practices that jurisdictions must follow should be documented.
      • Create one or more DACS jurisdictions.

    19. How would we create a DACS jurisdiction?
      In brief, here's what needs to be done:
      • Receive permission to join an existing federation. You may have to agree to rules and procedures determined by the federation.
      • Get and install a DACS distribution that is approved by the federation's administrator.
      • Choose a short, unique name for the new jurisdiction (this must be approved by the federation administrator).
      • Choose a domain name for the jurisdiction within the federation and configure DNS appropriately. The jurisdiction's domain name may be an alias for an existing domain name owned by the jurisdiction's organization. It may be necessary to acquire SSL server certificates.
      • Using a secure channel, get the federation's encryption keys from the federation administrator.
      • Recompile and configure Apache for DACS.
      • Set up any local services that are needed, such as authentication modules.
      • Configure and test the new jurisdiction.

    20. How is DACS different? What requirements does it meet?
      DACS takes a decidedly pragmatic approach to authentication, managing identities, and access control. Organizations are usually unable or unwilling to make any but minor changes to their computing environment, existing applications, and web services, whether for financial or political reasons, lack of qualified personnel, or because of other concerns. The additional administrative overhead incurred by a new software system is often a significant impediment to its use. The DACS framework recognizes these facts and strives to minimize the cost of adopting and administering DACS and participating in a federation.

      DACS was originally devised as a system that would:

      1. Facilitate the cooperation of autonomous organizations to control access to information services delivered through web-based access methods;

      2. Define a common syntax and semantics for identifying users;

      3. Define a common syntax and semantics for jurisdictions to specify access to their information services, with the resulting access control language being extensible to meet with future needs but also simple enough to remain understandable by administrators;

      4. Allow a user authenticated by one jurisdiction to access web services at any other participating jurisdiction, subject to access control on those services;

      5. Enable the controlled sharing of web-based resources while leaving it to the custodian of a resource whether any request to access the resource should be granted or denied; management of access to a service must reside within the jurisdiction delivering the service (existing jurisdictional control must be retained and responsibility for the management of information and for the definition and implementation of services must continue to reside with the custodian of the information);

      6. Manage user identities but let the organizations to which those users are already known perform authentication through the same mechanisms that they already use; furthermore it should require only a modest implementation and administration effort on the part of a jurisdiction (creation and maintenance of jurisdictional accounts is out of scope);

      7. Provide a high degree of performance, availability, and scalability;

      8. Be resilient against hardware, software, and communication failures that cause a jurisdiction to become inaccessible to other system components (e.g., loss of Internet connectivity); failures should only affect normal operation with respect to the inability of authenticating that jurisdiction's users and obtaining services from that jurisdiction;

      9. Not dictate a particular implementation programming language or specific operating system platforms or environments for operation;

      10. Be standards-based and use mature and proven technologies;

      11. Maintain the secrecy of sensitive information (such as passwords) provided by a user or communicated between system components while it is possessed by the system;

      12. Preserve system security by preventing unauthorized access to computer systems, their information assets and services, etc., subject to the limitations introduced by browsers, operating systems, dependence on the end user's computing environment and his trustworthiness, and security practices at participating jurisdictions;

      13. Permit a service request based on the requestor's membership in a named user group;

      14. Be usable with standard web browsers (primarily newer releases of Internet Explorer and Netscape) that support secure communication via SSL/TLS, and requiring few or no browser configuration changes by the user; it must not depend on user agents (the interface by which a user invokes web services) having anything other than the simplest computational abilities; DACS is required to work with a "lowest common denominator" user agent, namely an SSL/TLS-capable web browser; DACS must not require any custom code at the user's end. Note that this does not mean that a user can't be sitting in front of some other kind of interface, interact through a servlet, or use a browser proxy, only that basic DACS functionality must be accessible from a standard browser;

      15. Be independent of whether a jurisdiction's services are accessed from an Internet address inside or outside of the jurisdiction; e.g., bookmarks to services and links within web pages should function as expected, to the maximum extent possible;

      16. Be reasonably simple to understand, so that jurisdictions can be confident that they understand how it works, what its weaknesses and vulnerabilities are, and how to administer it;

      17. Support system administration through a web-based interface, to the maximum extent possible.

      As the design and implementation evolved, it also became necessary for DACS to be:

      1. Usable with a wide variety of web servers for the purposes of access control (through "delegated authorization");
      2. Applicable in a server-to-server context;
      3. Able to be used directly by applications to control access to resources that are not web-based; and
      4. Be distributed under an open source license.

      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:

      • DACS is not proprietary. Its requirements and all elements of its design are freely available. Those interested in DACS may therefore become aware of exactly how it works, its strengths and weaknesses, how it might be improved, whether it is appropriate for a particular environment, make enhancements, and so on;

      • A major goal of DACS is to minimize the implementation effort required by any jurisdiction to provide authentication services for its users (DACS supports and encourages heterogeneity);
      • DACS aims to interoperate with virtually any authentication method. Passwords and other sensitive information are never shared between jurisdictions;
      • Fully distributed and highly available, its operation does not rely on any central servers;
      • While the primary goal of DACS is to function in the context of web-based services, its framework can readily be generalized to any client/server application distributed over the Internet or any network providing TCP/IP based communication;
      • DACS can be used in server-to-server contexts, including cascading (chained) service requests;
      • DACS may be used by any application, whether web-based or not, to support fine-grained, application-specific access control; and
      • DACS may be used by any application, whether web-based or not, to perform authentication.

      There is some additional discussion about these issues.

    21. Can DACS do authorization without authentication?
      Yes. Whether a request for a resource is granted or denied need not depend on the identity of the user making the request. An access control rule can consider almost anything. Typical examples include the IP address from which the request is sent, the current date or time, the presence or value of an HTTP cookie, and the arguments that accompany the request. User authentication is not a requirement.
    22. Although it manages its own private ("native") accounts and can disable or constrain identities "imported" from other authentication systems, it is not accurate to describe DACS as an identity management system. For example, DACS cannot perform any administrative functions on Unix, Windows, or macOS accounts. But you can tell DACS that it should consider a Unix or Windows account, or specific identities regardless of the authentication method, to be disabled for its own use.
    23. What about SAML?
      SAML, the Security Assertions Markup Language, is an evolving specification developed by OASIS, an e-business consortium. SAML is an "XML-based framework for communicating user authentication, entitlements and attribute information". It is a comparatively heavyweight method of federating service providers and providing Web single sign-on functionality.

      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.
      --- Microsoft man seeks to re-engineer the Web
      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].

  2. Technical Details
    1. What is a group?
      For administrative convenience, a DACS administrator can define a group that acts as a shorthand for some set of identities within the federation. The membership of a group can consist of individuals or the membership of other groups. The name of the group can then be used in an access control rule to grant (or deny) access to any individual who belongs to the group.

      Group membership is determined at run time.

    2. What is a role?
      Basically, a role is a word that describes or classifies a user. It can be viewed as a kind of attribute of its holder. A user can be assigned any number of roles, or none. For example, the user EARTH:kirk might be assigned the roles captain, staff, and officer.

      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.

    3. Exactly what is an access control rule?
      An access control rule tells DACS whether a web service request should be granted or denied. Essentially, it is a description of an authorization policy. DACS searches the set of rules that you have provided and finds the rule that most closely matches a request. Expressions within that rule are then evaluated to determine the access control decision. These expressions can test arguments to a web service, examine exactly who is making the request, take into account the overall context of the request, or call external programs.

      Here are just a few examples of policies that can be specified:

      • Access should be denied if a certain argument is present or has a particular value
      • Access should be granted only if the request is coming from a particular IP address range
      • Access should be granted only if a certain file exists on the web server
      • Access should be denied outside of business hours
      • Access should be granted only if a specified program can be run and returns a particular result

      These kinds of constraints, and many others, can be combined in many ways.

    4. What does an access control rule look like?
      A "ruleset" consists of any number of ordered access control rules, each of which is expressed as an XML document. The services section identifies the web services (as a URL path) to which the rule applies. The predicates identifies a set of users to which the rule applies and, optionally, the conditions under which those users will be granted access and flags that enable or disable certain features.

      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.

  3. Security Issues
    1. If we use DACS, do we have to give up other access control methods or security measures?
      No. A jurisdiction is free to filter out requests before or after DACS is invoked on a web service request. For example, other Apache access control modules can be used in conjunction with DACS.

      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.

    2. Who do we have to trust?
      Jurisdictions will typically (but are not required to) trust each other's authentication services. Each jurisdiction is completely autonomous with respect to granting and denying access to its own information resources.

      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.

  4. Authentication
    1. Exactly how is a user authenticated?
      To be authenticated by DACS at a particular jurisdiction, a user must already be known to that jurisdiction; that is, the jurisdiction must have previously established some way of confirming the user's identity, such as by providing the user with a username, secret password, and the name of the jurisdiction.

      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:

      • Simple authentication
        All of the information required to authenticate a user is provided in a single operation with a fixed set of arguments. This might be done through an HTML form, for example. This method corresponds to the common username and password style of authentication. Auxiliary information can also be provided, making two-factor authentication possible (e.g., using an authentication token). This style can be associated with RFC 2617 Basic Authentication, so that a user can be prompted by a browser pop-up and his password validated against your existing Apache htpasswd or htdbm accounts.

      • Digest authentication
        This style uses a pure DACS implementation of RFC 2617 Digest Authentication, allowing a user to be prompted by a browser pop-up and his password validated against an existing Apache htdigest account.

      • CAS
        This style works with the Central Authentication Service protocol. It does not require CAS server software, only software that follows the subset of the CAS protocol that DACS expects.

      • HTTP
        This style works by invoking a web service and examining the status code that is returned. This can be used to authenticate against a Google™ account, for instance.

      • Information Cards
        DACS can work with registered self-issued (personal) and managed Information Cards; that is, it can act as a Relying Party for DACS authentication. (Now deprecated)

      • Certificate-based authentication
        This style is characterized by the user providing an X.509 certificate (SSL client authentication).

      • Native authentication
        This style of authentication allows any of Apache's Basic or Digest authentication modules (RFC 2617) to be used indirectly with DACS. The identity that is established after Apache authentication can be automatically converted to a DACS identity. This style allows the large collection of Apache authentication modules, including proprietary and custom modules, to be reused with DACS. Also, existing user passwords can continue to be used.

      • Prompted authentication
        This style is characterized by conversational prompting, where the prompts are determined at authentication time. This extremely flexible style can be used to build an authentication method where the user is queried based on input obtained earlier during the authentication process; for example, if a password has been forgotten the user could be asked for some other proof of identity. Authentication using Pluggable Authentication Modules (PAM) [1, 2] is based on this style.

      • Expression-based authentication
        Rather than using an authentication module, this style of authentication involves evaluating an expression, including running any external program. This allows practically any kind of computation, database search, etc. to be executed to authenticate users.

      • Delegated authentication
        Instead of authenticating directly, a user can be authenticated indirectly through a trusted agent that vouches for the user. A mechanism is also available to transfer DACS credentials to another federation (or import an identity from another federation, DACS or not).

      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.

    2. Do DACS credentials contain a user's password?
      No. Despite what was once said (in the GeoConnections CGDI online training publication), DACS credentials do not include any user passwords, or any passwords, and have never done so.
    3. Do all DACS users within the same federation have to be authenticated in the same way?
      No. Each jurisdiction that provides authentication services for its users is free to authenticate them using any method (or combination of methods) that is supported by DACS.

    4. Do all DACS users within the same jurisdiction have to be authenticated in the same way?
      No. Any user can be authenticated in any way that is supported by DACS and the jurisdiction. It is possible to authenticate different users using different methods. For example, "guests" can be authenticated using a different method than everyone else, or users belonging to different departments within the jurisdiction can be authenticated using whatever method their department usually uses to authenticate them.

    5. Do all DACS users have to have client certificates issued by the same certificate authority?
      No. And unless their jurisdiction requires it, users do not have to have client certificates.

      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.

    6. What programming work does a jurisdiction have to do before it can authenticate its users?
      Typically, none. DACS includes authentication modules that provide common authentication services (Unix username/password, NT Domain username/password, Central Authentication Service username/password, private password files, Apache password files) and support for some generic authentication methods, such as ones based on X.509 certificates and PAM. DACS can also leverage existing Apache authentication modules. And when necessary, an external program can be called to authenticate. Should a special method be required, writing an authentication module is not a difficult task for an experienced system programmer.

    7. Does DACS require that HTTP cookies be used?
      No. The requirement for a common domain name suffix for jurisdictions is due to the rules that standard browsers use to decide whether to send an HTTP cookie. Since DACS is often deployed in environments where these off-the-shelf browsers are used, HTTP cookies are the mechanism of choice to convey DACS identities.

      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.

  5. DACS and Apache
    1. Why should I use DACS instead of Apache's authentication and authorization modules?
      DACS unifies and extends the functionality of Apache's modules and is more flexible, customizable, and versatile. DACS includes the ability to access the same password files used by mod_auth_basic, mod_auth_dbm, and mod_auth_digest. Although we have the utmost respect for the Apache web server, we believe that in many cases DACS offers simpler, cleaner, and more easily understood solutions than does Apache with its assortment of modules.

      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.

    2. Do we have to modify Apache?
      You do not have to patch or make any changes to Apache, but to get all of the benefits of DACS for web services you must use the mod_auth_dacs module.
    3. Are there alternatives to using mod_auth_dacs?
      Yes, but they are a little more complicated to use or require some programming work.

      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.

    4. I am a developer. Do I have to use mod_auth_dacs?
      No. You may be able to build a solution using dacscheck(1), dacsauth(1), and other commands. None of these programs require mod_auth_dacs or Apache.

      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.

    5. Can I use DACS when Apache is proxying requests?
      DACS is used in many environments where Apache acts as a reverse proxy. In general, DACS does not currently support Apache in forward proxy mode.
  6. Implementation and Installation
    1. How is DACS implemented?
      DACS is a suite of light-weight CGI programs written in ISO C99 C/C++ with GNU extensions using IEEE/ANSI Std 1003.1 (POSIX) and other open Unix standards. There are roughly 20 commands and 40 web services. It currently stands at about 200,000 lines of code.

    2. What platforms is DACS available for?
      DACS releases are tested and officially supported on recent versions of GNU/Linux and FreeBSD that use 64-bit Intel/AMD processors, and macOS on the Apple M1/arm64e architecture. Though no longer officially supported, macOS on a 64-bit Intel processor should continue to be workable for this release. Development is primarily done on FreeBSD 13.x, and testing is done on FreeBSD 13.x, CentOS 7.x (built from Red Hat Enterprise Linux 7 and "DACS should build and work on other POSIX-compliant platforms with little effort, we can only support those platforms that are available to us for testing.

      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.

    3. Why doesn't DACS work with Apache 1.3?
      Earlier versions of DACS did work with Apache 1.3 but because it did not supply the necessary hooks, patches to several Apache source files were required. These patches would have to be reviewed and possibly updated with each new release of Apache 1.3. In contrast, DACS uses a single self-contained module with Apache 2.4 and is easily built and installed. It was felt that the additional complexity for administrators to install DACS with Apache 1.3, together with the extra development time and cost, didn't warrant supporting both servers.
    4. Why doesn't DACS work with IIS?
      Although we believe that DACS could be ported to Windows and integrated with IIS, we have received no expressions of interest. It would involve a significant development effort. Delegated authorization is the only alternative.
    5. Does DACS include any support for Java?
      Yes, but it is currently quite limited and mainly a proof of concept. There is nothing to prevent development of a complete JNI interface to DACS functionality, but to date we have received virtually no expressions of interest in such a thing so we have not directed much energy to it.
    6. Does DACS work with OpenID?
      There was a demonstration to show that DACS can function as a relying party, obtaining DACS credentials from a valid OpenID identifier. But when major players abandoned OpenID (circa 2013-2018) and DACS sites did not express interest in it, the DACS development work was discontinued.
    7. Why doesn't DACS provide support for account self-registration?
      For some web-based systems, it is convenient for users to create their own accounts based on some form of readily confirmable identity. Most commonly, at account creation time a user is asked to provide an email address. The system sends a message to the user's purported email address; if the user confirms receipt of the message within a given period of time (often by invoking a specified URL or replying to the message), the system accepts the email address as a unique identifier for the user's account (sometimes, or it uses the email address for functions such as password recovery) and proceeds with account creation.

      Design and implementation of a simple, general purpose mechanism to conduct this type of registration procedure is currently in progress.

    8. Why does DACS include some commands and web services that seem to have nothing to do with authentication or access control?
      Functionality that DACS uses internally is sometimes "exported" as a command (e.g., dacshttp(1)) or web service (e.g., dacs_transform(8)) because:
      • doing so helps to implement a better API for the functionality more quickly
      • it facilitates testing and debugging
      • it demonstrates a feature
      • a possibly useful program can be created at very little extra cost by simply putting a wrapper around the API
    9. Does DACS work with Information Cards or Windows CardSpace?
      Yes. Well, sort of. Support for InfoCards became available starting with release 1.4.23. Microsoft initially shipped Windows CardSpace with .NET Framework 3.0 (a free download for Windows XP and Windows Server 2003), Windows Vista, and Windows 7, and updated CardSpace with .NET Framework 3.5. In 2011, Microsoft announced that Windows CardSpace 2.0 will not be shipped and that they are adopting a replacement called U-Prove. As CardSpace has been the most widely available identity selector for using Information Cards, this is not good news for the future of InfoCards, and although it is still included in the DACS code base, InfoCard support is no longer maintained or tested and will likely be removed eventually.
    10. What level of expertise is required to install and configure DACS?
      A system administrator who has installed and configured Apache and who has some experience with OpenSSL should not find it too challenging. The ability to successfully complete the Quick Start Tutorial is a good test.
    11. How difficult is it to evaluate DACS?
      The Quick Start Tutorial was written to make it as easy as possible to install, configure, and experiment with DACS. A system administrator with some experience building and configuring Apache should be able to install DACS, including the necessary third-party software, and configure it for testing in about 30-45 minutes.

      After installing DACS, a basic DACS configuration involves:

      1. Adding about a dozen additional directives to Apache's httpd.conf file;
      2. Adding a similar number of DACS directives to DACS's dacs.conf file;
      3. Running a few DACS utilities;
      4. Writing a handful of access control rules to try; and
      5. Using an ordinary browser to test DACS services and DACS-wrapped resources.

      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.

  7. Using DACS
    1. We have a custom application that makes web service requests. Does DACS require web services to be accessed using a browser?
      No. Any user agent that talks HTTP to a web server, whether it's a standard browser or some other program (such as a thick client or middleware), should be capable of obtaining DACS credentials and sending them as an HTTP cookie. For example, a Java/JSP application has been written that uses DACS entirely for its user authentication and access control. Once a user is authenticated and obtains a cookie, a DACS service is called by the application to identify the user and obtain his application-specific roles.

      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.

    2. What if want DACS to perform authorization but we don't use Apache or can't use mod_auth_dacs?
      Although DACS can currently only be integrated with Apache 2.4, it is not essential for the web services protected by DACS to be deployed by a DACS-enabled web server or even an Apache web server. In some cases it is impractical or impossible for a site to install, operate, and maintain a web server that directly supports DACS.

      When access control is delegated to another server, service requests are directed to a DACS-enhanced web server that grants or denies the request. If a request is granted, the server acts as a proxy and forwards the request to the first jurisdiction.

      One alternative is to add a new server that can run a DACS-enhanced version of Apache on a different host or as a separate Apache server on the same host. DACS-wrapped web service requests would then be directed to this server, where Apache's "proxy mode" of operation is used, and which runs DACS services and makes access control decisions. Requests that are granted are forwarded to the web server where the services actually reside - a standard access control feature of this web server would be used to ensure that only "approved" requests would be processed.

      DACS can also approach this problem by allowing a jurisdiction to delegate authorization for its web services to a second jurisdiction within the same federation. The first jurisdiction runs any web server that meets a rather standard set of operational requirements, while the second jurisdiction would run a DACS-enhanced web server.

      While there are advantages to integrating DACS with web servers other than Apache, the capability to proxy access control means that this rather difficult integration task need not be repeated (and maintained) for each web server that DACS must support.

      The environment in which DACS-wrapped programs execute when delegated authorization is used is not identical to when mod_auth_dacs is available, although in some cases this may not be important.

      For controlling access to programs, another possibility is for programs to do their own access control. When DACS is used in this way, the web server (which need not be Apache) is not altered or configured in any special way. Apache runs the requested program as usual, but the program calls dacscheck(1) to decide whether the caller is allowed to use the program or perform certain functions. Rather than modifying a program, this might be done by wrapper script that executes the program if access is granted.

      Improved methods of delegated operation are being investigated, including some that will work with resources served by Apache 1.3 and even non-Apache web servers. The basic idea is for the origin server to redirect unauthorized requests to a DACS-enabled web server for authorization testing, redirect the user to the origin server with secure authorization information, employ some clever URL rewriting, and then serve only authorized requests. Any origin server capable of using mod_rewrite or equivalent could then use DACS in an almost transparent way without needing the mod_auth_dacs module.

    3. OK, but could DACS work directly with a web server other than Apache?
      We believe so, although little work has been done in this area.

      The two main capabilities required of the web server are:

      1. to be able to invoke DACS as an external program when a request is received for a resource that is wrapped by DACS, passing various information associated with the request, and
      2. depending on the result returned by DACS, either deny access (and possibly redirect) or grant access (and possibly alter the context of the request).

      We are willing to work with anyone interested in supporting additional web servers as an open source contributed resource for DACS.

    4. How else can DACS be used?
      Because of its generality and feature set, DACS can be applied to all sorts of problems in addition to controlling access to web resources. For example, DACS can provide fine-grained access control, programmed audit trails for web access, or look for unusual web service requests.

      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)).

    5. Can DACS be integrated with our application?
      Yes. The easiest way to do this is to use the dacscheck(1) or dacsauth(1) commands, which can be called from Perl, PHP, shell scripts, and so on. The distribution includes wrappers for several languages that provide a simplified API for calling these DACS commands. It should be a simple exercise to develop interfaces in any similar language, such as Tcl, Python, and PHP (contributions would be most welcome).

      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.

    6. Can DACS be used to limit access to certain data within a web service? For example, can one group of users be limited to read-only access for sensitive data while another group of users be given full editing/writing privileges for the same data?
      Yes. The "automatic" kind of access control provided by DACS is coarse-grained; that is, it provides a yes/no decision to the web server about whether an application should be run by the web server based on access control rules that apply to the application and the user making the request. This level of access control is transparent to the application - it does not need to be modified - and the application is never executed if access is denied.

      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.

    7. Can DACS function as a URL filter?
      Yes. Along with appropriate firewall settings, it can be done through a DACS-enhanced Apache proxy server or by developing software that uses dacscheck(1) to determine whether a request should be granted or denied.

      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.

  8. Common Problems
    1. "Could not open item type ..."
      DACS needs to access data through its virtual filestore mechanism but could not do so. For example, some components need to read the current jurisdiction's encryption keys and expects the item type jurisdiction_keys to be defined to point to an object (usually an ordinary file) generated by dacskey(1). The jurisdiction's configuration must include a VFS directive that defines jurisdiction_keys so that DACS knows where these keys are and how to access them.

      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.

  9. Other Stuff
    1. What is the current status of DACS?
      DACS version 1.4.50 is the latest release.

      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.

    2. Where can I get DACS?
      DACS is available here.

    3. What license is used for DACS?
      DACS 1.4 is released under an open source license and commercial licenses. That is, we use dual licensing. In a nutshell, if you distribute a product based on DACS, either that product must be open source or you must obtain a commercial license from DSS. If you are only using DACS and not redistributing it, then you do not require a commercial license. Whether or not you are selling products or services based on DACS is not relevant.

      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.

    4. Is DACS an open source project?
      No. Although DACS is released under an open source license, it is not a "community open source" project and it does not have an open development process. A small team is responsible for its development.
    5. Can I contribute to DACS?
      Yes! You can submit bug fixes, patches, improvements, etc. for our consideration provided that you clearly state that 1) you are the author and 2) you are placing the submitted material in the public domain or are contributing it under a BSD, MIT, or similar open source license.

      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.

    6. Has DACS functionality been added to other open source software?
      Yes. We are always looking for new ways to use DACS. Suggestions are welcome.

      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.

    7. How can I support DACS?
      The best way to support DACS is by purchasing technical support, which is very affordable relative to comparable commercial (non-free) products.

      Words of encouragement are welcome.

    8. Where can I find out more about DACS?
      Documentation and other information is available. Please visit dacs.dss.ca.

$Id: $