1. METALOGIC s o f t w a r e © Metalogic Software Corporation 2004-2006 DACS Developer Overview DACS – the Distributed Access Control System

2. © Metalogic Software Corporation, March 2006 DACSkit a distributed access control toolkit A replacement for ad hoc access control code, DACSkit allows any program to make powerful, data-driven access control decisions. DACS ACLs DACS C/C++ API C/C++ Programs dacscheck Scripting Languages dacs_javalib Java Programs ?? ? command line CGI Desktop Apps

3. © Metalogic Software Corporation, March 2006 Cookies may be used as an envelope for DACS credentials Web Browser DACS Services DACSweb distributed access control for the Web A universal authentication and authorization system for Apache that can provide federated identity (single sign-on) functionality. DACS ACLs Content & Services mod_auth_dacs Apache Server ? Configurable Event Handling c Pluggable Authentication

4. © Metalogic Software Corporation, March 2006 Why use DACS technologies?  leverage a robust, mature access control framework  supports local and Web applications  centralize configuration of access control, share user account and role information between applications  simplify application software development & maintenance

5. © Metalogic Software Corporation, March 2006 Programs that perform authorization tests typically contain code like: If the current user has provided a suitable password, then execute the following code, or If the current user is the administrator, do the following, or If the current user is allowed to perform an update operation, then show these menu items This makes applications prone to bugs and security problems and harder to maintain a change to a security policy may involve changes throughout an application or suite of applications password handling can involve significant implementation effort and is difficult to do securely

6. © Metalogic Software Corporation, March 2006 Recipe 1: Basic Web Site Problem: You want to add user and role-based access controls to your Web site. Solution: DACS-enable your Apache server and configure your access control rules. Build and install DACS on your server. Then load mod_auth_dacs in the Apache config. Enable DACS access control for a or using Apache DACS directives. Configure access control in DACS ACL files: Service Specification: DACS matches the request against this specification to determine if the rules should be applied Rules: a list predicates that is evaluated to decide if access should be allowed or denied

7. © Metalogic Software Corporation, March 2006 fire this ACL for all requests default is to allow access Example ACL Description: a wildcard rule allowing access to everything under the document root (more specific rules will override)

8. © Metalogic Software Corporation, March 2006 Mapviewer group is defined by the BC jurisdiction Apply rule if url_pattern matches request default is to deny access user("%BC:mapviewer") Example ACL Description: allow access to the MapServer application only for users belonging to BC’s mapviewer group

9. © Metalogic Software Corporation, March 2006 Recipe 2: Authentication Problem: You want to let users authenticate using their existing corporate accounts. Solution: Configure DACS authentication modules to reference local authentication services. DACS comes with modules for Microsoft ADS/LDAP, NTLM, Unix /etc/passwd & NIS, flat file, native Apache, SSL/X.509 and PAM. Crafting custom authentication modules (for example to reference a database schema for users and roles) is simple. Modules are configured in DACS Auth Clauses and are applied in a controlled sequence to the parameters supplied by the user. If successful, DACS credentials are returned to the user.

10. © Metalogic Software Corporation, March 2006 Example Configuration URL "https://fedroot.com/dacs/local_passwd_authenticate" STYLE "pass" CONTROL "sufficient" URL "https://fedroot.com/dacs/local_ntlm_authenticate" STYLE "pass" CONTROL "sufficient" OPTION 'SAMBA_SERVER="samba.fedroot.com"' URL "https://fedroot.com/dacs/local_unix_authenticate" STYLE "pass" CONTROL "sufficient" Description: configure flat-file, NTLM & Unix authentication modules.

11. © Metalogic Software Corporation, March 2006 Recipe 3: Basic User Accounts Problem: You want a simple, off-the-shelf user accounts framework. Solution: Use native DACS user accounts and roles. In addition to the modules DACS includes for industry- standard authentication technologies, DACS implements its own basic user account and roles framework. Web services are provided to add and delete user accounts, assign roles, and manage passwords. DACS ACLs provide for fine-grained control of access to user account management functions.

