The core DACS technologies can be accessed directly or indirectly from the command line or by invoking simple web services. Instead of relying on complicated and hard-to-use protocols (such as SOAP, WSDL, and so on), DACS uses a REST-oriented design where its web services can be invoked from an ordinary browser, HTTP client utility, or API that provides HTTP functionality. Simple XML or HTML documents are returned. Because of this approach, writing programs, including middleware, that builds on DACS web services is not difficult.
A PowerPoint overview for developers is available.
Through the dacscheck command, the DACS rule-processing engine can be used from the command line. This allows scripts (Perl, PHP, shell, etc.) and compiled programs to make data-driven access control decisions rather than program-driven ones. Although no authentication or identity management is performed by dacscheck and it is a totally stand-alone program, CGI programs in particular can benefit from its capabilities.
A script or other program might use dacscheck with appropriate access control rules to decide, for instance:
For example, a program might use dacscheck to control access to a printer. Access could easily be limited to certain users or classes of user. Usage could be further limited to certain days, times, locations, etc., all depending on the policy expressed by the access control rules.
dacscheck could be used by a resource allocation/scheduling system. For example, exclusive use of a remotely-controlled web cam might be managed by a set of rules that allocates time slots to individuals.
dacscheck has many advantages over specially-written access control logic:
A C/C++ API is being developed to expose this functionality directly to scripting languages and compiled programs.
Please refer to dacscheck(1) for technical information and examples.
dacscauth is to authentication testing what dacscheck is to authorization testing. dacscauth harnesses the DACS authentication infrastructure, providing command line access to its authentication modules. Programmers do not need to waste time reinventing the wheel, perhaps poorly, by building username/password authentication into their programs - through dacscauth, they can reuse the DACS username/password mechanism. Even better, instead of having to create new, application-specific accounts, they can call dacscauth and ask it to authenticate using your existing Unix, NTLM, LDAP, Apache, CAS, etc. accounts.
dacscauth makes it easy to leverage existing authentication methods, helping to prevent the proliferation of accounts that makes life difficult for both users and system administrators.
Programs that use dacscauth can issue DACS credentials after successful user authentication, but they do not have to.
Please refer to dacsauth(1) for technical information and examples.
A variety of other software and resources for DACS can be found in the dacs-contrib project at SourceForge.
The DACS Java Library (DJL) is being developed to support the use of DACS in Java client applications. It implements Java wrapper classes for selected DACS services, and provides an HTTP client through which DACS services may be accessed and DACS credentials obtained and managed.
The FedAdmin Web Application is an administrator console for managing the configuration of DACS federations and jurisdictions. It is deployed in a servlet container such as Tomcat, but must be accessed via an Apache+DACS proxy and deployed under a dedicated FEDADMIN DACS application jurisdiction. FedAdmin implements partial coverage of the most common DACS configuration tasks, including viewing federation and jurisdiction configuration directives, adding and deleting local DACS users, and creating, editing, and deleting ACL rules.