|
|
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 being faced increasingly by companies, schools, departments, labs, and organizations that must embrace collaboration, sharing information among staff, contractors, partners, guests, remote departments, external organizations, students, or the public. But just as important is maintaining 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, of course, and be adaptable to a wide range of environments, 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 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 web services 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 services 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 focused on 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.
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 form a federation. As a result, 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 just once, a user can access information throughout the federation (subject to access control rules on that information). 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, your 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 a way to name users and mechanisms to manage user identities, including the means by which users can be authenticated. 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 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 identities 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 an X.509 certificate. 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 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-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 the client side and needs no special user administration. 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.