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.
Perhaps it's just us, but despite working with Apache for many years, we have found that it can often be unconscionably difficult to configure to do what you want, and to be certain that it is not doing something you do not want.
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 DACS.
Quick Start Steps:
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 Apache 2.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 required.
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.
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.
127.0.0.1 localhost dodgers.dacstest.dss.ca
hostip hostname dodgers.dacstest.dss.ca
For example, on my system I used:
10.0.0.125 i7.dss.ca i7 dodgers.dacstest.dss.ca
So the hostip I selected above is 10.0.0.125.
% ping dodgers.dacstest.dss.ca
(You may need to run it as /sbin/ping or something similar on your system.)
# Permit access to the DACS documents <Directory /usr/local/dacs/www/*>
Options Indexes FollowSymLinks
Order allow,deny
Allow from all </Directory> # Permit access # Configure a virtual host and make the DACS documents available Listen dodgers.dacstest.dss.ca:18123 # Grrr! In some cases it seems to be necessary to use the IP address instead... # Listen 10.0.0.125: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/" </VirtualHost>
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 DocumentRoot[16].
Listen 80 Listen 0.0.0.0:80 Listen [::]:80
# bin/httpd -M
The shared library mod_cgi.so should be in the Apache installation's modules subdirectory or it should have been built-in to httpd; in the former case, also check that there is a LoadModule[21] directive for it:
LoadModule cgi_module modules/mod_cgi.so
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[23] is one approach, but for the purpose of this tutorial we want to keep things simple. Note that setting User[22] (or Group[24]) 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)[25]) 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
% chgrp -R $dacsgroup /usr/local/apache-dacs/ % chmod -R g+w /usr/local/apache-dacs/
# /usr/local/apache-dacs/bin/apachectl start
The reason you must do this as root is because it is required by Apache's User[22] and Group[24] directives.
Failed to enable the 'httpready' Accept Filter
You may be able to fix this by doing (as root):
# kldload accf_http
See this[26].
http://dodgers.dacstest.dss.ca:18123
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 Apache).
# system-config-firewall
(This command was named system-config-securitylevel in earlier releases of CentOS). 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.
% chmod 0750 /usr/local/apache-dacs/cgi-bin/test-cgi
And then invoke it:
http://dodgers.dacstest.dss.ca:18123/cgi-bin/test-cgi
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.
Forbidden You don't have permission to access /cgi-bin/test-cgi on this server.
Make sure to follow the Apache instructions for enabling script execution (e.g., using Options ExecCGI), setting permissions on script files and their paths, and setting up the first line of script files so that they are executed by the appropriate interpreter.
% /usr/local/apache-dacs/bin/apachectl stop
Now it is time to build and install the DACS utilities and web services. Make your working directory the src subdirectory of the DACS distribution.
% ./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 \
--with-ssl=/usr/local/openssl-1.0.1p % 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's Group 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.
We'll continue by installing the mod_auth_dacs[27] module for Apache. Make your working directory the apache subdirectory of the DACS distribution.
% gmake tag % gmake install
If this succeeds, your Apache httpd.conf[28] 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[21] directive.
# /usr/local/apache-dacs/bin/apachectl start
and take another look at the SERVER_SOFTWARE variable:
http://dodgers.dacstest.dss.ca:18123/cgi-bin/test-cgi
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:
http://dodgers.dacstest.dss.ca:18123/man
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 dacs.conf(5)[29]).
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 tutorial.
At this point you can use the dacsinit(1)[30] 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[31].
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 error-prone.
% install -c -g $dacsgroup -m 0640 $feds/site.conf-std $feds/site.conf
SECURE_MODE "off"
% install -c -g $dacsgroup -m 0660 /dev/null $feds/dacs.conf
% install -d -g $dacsgroup -m 0770 $feds/dacstest.dss.ca
% install -d -g $dacsgroup -m 0770 $la
% install -d -g $dacsgroup -m 0770 $la/acls % install -c -g $dacsgroup -m 0660 /dev/null $la/acls/revocations
% 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 file:
<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"
dacs_url="http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs"
authenticates="yes" prompts="no"/>
</group_definition> </groups>
(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)[34] for additional information.
<Configuration xmlns="http://dss.ca/dacs/v1.4">
<Default>
FEDERATION_DOMAIN "dacstest.dss.ca"
FEDERATION_NAME "DACSTEST"
LOG_LEVEL "info"
</Default>
<Jurisdiction uri="dodgers.dacstest.dss.ca">
JURISDICTION_NAME "LA"
</Jurisdiction> </Configuration>
% rm -f $la/dacs.conf % ln -s $feds/dacs.conf $la/dacs.conf
% $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.
% 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.
% 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.
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.
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.
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 </Location>
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)[37]) and the DACS configuration file.
# /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.
http://dodgers.dacstest.dss.ca:18123/cgi-bin/test-cgi
http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/dacs_prenv[38]
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[39] directive in site.conf). This happens because the default rules do not grant access to dacs_prenv, so all access will be denied.
% 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">
<services>
<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}"'/>
</services>
<rule order="allow,deny">
<allow>
user("any")
</allow>
</rule> </acl_rule>
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:
http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/dacs_prenv[38]
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)[40] for additional information.
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.
http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/dacs_version
http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/dacs_list_jurisdictions
You may recognize some of this material from the jurisdictions.grp file.
http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/dacs_conf
Ooops! You should have been denied access to this web service. If you examine the default ACL (see dacs.acls(5)[43]) 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)[44]). 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.
It is possible to create accounts or identities specifically for DACS users. These identities are managed by the dacspasswd(1)[45] utility (there are user accounts managed by other DACS commands, but we will not discuss them here). Similar to Apache's htpasswd[46] 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[47].
% 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.
<Auth id="passwd">
URL \ "http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/local_passwd_authenticate"
STYLE "pass"
CONTROL "sufficient"
</Auth>
This configuration enables authentication (see dacs_authenticate(8)[48]) for accounts managed by the dacspasswd utility. Check again that all files starting with /usr/local/dacs have appropriate permissions, as discussed earlier.
DACS comes with examples of simple HTML login pages with which you can authenticate:
http://dodgers.dacstest.dss.ca:18123/examples/login.html
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.
% $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 sandy and don), but this is disallowed by default; see ACS_CREDENTIALS_LIMIT[52] and AUTH_SINGLE_COOKIE[53].
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):
http://dodgers.dacstest.dss.ca:18123/cgi-bin/dacs/dacs_conf
If you signout[54] 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.
user("any")
with:
user("auth")
Try invoking dacs_prenv[55] when you are not authenticated - you should be denied access. Now authenticate and try dacs_prenv[55] again - it should work. Edit the rule again and replace:
user("auth")
with:
user("LA:don")
Now you should only be granted access if you've authenticated as the DACS username LA:don.
To use DACS to control access to a resource, there are just a few things you need to do:
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's Virtual Hosts[57] 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.
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 difficulty):
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:
sandy:pitchers,retired-players don:pitchers,retired-players eric:pitchers,active-players cesar:infielders,active-players
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" </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)[59]):
user("%LA:pitchers")
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")
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.
If you are done, you may want to do some clean up now. First, stop Apache:
# /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[61] 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 DACS LOG_LEVEL[62] and LOG_FILTER[63] 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:
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)[64], dacsinit(1)[30], dacs.readme(7)[3], dacs.install(7)[4]
Distributed Systems Software (www.dss.ca[65])
Copyright © 2003-2018 Distributed Systems Software. See the LICENSE[66] file that accompanies the distribution for licensing information.
02/19/2019 | DACS 1.4.40 |