DACS.QUICK(7)           DACS Miscellaneous Information           DACS.QUICK(7)

       dacs.quick - DACS Quick Start Tutorial

       The purpose of DACS Quick Start is to explain, step-by-step, how to
       configure a very basic DACS-enabled web site from scratch so that you
       can try DACS with minimal effort. We hope that by performing the entire
       example configuration yourself, you will gain a better understanding of
       how DACS works and how to go about configuring it to meet your needs.
       By following along with some simple examples, you will create a
       completely stand-alone, single jurisdiction DACS federation on one of
       your hosts. You will become familiar with some of the DACS utilities
       and web services. When you are done, you can simply delete a few
       directories to uninstall everything. The tutorial should take about 30
       minutes to complete the first time.

       After successfully completing Quick Start, you should understand DACS
       well enough that you can proceed to experiment with configuration and
       features, and perhaps use the example configuration as a starting point
       to meet your requirements.

       We do not provide much background or technical information about DACS
       here, or tell you how to set up a fully functional, production-quality
       DACS system. You may find it worthwhile to review the FAQ[1] before
       beginning, but if you're itching to get started right away you may do
       so. For technical details, please refer to the manual pages[2] and
       other documentation.

       We assume that you've got some hands-on experience configuring and
       using Apache, although Quick Start tells you exactly what to do.  To
       avoid frustrating problems, we recommend that you resist the temptation
       to stray from the instructions except when indicated. Experienced
       Apache administrators may recognize the opportunity for some shortcuts,
       but since we're trying to keep things simple for a wide audience, we'd
       rather not get sidetracked by mentioning them. Likewise, experienced
       DACS administrators may recognize alternative ways - maybe even better
       ways - of doing things. But our goal is to get beginners started
       quickly, so we'll progress in small steps, explaining what is being
       done, and providing assurance that everything is correct so far. That
       way if you run into a problem, you should be able to isolate and fix it
       more easily.

       We'll assume that you've already obtained the latest version of DACS,
       unpacked it, and at least skimmed through dacs.readme(7)[3] and
       dacs.install(7)[4]. This document should have come from that version of

            1. You will be installing and configuring a basic Apache server
               (httpd) as part of this tutorial. You may perform this
               installation on any supported platform, whether your desktop
               Unix host or some other host, such as a remote server. You will
               find the former somewhat easier and safer to do, so it is
               recommended when possible. If doing the installation on a
               particular host may expose the tutorial's web server to
               requests from the Internet, be sure to carefully consider the
               security implications and take appropriate precautions before
               proceeding. Nothing in the tutorial ought to make the host
               running the web server more vulnerable, but if you experiment
               with DACS on your own there could be unintended consequences.
               It is probably a good idea to stop Apache when you are no
               longer using it.

            2. You will find it much easier to follow along if you use the
               HTML version of this document because it includes links that
               save you from having to type examples. Obviously these links
               will only work if you have configured the tutorial's
               environment. Some links from this document to other
               documentation point at the tutorial environment, so they will
               not function if that environment is not available. Also, your
               web browser must be capable of handling cookies and have that
               feature enabled.

            3. Make sure that this document came with the DACS release that
               you are working with.

            4. The Quick Start procedure has been performed successfully on
               FreeBSD and CentOS, but we expect it to work on most Unix-like
               systems. If you run into a problem, you should not proceed
               until you have fixed it.

            5. Depending on your environment, some tasks may need to be done
               as root (e.g., using sudo). In particular, editing /etc/hosts
               and DACS configuration files, setting file ownership and
               permissions, and the make install commands are likely to need
               this. No program or web service used in the examples needs to
               run as root. Except for one or two optional DACS web services,
               none of the DACS web services needs to run set-uid or set-gid.

            6. Ordinarily, all DACS-related network communication must be done
               over SSL. Setting up SSL appropriately is primarily an Apache
               configuration task[5], requiring a server certificate; anyone
               who has done this before will likely understand what needs to
               be done after completing Quick Start. But to help keep this
               document simple and because our goal is not to create a
               production-quality DACS installation, we will neither use SSL
               in the examples nor mention SSL again.

            7. It's a challenge to write instructions that will work
               everywhere, everytime, for everyone, so please accept our
               apologies for any deficiencies in this document. We are keen to
               improve it, so if you encounter any problems while trying this
               tutorial, or if you have any questions, please contact us[6].
               Our goal is to make it as easy as possible to get started with

       Quick Start Steps:

        1. Step 1: Install required third-party packages

        2. Step 2: Install and configure Apache

        3. Step 3: Build and install DACS

        4. Step 4: DACS-enable Apache

        5. Step 5: Do basic DACS configuration

        6. Step 6: Do basic Apache configuration for DACS

        7. Step 7: Test basic DACS services

        8. Step 8: Try DACS authentication

        9. Step 9: DACS-wrapping a web service

       10. Step 10: What's next?

       11. Step 11: Clean up

   Step 1: Install required third-party packages
       Obtain the versions of Apache[7], OpenSSL[8], and Expat[9] that are
       specified in dacs.install(7)[4]. If your system already has suitable
       versions of OpenSSL[8], and Expat[9] installed, you may use them if you
       are comfortable deviating from these instructions; you may have to
       adjust paths that are used below, however. Detailed instructions have
       been provided for building OpenSSL[10] and Expat[11]. This document
       assumes that Apache2.2 is being used; you may use 2.4 if you are able
       to adapt the instructions on your own.

       For the purposes of this exercise, those are the only third-party
       packages that you need, other than gmake, GCC, and the usual software
       development tools. Install OpenSSL and Expat now; we will deal with
       Apache in the next step.

           We will assume that these packages are installed under /usr/local.
           If you installing elsewhere, be sure to adjust paths appropriately
           in the examples below.

           Some administrators prefer to use a particular file extension, such
           as ".cgi", for CGI executables. The easiest way to make DACS
           accommodate this is to pass the --with-cgi-suffix flag to configure
           (see dacs.install(7)[4]). This results in the configuration
           variable ${Conf::dacs_cgi_bin_suffix} being set to the suffix. In
           this document, we will assume that no special file extension is

   Step 2: Install and configure Apache
       Because you probably do not want to use a production web server for
       this exercise, so that we're on the same page to begin with, and to
       make it easier for you to clean up later, we'll build and install a
       fresh Apache server. It will be best if you start from scratch by
       unpacking an Apache distribution into a new directory, building and
       installing it, and then verifying that the default Apache configuration
       works. We will install this Apache in /usr/local/apache-dacs so that it
       does not interfere with anything already on your system - you may
       change this path, but remember to make appropriate changes to the
       instructions that follow.

        1. From the root of the Apache distribution, you need to build Apache.
           Review the ApacheINSTALL file. Unfortunately, there is no simple
           way to build Apache that will work on all platforms, so you will
           need to review the detailed instructions[12]. Then build and
           install Apache.

           Do not configure any Apache modules or customizations. We want to
           create a vanilla web server. The path /usr/local/apache-dacs is
           being used to avoid any existing Apache installation; when you are
           finished with the tutorial, you will remove this directory.

        2. We will soon configure a virtual host for a (fake) domain name that
           we have reserved for this purpose, but first we must make
           dodgers.dacstest.dss.ca an alias for the host that will run httpd.
           Choose one of the following two options:

            1. If you are installing Apache on the same machine from which you
               are running your web browser, edit /etc/hosts as follows:

              localhost dodgers.dacstest.dss.ca

            2. If you will be running your browser on a host different from
               where Apache is running, you will need to add an alias in
               /etc/hosts for that host's IP address on both machines. The
               entry will have the format:

                   hostip       hostname dodgers.dacstest.dss.ca

               For example, on my system I used:

              i7.dss.ca i7 dodgers.dacstest.dss.ca

               So the hostip I selected above is

                1. If your desktop is a Windows platform rather than
                   Unix-based, you will need to edit
                   C:\Windows\system32\drivers\etc\hosts or
                   C:\WINNT\system32\drivers\etc\hosts (or similar) instead of

                2. You can use the domain dodgers.dacstest.dss.ca and the
                   others in this document no matter where your host is
                   located. These domain names will not be visible outside of
                   the hosts on which you define them by hand.

                3. After you have completed this exercise, please remember to
                   delete the aliases.
           To verify the change, use ping:

               % ping dodgers.dacstest.dss.ca

           (You may need to run it as /sbin/ping or something similar on your

        3. We need to make a few changes to Apache's default configuration, in
           case you are already running a web server on this machine and as a
           first step towards some customization that we will need shortly. We
           will add a virtual host definition and do some initial set up for
           DACS. Edit /usr/local/apache-dacs/conf/httpd.conf, advance to the
           bottom of the file, and insert the text that appears below:

               # Permit access to the DACS documents
               <Directory /usr/local/dacs/www/*>
                 Options Indexes FollowSymLinks
                 Order allow,deny
                 Allow from all

               # Permit access
               # Configure a virtual host and make the DACS documents available
               Listen dodgers.dacstest.dss.ca:18123
               <VirtualHost *:18123>
                 ServerName dodgers.dacstest.dss.ca:18123
                 DocumentRoot "/usr/local/apache-dacs/htdocs"
                 ErrorLog     "/usr/local/apache-dacs/logs/error_log"
                 TransferLog  "/usr/local/apache-dacs/logs/access_log"
                 ScriptAlias /cgi-bin/ "/usr/local/apache-dacs/cgi-bin/"

                 Alias /css       "/usr/local/dacs/www/css/"
                 Alias /dacs      "/usr/local/dacs/www/"
                 Alias /dtd-xsd   "/usr/local/dacs/www/dtd-xsd/"
                 Alias /examples  "/usr/local/dacs/www/examples/"
                 Alias /handlers  "/usr/local/dacs/www/handlers/"
                 Alias /infocards "/usr/local/dacs/www/infocards/"
                 Alias /man       "/usr/local/dacs/www/man/"
                 Alias /misc      "/usr/local/dacs/www/misc/"
                 Alias /mod       "/usr/local/dacs/www/mod/"

           This VirtualHost[13] section is going to correspond to the DACS
           jurisdiction that we will define shortly. The purpose of the
           Directory[14] and Alias[15] directives is to make various web
           resources available without having to copy them under your

                1. In our examples, we use port 18123, which we're guessing is
                   unlikely to already be in use on your machine. If you are
                   unlucky and it is in use, Apache will complain when you
                   start it and you will obviously need to select a different
                   port number. So that the examples will continue to work,
                   consider creating a copy of this document and changing all
                   occurrences of "18123" to the port number you have
                   selected. If available, commands such as netstat(1)[17] and
                   sockstat(1)[18] can tell you which ports are currently in
                   use. In the event that you will be accessing your server
                   from the other side of a firewall (which is not
                   recommended, as previously mentioned), keep in mind that
                   traffic may not ordinarily be passed through on this port.

                2. If you are already running Apache on port 80 (the default)
                   or if you are not root whenever you run apachectl in any of
                   the following steps, you must comment out (or delete) all
                   Listen[19] directives for port 80 in httpd.conf. Therefore,
                   comment out all directives that look like any of the

                       Listen 80
                       Listen [::]:80

        4. It is good practice to run httpd as an unprivileged user id and
           Apache does this by default through the User[20] directive in

               User nobody

           DACS web services are run as the same user id as httpd, but they
           must be able to read and sometimes write files within the DACS
           installation directory. These files should not be readable or
           writable by other processes or anyone other than a DACS
           administrator. Using mod_suexec[21] is one approach, but for the
           purpose of this tutorial we want to keep things simple. Note that
           setting User[20] (or Group[22]) to root is not a good idea.

           The Apache documentation recommends setting up a new group
           specifically for running the server, and we will take this
           approach. We will assume in our examples that this group is called
           www. You may need to create this group (see group(5)[23]) or you
           may already have a different but suitable group name to use (e.g.,
           webservd, _www, or daemon). Whatever group name you choose, when
           DACS is installed in the next step you will be prompted for this
           group id and you must make the appropriate change to httpd.conf:

               Group www

           Because we will refer to this group name often in later steps, save
           its name as the value of the shell variable dacsgroup (we will use
           csh/tcsh syntax - use the syntax preferred by your shell):

               % set dacsgroup=www

               Consider adding yourself to this group while you are working on
               this tutorial because you will have to do much less of the work
               as root. Remember to logout and login again after adding
               yourself, and verify the change using the groups command.
           Change the group id of files in the Apache installation directory
           to this group and adjust permissions (you may have to do this as

               % chgrp -R $dacsgroup /usr/local/apache-dacs
               % chmod -R g+w /usr/local/apache-dacs

        5. As root, start your httpd...

               # /usr/local/apache-dacs/bin/apachectl start

           The reason you must do this as root is because it is required by
           Apache's User[20] and Group[22] directives.

        6. Use your favourite browser (or link fetcher, such as wget) to
           verify that Apache is serving content, starting with this link:


           If this fails, check again that your host has the correct IP
           address for dodgers.dacstest.dss.ca. If you are running your
           browser on a different host than Apache, check for a networking or
           firewall related problem (and try the browser on the same host as

               It appears that CentOS disallows non-localhost connection
               requests by default; to allow Apache to receive non-localhost
               requests on CentOS, run (as root):

                   # system-config-securitylevel

               In the "Other ports" section of the "Firewall Options", add
               port 18123 for protocol tcp. Once the change is applied it is
               persistent, so remember to remove the port from the list when
               you are finished with this tutorial. Another option, if it is
               safe to do so, is to totally disable the firewall. On CentOS:

                   # service iptables stop

               If you choose to do this you should either restart the firewall
               when you are done ("service iptables start") or reboot.

               Another alternative, for CentOS and other systems, is to use
               the appropriate command (e.g., iptables, ipfw, or pfctl) to add
               a firewall rule to allow TCP access to port 18123.

        7. You should now check that your httpd was built properly. First,
           make sure that test-cgi is executable (a CGI that is installed by

               % chmod 0750 /usr/local/apache-dacs/cgi-bin/test-cgi

           And then invoke it:


           Look for the SERVER_SOFTWARE variable in its output and ensure that
           its value shows the correct versions of Apache, mod_ssl, and
           OpenSSL; if you find something unexpected, you probably didn't
           configure and/or install Apache or OpenSSL correctly.

        8. You have confirmed that Apache is properly installed, so stop the
           web server:

               % /usr/local/apache-dacs/bin/apachectl stop

   Step 3: Build and install DACS
       Now it is time to build and install the DACS utilities and web
       services. Make your working directory the src subdirectory of the DACS

        1. Build and install DACS web services and utilities. You must use
           gmake, the GNU Make utility. Adjust the paths specified for Expat,
           Apache, and OpenSSL as necessary. The DACS installation directory
           must be writable to you and you must be able to set file user and
           group ownership (see below); you may need to be root.

               % ./configure --prefix=/usr/local/dacs \
                  --disable-shared --enable-static \
                  --enable-passwd-auth --disable-bdb \
                  --with-apache=/usr/local/apache-dacs \
                  --with-apache-apr=/usr/local/apache-dacs/apr-httpd \
                  --with-expat=/usr/local/expat-2.0.1 \
               % gmake

           If all goes well:

               % gmake install

           You can ignore any warnings about ACLs.

           You will be prompted for the user id and group id to be used for
           DACS files and directories. The group id you give should match the
           value you used for Apache'sGroup directive (that is, the value of
           $dacsgroup). The user id can be your user id; if it is not, you
           will need to do the upcoming install command (and some later
           commands) as root. You will need to do gmake install as root if
           your account has insufficient privileges to set the user and group
           ids that you specify. The installation procedure will remember your
           answers to the prompts; if you make a mistake or want to change
           them, do:

               % conftools/setaccess-sh reset

           and try gmake install again.

   Step 4: DACS-enable Apache
       We'll continue by installing the mod_auth_dacs[24] module for Apache.
       Make your working directory the apache subdirectory of the DACS

        1. Compile and install the mod_auth_dacs module. As earlier, you will
           need to do gmake install as root if your account has insufficient
           privileges to set the user and group ids that you specify.

               % gmake tag
               % gmake install

           If this succeeds, your Apachehttpd.conf[25] file should now contain
           the following directive:

               LoadModule auth_dacs_module modules/mod_auth_dacs.so

           Please check that this is so. If you cannot find that directive,
           add it manually near the part of httpd.conf that talks about the
           LoadModule[26] directive.

        2. Start Apache again (as root):

               # /usr/local/apache-dacs/bin/apachectl start

           and take another look at the SERVER_SOFTWARE variable:


           The SERVER_SOFTWARE variable ought to look the same as before,
           except it should now also mention mod_auth_dacs.

           Congratulations - you are now running a DACS-enabled web server!
           DACS is not configured to do anything at the moment, mind you, but
           your web server is now capable of DACS-wrapping web services. You
           should be able to view the DACS manual pages served from the web
           server you just installed:


   Step 5: Do basic DACS configuration
       Although your Apache is now DACS-enabled, a little more configuration
       of both DACS and Apache are necessary before you can do anything
       interesting. We'll continue by working with the DACS configuration (see

       We begin this step by defining a new DACS federation that consists of
       one jurisdiction. We will call the new federation DACSTEST and
       associate it with the domain name dacstest.dss.ca. We will call our
       jurisdiction LA. Incidentally, the names that we are using in this
       tutorial for our federation and jurisdiction ("DACSTEST", "LA", and
       "dacstest.dss.ca") are not "special"; there's an underlying theme that
       should be apparent to any baseball fan but we could have chosen any
       syntactically valid names. The domain name for our jurisdiction
       (dodgers.dacstest.dss.ca) is only special in that it is a subdomain of
       dacstest.dss.ca; this must be the case for all jurisdictions in our
       example federation.

           All of the files and directories that we create in this and future
           steps must be readable by DACS web services. This means that they
           must have their group ownership set to $dacsgroup and have group
           read and write permissions, as discussed earlier.

       We're going to be using a few long pathnames in this step and later on,
       so to help unclutter the instructions, and for your convenience, we
       will represent them as shell variables. For example, the pathname
       /usr/local/dacs/federations will be referred to as $feds and the
       pathname $feds/dacstest.dss.ca/LA will be $la. You may find it useful
       at this time to define the following variables in your shell using the
       particular syntax it prefers (we use tcsh):

           % set dacs=/usr/local/dacs
           % set bin=$dacs/bin
           % set feds=$dacs/federations
           % set la=$feds/dacstest.dss.ca/LA

       If you are using a compatible shell, such as csh, you will then be able
       to copy and paste command lines and other text that follows in the

           At this point you can use the dacsinit(1)[28] program, found in the
           distribution's src directory, to perform the operations in this
           step for you. By default, the program uses the default paths that
           were established when DACS was built and the example paths used in
           this step. When prompted, simply use the dacsinit default values
           (just hit Return/Enter), which should result in the same
           configuration as you would obtain by manually following the
           directions in this step.

           You can also use dacsinit to create a configuration for a
           federation with one very basic jurisdiction based on names of your
           choosing. You can later extend or customize this configuration
           manually. Also see Initial Configuration[29].

       Although you can get away with having a single DACS configuration file
       on a host, we recommend a hierarchical organization. The file
       site.conf, although optional, holds standard default configuration
       directives as well as site-specific directives for all federations
       configured on this host. One or more files named dacs.conf can be used
       on a per-jurisdiction, per-federation, or per-host basis; that is, each
       jurisdiction on a host can have its own dacs.conf, or all (or some) of
       the jurisdictions on a host can share a dacs.conf, or everything can
       just be lumped into one dacs.conf. It's entirely up to you.

       When configure is run to build DACS, you can specify default locations
       for various configuration files, including site.conf and dacs.conf. We
       did not change the defaults when we built DACS above, so our examples
       will use the default paths.

           We recommend that you always use the site.conf-std that comes with
           your DACS distribution as your site.conf file and that you do not
           make any modifications to it, instead putting customizations in
           your dacs.conf file. This will make upgrades easier and less

        1. Proceed by installing the default site configuration file as
           $feds/site.conf (recall that we defined the shell variables
           earlier[30], and that you may have to be root to be able to install

               % install -c -g $dacsgroup -m 0640 $feds/site.conf-std $feds/site.conf

               If the install command is unavailable on your system, you can
               use src/conftools/install-sh relative to your DACS distribution
               directory. Or just use cp (or mkdir), chgrp, and chmod.

        2. Since we are not using SSL in this tutorial, edit $feds/site.conf
           and change the value of the SECURE_MODE[31] directive to "off". For
           production use, the directive's value should always be "on":

               SECURE_MODE "off"

        3. It is convenient - though not required - to collect the
           configuration directives for all jurisdictions on this host in a
           single file. It's not unusual for a host to be associated with just
           one jurisdiction (and one federation), but this is certainly not
           always the case.

               % install -c -g $dacsgroup -m 0660 /dev/null $feds/dacs.conf

        4. We will create a directory where most of the files associated with
           our new federation will live:

               % install -d -g $dacsgroup -m 0770 $feds/dacstest.dss.ca

        5. And a subdirectory within it where most of the files associated
           with our new jurisdiction will live:

               % install -d -g $dacsgroup -m 0770 $la

        6. Create a directory where we will put access control rules (also
           called ACLs, access control lists, or simply rules) for our
           jurisdiction, and we also need an empty revocation file:

               % install -d -g $dacsgroup -m 0770 $la/acls
               % install -c -g $dacsgroup -m 0660 /dev/null $la/acls/revocations

        7. Create directories where we will put group definitions for our
           jurisdiction and define the membership of our federation:

               % install -d -g $dacsgroup -m 0770 $la/groups $la/groups/LA $la/groups/DACS
               % install -c -g $dacsgroup -m 0660 /dev/null $la/groups/DACS/jurisdictions.grp

           Paste the following text into the $la/groups/DACS/jurisdictions.grp

               <groups xmlns="http://dss.ca/dacs/v1.4">
                <group_definition jurisdiction="LA" name="jurisdictions"
                    mod_date="Tue, 14-Jun-2005 16:06:00 GMT" type="public">
                  <group_member jurisdiction="LA" name="LA Jurisdiction" type="meta"
                    alt_name="Test Jurisdiction for the LA Dodgers"
                    authenticates="yes" prompts="no"/>

           (Remember to change 18123 if you are using a different port.) The
           purpose of jurisdictions.grp is to provide DACS with information
           about the jurisdictions in this federation. All jurisdictions in a
           federation should use identical jurisdictions.grp files. We're not
           going to make much use of this in the tutorial, but if you add a
           jurisdiction or if any of this information changes,
           jurisdictions.grp would ordinarily be updated everywhere in your
           federation. For instance, if you were to add a jurisdiction to your
           federation, you should add another group_member element to the
           group_definition that describes the new jurisdiction, and then copy
           the updated jurisdictions.grp file to each jurisdiction. Please see
           dacs.groups(5)[32] for additional information.

        8. We need some basic configuration directives for the jurisdiction
           LA. Paste the following text into the $feds/dacs.conf file:

               <Configuration xmlns="http://dss.ca/dacs/v1.4">

                  FEDERATION_DOMAIN "dacstest.dss.ca"
                  FEDERATION_NAME "DACSTEST"
                  LOG_LEVEL "info"

                <Jurisdiction uri="dodgers.dacstest.dss.ca">
                  JURISDICTION_NAME "LA"


        9. And let's make this the default configuration file for DACS
           jurisdictions at this site:

               % rm -f $la/dacs.conf
               % ln -s $feds/dacs.conf $la/dacs.conf

       10. Now, let's ask DACS to display its configuration by running the
           dacsconf(1)[33] utility:

               % $bin/dacsconf -uj LA -q

           This configuration is the result of merging the contents of
           $la/dacs.conf (which points to $feds/dacs.conf) and
           $feds/site.conf, with directives in the former file overriding
           directives in the latter.

       11. We must create encryption keys for this federation using the
           dacskey(1)[34] utility:

               % install -c -g $dacsgroup -m 0640 /dev/null $feds/dacstest.dss.ca/federation_keyfile
               % $bin/dacskey -uj LA -q $feds/dacstest.dss.ca/federation_keyfile
               % ls -l $feds/dacstest.dss.ca/federation_keyfile

           We could not do this until after the jurisdiction had been
           configured because dacskey needs to look at dacs.conf.

               The federation key file must be kept secret. Any person or
               process that can read the federation key file can create DACS
               identities. It should be readable only by its owner and DACS
               and not readable by anyone else.

       12. Similarly, we should create encryption keys for our jurisdiction:

               % install -c -g $dacsgroup -m 0640 /dev/null $la/jurisdiction_keyfile
               % $bin/dacskey -uj LA -q $la/jurisdiction_keyfile
               % ls -l $la/jurisdiction_keyfile

           Like the federation keys, these keys must also be kept secret. But
           the jurisdiction keys are private to their jurisdiction and are not
           shared among federation members.

       13. Make sure that all of the files and directories starting with
           /usr/local/dacs have appropriate permissions, as discussed earlier.

           If you modify httpd.conf you must restart Apache for the changes to
           take effect. If you modify dacs.conf, site.conf, or any other DACS
           configuration file, the changes take effect immediately and do not
           require restarting Apache.

   Step 6: Do basic Apache configuration for DACS
       Your Apache is now DACS-enabled and we've configured DACS. Before we
       can do anything interesting we must make some changes to the Apache
       configuration. We will begin by DACS-wrapping DACS web services, which
       is required.

        1. Edit /usr/local/apache-dacs/conf/httpd.conf and locate the
           VirtualHost[13] section that you added earlier. Inside that
           VirtualHost section and near its end, add the following text
           (remember to adjust paths as necessary):

               AddDACSAuth dacs-acs /usr/local/dacs/bin/dacs_acs "-t -v"
               SetDACSAuthMethod dacs-acs external
               SetDACSAuthConf dacs-acs "/usr/local/dacs/federations/dacs.conf"

               <Location /cgi-bin/dacs>
                 Require valid-user
               # Note: For Apache 2.4, instead use:
               # Require dacs-authz
                 Options ExecCGI
                 AuthType DACS
                 AuthDACS dacs-acs

           These directives configure the virtual host to DACS-wrap the
           contents of all URLs that fall under the /cgi-bin/dacs namespace.
           The first three directives tell mod_auth_dacs where to find the
           external DACS access control program (dacs_acs(8)[35]) and the DACS
           configuration file.

        2. Start (or restart) Apache so that it uses its new configuration (as

               # /usr/local/apache-dacs/bin/apachectl restart

           DACS should now be enforcing access control on the /cgi-bin/dacs
           part of the server's URL space.

        3. Check that you can still access test-cgi (which you have not


        4. Now, let's see what happens when we try to access dacs_prenv:


           Apache should produce a "403 Forbidden" error, which causes DACS to
           display an "Access Denied by DACS" page (actually, it is the
           contents of the file /usr/local/dacs/www/handlers/acs_failed.html,
           which is set by the ACS_ERROR_HANDLER[37] directive in site.conf).
           This happens because the default rules do not grant access to
           dacs_prenv, so all access will be denied.

        5. To finish up this step, let's add a rule that will grant everyone
           access to dacs_prenv. Create $la/acls/acl-tutorial.0 with
           appropriate permissions:

               % install -c -g $dacsgroup -m 0660 /dev/null $la/acls/acl-tutorial.0

           and then paste the following text into it:

               <acl_rule status="enabled">
                   <service url_expr='"${Conf::dacs_cgi_bin_prefix}/dacs_prenv${Conf::dacs_cgi_bin_suffix}"'/>
                   <service url_expr='"${Conf::dacs_cgi_bin_prefix}/dacs_version${Conf::dacs_cgi_bin_suffix}"'/>

                 <rule order="allow,deny">

           Whenever you add or change an access rule, you must rebuild the
           rule index for the jurisdiction:

               % $bin/dacsacl -uj LA -q -build
               % chgrp $dacsgroup $la/acls/INDEX

           It's currently only really necessary to run dacsacl if you add a
           rule or modify any part of a rule's services element, but this may
           change in a future release so just do it always. We make sure that
           the index file's group ID is correct.

           This time dacs_prenv should work because our new rule grants access
           to everyone. Try it:


           This output includes some new environment variables that are passed
           to all DACS-wrapped programs. These variables begin with "DACS_",
           such as DACS_VERSION - see dacs_acs(8)[38] for additional

   Step 7: Test basic DACS services
       There's still not too much you can do at this point, but there are a
       few DACS services that you can try. If one of these requests fails,
       take a look at the DACS log files in the /usr/local/dacs/logs directory
       for clues. The most likely cause is incorrect permissions on a file or
       directory, or possibly you made an editing mistake.

        1. The dacs_version(8)[39] web service displays various version
           information, naturally enough:


        2. The dacs_list_jurisdictions(8)[40] web service displays information
           about jurisdictions:


           You may recognize some of this material from the jurisdictions.grp

        3. We saw the conf utility earlier. We can get the same information
           from a web service:


           Ooops! You should have been denied access to this web service. If
           you examine the default ACL (see dacs.acls(5)[41]) for this web
           service, which can be found in /usr/local/dacs/acls/acl-conf.0, you
           might suspect that access to dacs_conf will only be granted to
           identities that satisfy the expression "dacs_admin()" (see
           dacs.exprs(5)[42]). And since you have not signed on to obtain a
           DACS identity, the ACL should deny access. After we do a little
           more DACS configuration work in the next step, we will give this
           another try.

   Step 8: Try DACS authentication
       It is possible to create accounts or identities specifically for DACS
       users. These identities are managed by the dacspasswd(1)[43] utility
       (there are user accounts managed by other DACS commands, but we will
       not discuss them here). Similar to Apache'shtpasswd[44] command, these
       accounts are "private" in that they are unrelated to any other
       identities you might have on your system, unless you tie them together.
       For example, we can create a DACS identity named "root" that has no
       relationship to a Unix system's superuser - perhaps you are creating a
       DACS account for actor Stephen Root[45].

        1. We begin this step by creating an empty password file for
           dacspasswd (to ensure correct permissions). Then we create a DACS
           account for username "sandy".

               % install -c -g $dacsgroup -m 0660 /dev/null $la/passwd
               % $bin/dacspasswd -uj LA -q -a sandy

           You will be prompted for a password to assign to sandy's account.
           Choose any password you like as long as it is at least six
           characters long. You can change sandy's password by running this
           command again.

        2. Next, we edit $la/dacs.conf and add the following text in the
           Jurisdiction section for dodgers.dacstest.dss.ca:

               <Auth id="passwd">
                  URL \
                  STYLE "pass"
                  CONTROL "sufficient"

           This configuration enables authentication (see
           dacs_authenticate(8)[46]) for accounts managed by the dacspasswd
           utility. Check again that all files starting with /usr/local/dacs
           have appropriate permissions, as discussed earlier.

        3. We should now be able to authenticate ("login") as sandy by
           providing the password you set up earlier. If successful, your
           browser will be sent credentials (in an HTTP cookie) for the
           identity DACS calls LA:sandy. Note that the cookies DACS creates
           are deleted when your browser exits. Even if a cookie is not
           deleted, DACS credentials have a limited lifetime and will become
           useless when they expire.

           DACS comes with examples of simple HTML login pages with which you
           can authenticate:


           Your browser must have JavaScript enabled to use this page. Select
           the jurisdiction (LA), enter the username (sandy) and password, and
           then click "Login". If all is well, you should see the "DACS
           Authentication Succeeded" page, which is the contents of
           /usr/local/dacs/www/handlers/auth_ok.html. Of course in a
           production environment you would write custom login and signout
           pages, or integrate the functionality with a portal or in whatever
           way you prefer for your site.

        4. Things get a bit more interesting now that you are able to
           authenticate. You can follow one link on the "DACS Authentication
           Succeeded" page to see your current credentials (using
           dacs_current_credentials[47]) or another to visit a page that will
           allow you to signout (dacs_signout(8)[48]) from all or some
           identities (you can also invoke dacs_signout directly[49] to
           signout from all identities). If you signout, there will be a link
           that you can follow to login again.

        5. Now use dacspasswd to create another account:

               % $bin/dacspasswd -uj LA -q -a don

           If you are curious, you can take a peek at the password file, which
           we have configured to be $la/passwd.

           You can now authenticate as sandy or don. You can have more than
           one identity active at the same time (i.e., you could be signed on
           as both sandyanddon), but this is disallowed by default; see

        6. Now that you're able to authenticate, let's have another try at
           running dacs_conf (recall you were not granted access to it
           earlier). We must first make one of the identities that you have
           created a DACS administrator identity. Edit $la/dacs.conf and add
           the following text in the Jurisdiction section for
           dodgers.dacstest.dss.ca (but not within the Auth section):

               ADMIN_IDENTITY "LA:sandy"

           As you might assume, this confers special privileges to LA:sandy.

           Authenticate as sandy using the login page and then try this link
           again (it should work this time):


           If you signout[52] as sandy, then authenticate as don, and try
           http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/dacs_conf again,
           you should be denied access.

        7. In an earlier step, you created an ACL ($la/acls/acl-tutorial.0)
           that grants access to dacs_prenv to any user, whether authenticated
           or not. Edit that rule and replace:




           Try invoking dacs_prenv[53] when you are not authenticated - you
           should be denied access. Now authenticate and try dacs_prenv[53]
           again - it should work. Edit the rule again and replace:




           Now you should only be granted access if you've authenticated as
           the DACS username LA:don.

   Step 9: DACS-wrapping a web service
       To use DACS to control access to a resource, there are just a few
       things you need to do:

       •   Make the URL space in which the resource lies within the scope of a
           Location[54] directive for the VirtualHost that corresponds to the
           DACS jurisdiction responsible for the resource.

       •   Make an appropriate DACS access control rule for the jurisdiction
           responsible for the URL space in which the resource lies.

       Basically, you have to configure Apache to allow DACS to perform access
       control for the resource, and you have to configure DACS to enforce the
       selective access that you want. This is ordinarily both easy to do and
       something that is done infrequently because closely related resources
       are typically grouped together within the URL space you have defined
       (for example, all image files may be collected under /images in the URL
       space, related applications are collected somewhere under /cgi-bin, and
       so on) and because ACLs can be written with wildcard patterns that will
       match everything "under" a given URL space prefix.

           It is important to verify that all resources that you intend to be
           DACS-wrapped really are access controlled and that DACS cannot be
           bypassed (e.g., by using different URLs for the same resource). For
           instance, despite many improvements, getting Apache'sVirtual
           Hosts[55] configured exactly as you require can be challenging -
           make sure that security cannot be bypassed through selection of a
           particular hostname or port number.

           Also, note that DACS performs access control on resource names
           rather than on the resources themselves. This means that if a
           particular resource is known by multiple names, because of symbolic
           links, for example, then to correctly manage access to the resource
           all of its names must be DACS-wrapped.

   Step 10: What's next?
       Having successfully completed all of the previous steps, you should
       have a feel for some of the things that you can do with DACS. Of
       course, there's much more to DACS than what we've covered. You should
       be capable of using the system you've configured to this point to try
       some things on your own. Here are a few ideas (in order of increasing

       •   Add a DACS-wrapped resource and experiment with access control
           rules. It might be a static web page or a CGI program. Remember
           that by default, your site-specific ACLs for the jurisdiction LA
           are files in the $la/acls directory. Review dacs.acls(5)[56] before

       •   Assign a few roles to DACS user sandy and modify an access control
           rule to consider roles when granting or denying access. Roles
           provide a convenient way to classify users so that access control
           rules can be concisely written to grant (or deny) access to a set
           of users that are related in some way. For example, you might
           assign some users to "students", some to "staff", and some to
           "faculty", and then write rules that reference those roles rather
           than individual DACS usernames. Roles only have meaning with
           respect to how they are used in ACLs, so you can make up any
           syntactically valid words you want.

           Here are some hints to get you started. You'll need to do two
           things: assign roles to users and enable roles. Once enabled, your
           DACS will look for roles in the file $la/roles. Each line of that
           file assigns roles to a user and consists of the username, a colon,
           and a comma-separated list of roles. For example:


           The other thing you'll need is some DACS configuration to enable
           roles. Add the following to the Jurisdiction section of dacs.conf:

               <Roles id="roles">
                 URL "http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/local_roles"

           Now you can create rules that depend on the user making the request
           having certain roles. For example, a rule can be written to grant
           access to a resource only if the user making the request has the
           role "pitchers" by using the predicate (see dacs.exprs(5)[57]):


           Or you can create a rule that will grant access only if the user
           has the roles "active-players" and "pitchers"; use the predicate:

               user("%LA:pitchers") and user("%LA:active-players")

       •   If you create a DACS account for a username that corresponds to a
           user on your system, you can configure DACS to assign roles to that
           user based on the Unix groups that she belongs to. This is very
           easy to do: instead of using local_roles as in the example above,
           use local_unix_roles instead. If you create a DACS account for
           alice, for example, and the account "alice" has group membership on
           your system (see group(5)), then alice would authenticate using her
           DACS password and be assigned roles from her Unix group membership.

           Instead of using a DACS account to authenticate alice, you can
           easily configure DACS to use alice's Unix password. The DACS module
           local_unix_authenticate, which must be installed set-uid root so
           that it can access passwords, provides this functionality.

       •   Add a DACS jurisdiction named NY (yankees.dacstest.dss.ca) on the
           same host where you configured dodgers.dacstest.dss.ca. You do not
           have to configure authentication at the new jurisdiction. Notice
           that you can authenticate at dodgers.dacstest.dss.ca and then
           access resources at yankees.dacstest.dss.ca. This is "single

       •   Run DACS on an additional host. The procedure is basically the same
           as what you already did in this tutorial. Name the jurisdiction
           BOSTON and assign it the domain name redsox.dacstest.dss.ca. You
           won't be able to use the IP address for this; you'll have
           to alias the domain names to the IP addresses of real interfaces
           and make the same changes to /etc/hosts on both hosts. You'll also
           have to use the identical federation_keyfile on both hosts (simply
           copy the file you've already made).

       •   Configure a different (or additional) authentication method for
           your jurisdiction. See dacs_authenticate(8)[58]. For the password
           style of authentication, you might try the NTLM authentication
           method. For a bit more of a challenge, see if you can make the expr
           or cert style of authentication work.

   Step 11: Clean up
       If you are done, you may want to do some clean up now. First, stop

           # /usr/local/apache-dacs/bin/apachectl stop

       Next, delete dodgers.dacstest.dss.ca and any other domain names you
       created for this exercise from /etc/hosts. Delete any groups you
       created. Remove /usr/local/apache-dacs, /usr/local/dacs, and everything
       underneath them.

       The first thing to do if you encounter a problem is to check that
       you've got the latest version of DACS; a newer version might fix your
       problem. Also, visit the Post-Release Notes[59] area for your release
       in case a newer edition of this document is available or a bug fix has
       been posted.

       By default, the DACS log files are put in the /usr/local/dacs/logs
       directory. If you encounter any problems or just want to see what's
       going on, examine the log files in that directory. Depending on the
       DACSLOG_LEVEL[60] and LOG_FILTER[61] directives in effect, log files
       can quickly become big. It is safe to delete them or truncate them at
       any time.

       In the event of problems, you should also take a look at the Apache
       logs (in /usr/local/apache-dacs/logs).

       There are five main sources of problems:

        1. Typos (you got the spelling or punctuation incorrect, or didn't
           paste text correctly),

        2. File permissions are incorrect (DACS cannot read or write its files
           or directories),

        3. You didn't follow the instructions correctly (you skipped something
           or misunderstood something),

        4. You ran into unexpected platform dependencies, or

        5. We goofed.

       If you're sure the problem is either of the last two types, please
       contact us[6]. and tell us what happened. Be sure to mention which
       steps succeeded and which one failed.

       dacs(1)[62], dacsinit(1)[28], dacs.readme(7)[3], dacs.install(7)[4]

       Distributed Systems Software (www.dss.ca[63])

       Copyright2003-2013 Distributed Systems Software. See the LICENSE[64]
       file that accompanies the distribution for licensing information.

        1. FAQ

        2. manual pages

        3. dacs.readme(7)

        4. dacs.install(7)

        5. an Apache configuration task

        6. contact us

        7. Apache

        8. OpenSSL

        9. Expat

       10. OpenSSL

       11. Expat

       12. detailed instructions

       13. VirtualHost

       14. Directory

       15. Alias

       16. DocumentRoot

       17. netstat(1)

       18. sockstat(1)

       19. Listen

       20. User

       21. mod_suexec

       22. Group

       23. group(5)

       24. mod_auth_dacs

       25. httpd.conf

       26. LoadModule

       27. dacs.conf(5)

       28. dacsinit(1)

       29. Initial Configuration

       30. earlier

       31. SECURE_MODE

       32. dacs.groups(5)

       33. dacsconf(1)

       34. dacskey(1)

       35. dacs_acs(8)

       36. http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/dacs_prenv


       38. dacs_acs(8)

       39. dacs_version(8)

       40. dacs_list_jurisdictions(8)

       41. dacs.acls(5)

       42. dacs.exprs(5)

       43. dacspasswd(1)

       44. htpasswd

       45. Stephen Root

       46. dacs_authenticate(8)

       47. dacs_current_credentials

       48. dacs_signout(8)

       49. invoke dacs_signout directly



       52. signout

       53. dacs_prenv

       54. Location

       55. Virtual Hosts

       56. dacs.acls(5)

       57. dacs.exprs(5)

       58. dacs_authenticate(8)

       59. Post-Release Notes

       60. LOG_LEVEL

       61. LOG_FILTER

       62. dacs(1)

       63. www.dss.ca

       64. LICENSE

DACS 1.4.28b                      02/04/2014                     DACS.QUICK(7)