|
|
Do you have information that it would like to make available over the web?
Do you also need flexible ways of restricting access to this information?
This problem is faced by companies, schools, departments, labs, and organizations that must embrace collaboration and share information among staff, contractors, partners, guests, remote departments, external organizations, students, or the public. At the same time, they must maintain a high-degree of control over exactly who can access specific information and under what conditions.
An acceptable solution must be simple to configure and administer, and be adaptable to a wide range of environments. It must remain operational 24/7 and be as invisible as possible to users.
DACS, the Distributed Access Control System, was created by DSS to provide secure solutions for exactly these kinds of problems. DACS is open-source licensed software that allows your web site to flexibly control access to its web pages and web applications. If granted by DACS, a user's request for one of these resources will proceed normally; if denied, DACS will trigger an error condition and the web server will not perform the request. It does not matter what the web resources are, who wrote them, or what they do, and they do not have to be modified in any way.
Users that are known to your organization, regardless of their location, can be authenticated and granted access to web-based content and applications based not only on their identity, group membership, or roles, but on such contextual details as the current time or date, their location, their method of authentication, and how they are requesting to use an application. Users that are unauthenticated can be restricted to the most basic requests; all other requests can be denied.
An audit trail of requests, successful and failed sign-ons, and operations on DACS accounts is created. For any authentication method, weak passwords can be detected.
DACS can be deployed as a "firewall for web servers". That is, all incoming requests can be directed to a DACS-enhanced web server, subjected to access control, and then forwarded to other web servers for processing if access is granted. This provides a way for access control decisions to be centralized, an important consideration for any security architecture. And the content-serving web servers need not be modified, so they can run any web server software.
DACS gives your organization capabilities and possibilities that go far beyond what most web servers provide: expressive access control rules and light-weight single sign-on across your organization or a federation of organizations. At the same time, DACS is straightforward to configure and maintain. And your technical people will understand how it works, which may not be true for similar but far more complicated systems.
Does your software need fine-grained access control over its
resources and functionality?
Must its users have a special account created before it can be used?
This problem is commonly faced by developers. Often, they must write custom code that will give administrators full access to a program's functionality, including management operations, and give owners of data full control over it, but restrict what all other users can do. Programmers also repeatedly implement user authentication methods and create new accounts so that users of their system can login.
Why reinvent the wheel? Creating security software demands specialized expertise. It is challenging to develop and keep current. Besides offering a complete single sign-on solution, DACS includes a toolbox of components from which other single sign-on systems and web site features can be built. It supplies authorization checking capabilities and user authentication functionality that developers need to get their applications working quickly, whether web-based or not. Many kinds of server-based applications can benefit from DACS tools. Its rule processing engine can be employed in a wide variety of applications, not only to provide fine-grained authorization testing. Configuration is flexible and programmable.
| For applications: | Authorization testing can be performed from the command line, allowing scripts (Perl, PHP, shell, etc.) to make data-driven access control decisions rather than code-driven ones. Authentication functionality is also available from the command line; programs can easily reuse existing user accounts, authentication methods, and user management tools. |
| For middleware and web services: | Authentication and authorization testing can be done through simple, REST-based web service calls, the DACS Java library, or a C/C++ API. DACS web services can return XML or JSON formatted documents. |
With its dacscheck component and C/C++ API, DACS gives software developers a way to reuse a robust and rich framework for both course-grained and fine-grained access control for virtually any application, whether web-based or not (see dacscheck(1)).
The DACS 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. Where efficiency is important, a C/C++ API allows this functionality to be integrated with these scripting languages and integrated with compiled programs.
The dacsauth program exports DACS authentication methods to the command line, facilitating reuse of existing user accounts and account management tools. See dacsauth(1).
Essentially, DACS does just two things: authenticate users and perform authorization checks. Its authentication framework is flexible, extensible, and supports many commonly used authentication methods out-of-the-box. Authorization checking is implemented by a general-purpose, rule-driven access control engine. These two subsystems are often used together, making it easy to deploy a single sign-on, access controlled group of web sites. Either of the subsystems can also be applied directly by software developers to just about any application.
DACS functionality revolves around the jurisdiction, which generally corresponds to a single web site. A jurisdiction authenticates users, provides web-based resources, or both.
Any number of jurisdictions may be composed to form a federation. A DACS identity established through authentication at any one of the jurisdictions will be recognized for access control purposes by any other jurisdiction in the federation. This capability is known as single sign-on.
From a user's point of view, single sign-on means that after having authenticated himself once, a user can access information throughout the federation (subject to access control rules on that information) without having to sign-on again. From an organization's point of view, access control rules may very easily be created to grant or deny access to any set of users that have been authenticated anywhere within the federation.
Each jurisdiction is responsible for deciding whether or not to allow requests for its access controlled resources.
By specifying rules for web services, a DACS administrator can grant unrestricted access to those web services to some users, limited kinds of access to other users, and completely deny access to yet another set of users. Each rule grants or denies requests made by an individual or group of individuals, possibly depending on details associated with the request. Referring to one or more web services ("What"), a rule specifies, for a given set of users ("Who"), the conditions under which access is to be granted to them ("How").
Because a rule usually needs to refer to a particular user (e.g., "Grant access to Bob"), DACS provides ways to name users and manage user identities. A person is authenticated and assumes an identity by demonstrating knowledge of a secret (such as a password), or possession of some other information, that is associated with that identity.
DACS has a very flexible, module-based authentication framework that supports a wide range of authentication methods. To authenticate a user known to your organization, DACS can call upon whatever you already use to authenticate your users. Your DACS administrator can configure whichever methods best suit your environment. This is important because it allows your organization's existing authentication methods and user accounts to be leveraged. A user might be authenticated at your organization by providing a username and password that are recognized by your organization, or through a two-factor authentication method. Administration of identities can also be streamlined and simplified, lowering costs associated with password management, for example.
A user can be associated with roles within your organization (e.g., "Bob is a vice president") or with a group whose membership is known throughout the system (e.g., "Alice is currently working on Project X"). Access control rules at any DACS site can refer to these roles (e.g., "Grant access to any vice president") and groups (e.g., "Grant access to any member of Project X").
DACS uses industry-standard SSL/TLS communication over untrusted networks to ensure that information remains private and secure. User passwords, imported user account names, and other potentially sensitive information are either not stored by DACS or are stored in encrypted form. Whether in a federated situation or not, your organization always controls access to its own resources.
DACS makes few assumptions about the type of client software being used; any standard, SSL/TLS-capable web browser should be acceptable. A "zero footprint" philosophy means that DACS does not require plugins or code (such as JavaScript) to be installed on browsers and no special user administration is needed. More sophisticated client software, middleware, or non-interactive applications may also use DACS-protected information, however.
DACS is transparent both to the resources it protects and the users that attempt to access those resources. Because DACS is invisible to the web applications that it secures, it does not matter what those programs do, what programming language they are implemented in, or who implemented them, and they do not need to be modified in any way.
By configuring exception handlers, users can be automatically redirected to context-appropriate web pages from which they can login, acknowledge a notice, view an error message, and so on.
This document is merely an overview of how DACS is typically used. The system has many features, capabilities, and modes of operation that are not discussed here. For more general information, see the About and FAQ pages, or the What is DACS? article, which describes its basic features with a minimum of technical detail. See the technical documentation and features and benefits for more detailed information.