12. © Metalogic Software Corporation, March 2006 Recipe 4: DACS-enabled App Problem: You want to use or re-use DACS access control in your custom application. Solution: Use DACSkit’s dacscheck. dacscheck is a program that can be called from a scripting language like Perl, PHP or Ruby to provide simplified, general-purpose access to the DACS access control rule evaluation engine and lends itself to fine-grained access control decisions. dacscheck looks at access control rules to test if a given user is authorized to do something or access something. The command's exit status gives the result of the test.

13. © Metalogic Software Corporation, March 2006 where to find the ACL rules identifier for MyApp #! /bin/sh dacscheck -q -ieuid -rules /usr/local/myapp/rules /myapp st="$?" if test "${st}" != 0 then echo "Access is denied" exit "${st}" fi echo "Access is granted" # Do some stuff exit 0 Example MyApp (1) Description: control access to application MyApp from a Shell script (user identity derived from Unix login)

14. © Metalogic Software Corporation, March 2006 check access to MyApp is user a site admin? is user a MyApp admin?... <?php $user = $_SERVER["REMOTE_USER"]; putenv("REMOTE_USER=$user"); system("/usr/local/dacs/bin/dacscheck -q -fn DEMO -icgi -rules /usr/local/myapp/rules /myapp", $st); if ($st != 0) { // Access is denied, bail out exit($st); } else { // Access granted; test for admin priviledges system("/usr/local/dacs/bin/dacscheck -q -fn DEMO -icgi -rules /usr/local/myapp/rules /myapp/admin", $stapp); system("/usr/local/dacs/bin/dacscheck -q -fn DEMO -icgi -rules /usr/local/site/rules /admin", $stsite); $is_admin = ($stapp >> 8) || ($stsite >> 8);... Example MyApp (2) Description: control access to application MyApp from a CGI script (user identity derived from REMOTE_USER environment variable)

15. © Metalogic Software Corporation, March 2006 Recipe 5: Notice Presentation Problem: You require users to acknowledge a notice before accessing selected Web content or services. Solution: Use the dacs_notices Web service. An ACL rule may be defined to associate a notice or notices with a given service URI. DACS enforces a work flow using the dacs_notices service to present required notices to the user and, on acceptance, set a Notice Acknowledgement Token (NAT cookie) in the response. The NAT will accompany subsequent requests allowing the rule to be satisfied.

16. © Metalogic Software Corporation, March 2006 Web Browser HTTPS GET/POST.../mapserver/umn.phtml Step 1 – User attempts access to a DACS-wrapped resource (eg, Web Mapserver, file download area, etc...) DACS wrapped resources browser redirect to dacs_notices Step 3 – If a license acknowledgement is required, Apache/DACS sends a browser redirect to the configured notice presentation handler match.../umn.phtml against DACS ACLs ACLs Step 2 – DACS matches resource uri with configured ACLs Example License Agreement "/mapserver/umn.phtml" "allow,deny" ack("http://demo.fedroot.com/notices/geobase-license-agreement.html")

17. © Metalogic Software Corporation, March 2006 Web Browser (IE, Netscape, …) Step 4 – Browser follows redirect to notice presentation handler HTTPS Step 5 – Notice presentation handler obtains text of required license(s) and presents license(s) text in a license acceptance form Redirect to notice presentation handler redirecting to notice presentation handler present the license acceptance form Accept the license license cookie, browser redirect to original URL License Cookie (NAT) Created Redirect to originally requested URL Step 7 – This time the ACL is satisfied; Apache/DACS permits the request original request with License Cookie GET http://demo.fedroot.com/notices/g eobase-license-agreement.html Step 6 – User reads license text and clicks “Accept;” form SUBMIT calls notice acceptance service to obtain a Notice Acknowledgement Token (“license cookie”); possibly including optional security parameters access granted for subsequent requests

18. © Metalogic Software Corporation, March 2006 Recipe 6: Non-Apache Servers Problem: You want to use DACSweb to secure content or services on another Web server. Solution: Use Apache + DACS to proxy the other server. While Apache remains the work-horse of the Web at almost 70% of server deployments, content and services deployed on other servers like Microsoft IIS, WebSphere, Tomcat, JBoss may be “DACS-wrapped” without touching either the proxied server or the application.

19. © Metalogic Software Corporation, March 2006 configure DACS access control on this location # Proxy the FedAdmin Application in a Tomcat container ProxyRequests on ProxyPreserveHost on AuthType DACS Require valid-user AuthDACS dacs-acs ProxyPass http://localhost:8080/fedadmin ProxyPassReverse http://localhost:8080/fedadmin Example DACS-wrapped Proxy Description: control access to a Java servlet in a Tomcat container by configuring an Apache proxy

20. © Metalogic Software Corporation, March 2006 Recipe 7: Client & Middleware Problem: You need to implement Java client code or middleware to access DACS-wrapped Web services. Solution: Use the DACS Java Library. The DACS Java Library (DJL) supports the use of DACS in Java client applications in several key areas: establishing the necessary preconditions for access hiding implementation details of DACS Web services (HTTP request signatures, marshalling/unmarshalling of XML) specialization of the Jakarta Commons HttpClient library for DACS request processing and event handling DJL is available from SourceForge: http://sourceforge.net/projects/dacs-contrib http://sourceforge.net/projects/dacs-contrib

21. © Metalogic Software Corporation, March 2006 Recipe 8: Federated Web Problem: You want a secure way to federate Web information and service delivery amongst partners. Solution: Use DACSweb federated identity and distributed access control. By configuring a network of DACS-enabled Apache servers within a common domain, it is easy and practical to implement a full- fledged single sign-on, multi-server identity management and access control system for business collaboration on the Web. DACS imposes few technology constraints on member organizations and its decentralized design makes it a robust solution resilient in the face of network and server failures.

22. © Metalogic Software Corporation, March 2006 Business Requirements  members control access to own Web services, manage own users, set own policies  nominal central authority - easy for members to “pull the plug,” low administrative overhead  leverage existing authentication technologies of members (e.g., Microsoft ADS & NTLM, Radius, LDAP, PKI, /etc/passwd, etc.)  shallow learning curve

23. © Metalogic Software Corporation, March 2006 NXIS network DACSweb approach nxis.org DACS federation implemented by a common domain name on.nxis.org nl.nxis.org ns.nxis.org DACS federation consists of one or more jurisdictions bc.nxis.org single sign-on, federated identity leverages existing authentication technologies

24. © Metalogic Software Corporation, March 2006 DACS Jurisdiction An autonomous administrative entity provides authentication services for its users (if applicable) assigns access to its Web services Jurisdictions have a well-known, unique, name assigned within the federation: NXIS::BC, NXIS::ON, NXIS::PUBLIC etc Jurisdictions participate in a circle-of-trust through a shared DACS secret key

25. © Metalogic Software Corporation, March 2006 DACS User identity Each user has a home jurisdiction users are authenticated by a server in their home jurisdiction username = Federation + Jurisdiction + Username NXIS::METALOGIC:rmorriso NXIS::PUBLIC:bjb@dss.ca Role information may be assigned to user at authentication time, tested for at access time

26. © Metalogic Software Corporation, March 2006 DACS Single Sign-on User may be challenged to authenticate at any DACS jurisdiction: user provides username/password, X.509 certificate, etc relative to home jurisdiction authentication request is channeled to appropriate DACS server at home jurisdiction; native authentication is applied DACS itself does not do authentication Single-signon on success, user assumes a federation-wide identity

27. © Metalogic Software Corporation, March 2006 DACS User Credentials Secure, tamper-proof, kept private via SSL Expire or may be revoked immediately by the authenticating (home) jurisdiction A user may invoke a DACS signout service to invalidate credentials Web browser implementation based on Netscape cookie specification Exportable to affiliated federations

28. © Metalogic Software Corporation, March 2006 Stop reinventing access control! We don’t re-implement database management with each new application we write – why do we continue to custom code access control? DACS can do for access control what persistence frameworks like Hibernate have done for data access.

29. METALOGIC s o f t w a r e © Metalogic Software Corporation 2004-2006 Further information on DACS DACS Home Page: http://dacs.dss.ca http://dacs.dss.ca DACS SourceForge Projects: http://sourceforge.net/projects/dacs http://sourceforge.net/projects/dacs http://sourceforge.net/projects/dacs-contrib DACS Demos: https://demo.fedroot.com https://demo.fedroot.com Rick Morrison rmorriso@fedroot.com Barry Brachman brachman@dss.ca