A record, usually persistent, that associates an identity (or username) with state information (such as whether authentication is enabled or disabled), information that is required to authenticate the identity (such as a digest of a password string), and possibly other sign-on related information. DACS does not provide mechanisms to administer "foreign" account types. For instance, although it can authenticate against them, DACS cannot create, modify, delete, or list Unix or Windows accounts. Note that DACS identities do not necessarily have a corresponding account.

The procedure by which a person or program obtains credentials that represent a DACS identity, usually by asserting a DACS username that represents an identity and providing information that only that identity is likely to know or possess. After successful authentication, a person or program is said to have authenticated. DACS can interface with a wide variety of authentication methods and provides some of its own; new methods can easily be added.

The procedure that determines, in a particular context, whether a request for a given resource or object should be allowed. If an identity is authorized to perform a certain operation on the object, access is granted, otherwise it is denied. Access control rules are one method of describing which identity or identities should be granted - or denied - access to a particular resource. Coarse-grained access control involves making a high-level decision of whether access to an object should be granted; this is usually an all-or-nothing decision. Fine-grained access control is used within a program to decide whether access to a lower-level resource (some data, an administrative function, a menu) should be granted.

Note that unlike some systems, DACS does not predetermine which resources a particular user (identity) can and cannot access; that is, an administrator does not make a list of what rights each user has. Authorization is always determined by rule evaluation, in real time, when a user requests a resource. The only exemptions to this are some optional features: Authorization Caching and Rlinks.

If authentication is successful, DACS returns information that can be used in subsequent operations to represent the authenticated identity. Credentials contain information about the identity, such as its name, and meta information, such as the time at which the credentials expire and become invalid. Credentials are protected cryptographically so that they are difficult to forge or alter. They must be kept secret, so that the identity cannot be used by anyone other than its owner, and must accompany a request made to a server so that DACS knows who is making the request. The particular mechanism used for this is not important provided credentials cannot be copied and reused; transporting credentials using the payload of an HTTP cookie over an SSL/TLS connection is typical, although sending credentials as the value of an HTTP extension header is another possibility.

Although there is no specific limit on the size of credentials as far as DACS is concerned, since they can be encapsulated within an HTTP cookie and returned to a browser, constraints on cookies imposed by browsers should be carefully considered.

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.

Note that in DACS, credentials do not give their owner any rights or convey any authorization; DACS is not a capability-based system. Credentials simply represent a DACS identity.

Refer to dacs_authenticate(8) for details.

The event that has triggered the authorization check being processed by dacs_acs(8) is referred to as the current request. For a request for a DACS-wrapped web resource, this will be the HTTP request that is received by the web server for the resource. In situations where dacs_acs is not involved, such as when dacscheck(1) or dacsexpr(1) are used, the current request and its context are specified by command line arguments or are obtained from the execution environment.

dacs_acs uses ${DACS::URI} as the path component of the current request. It is obtained from the uri element of the current request_rec within httpd. This is the string that is used to match against access control rules.

Other DACS components determine the current HTTP request by examining several environment variables: HTTP_HOST (or SERVER_NAME and SERVER_PORT), REQUEST_URI, QUERY_STRING, and HTTPS.

The value of ${DACS::URI} and the path component of ${Env::REQUEST_URI} are not necessarily the same. After an internal redirect, for example, the latter's value is from the original URL, while the former's is from the target of the redirection.

The current request string is important because it may be used to determine the current federation and current jurisdiction, and because it is used when searching for the access control rule to apply to the request.

Consisting of CGI-based web services, an Apache 2.4 module, and a collection of utilities, DACS provides authentication and authorization functionality. Transparent, coarse-grained attribute-based access control is available for web resources.

Programmatic, general-purpose access control is available for virtually any program (using dacscheck(1)). This is completely decoupled from Apache.

An individual (or individuals) responsible for managing the operation of DACS is called a DACS administrator (sometimes just "the administrator"). This individual is not necessarily a system administrator (e.g., superuser or root), although a small number of optional components of DACS must execute as user or group root. The DACS administrator need not be an Apache administrator; once Apache has been configured for DACS it typically requires very few modifications thereafter. The DACS administrator is responsible for configuring and testing DACS (probably installing and upgrading it, too), managing user accounts and access control rules, safeguarding security, backing up configuration and data files, and so on. The design of DACS allows some delegation of responsibility, largely based on file permissions. When invoked as a web service, each of the identities configured as a ADMIN_IDENTITY is effectively a DACS administrator; in this context, the system superuser has no significance.

Each authenticated user is assigned a name that consists of the name of the authenticating jurisdiction, its federation name, and a username. Each of these naming components must be syntactically correct. In some contexts the federation name is implicit; sometimes the jurisdiction name is also implicit. Entities such as individuals (people, but also programs, devices, etc.), federations, jurisdictions, and groups have names. It is the responsibility of jurisdictions to authenticate users. The syntax, meanings, and uniqueness of names is also a jurisdictional issue, and perhaps a federation-wide issue as well.

Each real world entity typically has a unique DACS identity, but this is left up to authenticating jurisdictions. Two or more identities are distinct if they do not refer to the same real world individual. Federated identity or single sign-on (SSO) is the ability to recognize a user identity across jurisdictions and even across federations.

A web resource is said to be DACS-wrapped if the web server responsible for the resource calls DACS (more specifically, dacs_acs(8)) to make an access control decision whenever it receives a request for the resource.

A DACS federation consists of one or more jurisdictions. The jurisdictions comprising a federation coordinate information sharing through light-weight business practices implemented as a requirement of membership in a DACS federation; in other words, the members of a federation typically agree to observe certain rules of conduct to preserve overall security and so that users can obtain maximum benefit. A federation consisting of just one jurisdiction is not unusual.

An item type is a name that maps to a VFS (virtual filestore) specification that configures how and where data is stored. The level of indirection that they provide means that access control rules, for example, can be configured to be in regular files, a Berkeley DB database, a remote database accessed by HTTP, and so on - all that is required is that the item type acls be properly configured. Some item types (like acls) are reserved and have special meaning to DACS, while others can be used by a DACS administrator for other purposes. An item type name is case sensitive and consists of alphanumerics, hyphens, and underscores, but must begin with an alphabetic character.

A DACS jurisdiction is an autonomous administrative entity that authenticates its users, provides web services, or both. It may correspond to an organization, department, web server, or virtual host. Jurisdictions are sometimes created simply as an administrative convenience. Each jurisdiction is assigned a unique name within a federation.

A user's home jurisdiction is a jurisdiction that can authenticate that user. In situations where a user has multiple credentials obtained from different jurisdictions, the effective home jurisdiction for a request depends on which credentials are selected during authorization processing. Configuration directives are available to restrict the number of sets of credentials that may accompany a request.

A user agent is client-side software that interacts with other software (a server application, typically) on behalf of a user. A user is often a person but can also be software. A web browser, which is used to interact with a web server, is an example of a user agent.