Glossary of Terms

The DACS documentation tends to throw around various technical terms in an effort to be concise and accurate. For convenience, the most important terms have been collected here, with a brief explanation of their meaning and relevance within DACS, and with links to external sites that provide additional information. The explanation of Key Concepts may also be helpful.

• Access Control Lists (ACLs)
  Authorization testing in DACS is performed at run-time by a programmable rule evaluation engine. Unlike some other systems, a user's ability to access a given resource is determined at the time the resource is requested. In the documentation, these authorization requirements are sometimes called access control lists (for historical reasons), access control rules, or simply rules. Each rule is an XML document, and the collection of rules referenced during authorization testing is called the rule set. The rule set is written and maintained by an authority to describe an access control policy for real or virtual resources.
• Apache
  The simplest way to use DACS is to integrate it with the Apache web server using the mod_auth_dacs Apache module. Deploying DACS to manage access to web resources and provide single sign-on functionality in this configuration ordinarily requires no programming effort. "Apache has been the most popular web server on the Internet since April 1996."
• Authentication
  DACS interoperates with an array of commonly-used authentication methods so that they, along with existing user account information, can be used to authenticate users who can then assume a DACS identity for access control purposes. Because it implements a configurable and extensible authentication framework, DACS is agnostic with respect to authentication methods - it can take advantage of any suitable method. For instance, users can be required to login using their normal Windows (or Unix) username and password before gaining access to a web server's resources. This general capability is also available through the command line, and does not require interaction with a web server.
• Authorization
  Users trying to access a DACS-wrapped resource must be authorized to do so; that is, evaluation of the rule associated with the resource must grant access. This capability is provided both through Apache and the command line, the latter not requiring interaction with a web server.
• BNF Notation
  The DACS documentation sometimes uses this widely-used method to describe syntax.
• Client, User, User Agent
  By "user", we usually mean a person. And by "user agent", we mean the software that a user runs. Depending on the context, a "client" can be a person or software, acting through a user agent. Does that help?
• Context-based Access Control
  This term is used quite literally in that authorization checking within DACS can take into account any available elements of context associated with a resource request. For instance, when granting or denying access, a rule can consider what the request is for, the arguments of the request, the time and date of the request, where the request comes from, the identity submitting the request (if any), and many other things.
• Cryptographic Hash
  These are used within DACS for message integrity checks.
• DACS
  The Distributed Access Control System is a dual-licensed product of Distributed Systems Software. Consisting of authentication and authorization frameworks, it is mainly used to provide transparent access control and single sign-on for web-based resources.
• DACS-enabled
  A web server is said to be DACS-enabled if it uses the mod_auth_dacs Apache module.
• DACS-wrapped
  If access to a resource requires approval by DACS, the resource is said to be DACS-wrapped. For resources served by Apache, this is usually done using its Location directive. Not all of a server's resources need to be DACS-wrapped, but at minimum the DACS web services must be.
• Digital Certificate
  DACS can use asymmetric cryptography (or public-key cryptography, PKI) internally.
• Discretionary Access Control System
  DACS includes some of the characteristics of this type of system.
• Dual Licensing
  Although DACS can often be used without fee under the terms of its open source license, commercial licensing options are also available. Technical support can be purchased by both open source licensed users and commercial users.
• HTTP Cookie
  As is typical for web-based applications, DACS can send cookies to a client to store various kinds of information.
• Identity Management System
  DACS is not really an identity management system because it does not provide the functionality to administer accounts held by authentication mechanisms that it uses. You cannot use DACS to create, disable, or update Windows (or Unix) accounts, for instance. But DACS does provide tools to administer its own "native" accounts and identities; for example, it can be configured to disallow authentication through DACS by particular Windows (or Unix) accounts, or to monitor requests submitted by a particular identity.
• Login by Username and Password
  This is probably the authentication method most familiar to computer users. It is well-supported by DACS.
• Mandatory Access Control System
  DACS is not this kind of system.
• Message Authentication Code
  These are used within DACS to authenticate and verify the integrity of certain data it produces (credentials contained within a cookie, for instance).
• Open Source License
  DACS can be used free of charge under the terms of this license.
• OSI-approved License
  The DACS open source license is closely modeled after this type of license.
• Permalink
  This is a static, relatively long-lived link that resolves to the same web resource even if that resource is moved or renamed. DACS can create and use access-controlled permalinks.
• Pluggable Authentication Modules (PAM)
  DACS can leverage authentication methods made available through PAM.
• Role-based Access Control System
  DACS includes some of the characteristics of this type of system.
• Single Sign-on System (SSO)
  DACS includes this functionality by integrating a wide assortment of authentication methods to create DACS identities. Existing identities and authentication methods provided by other systems to DACS are unified and then used for access control purposes. Regardless of whether a user is authenticated through a Windows account, Unix account, native DACS account, Apache account, and so on, a DACS identity is assigned and can be used for authorization checking.
• Two-factor Authentication
  DACS includes support for this more secure form of authentication.
• XML
  Most of the configuration information and data used by DACS is in this textual format.