|
|
If you have read the previous parts of this document, you already know a little about what DACS does. We will now take a closer look at how it is most often used: to help a web server control access to its resources.
Let's say that you must create an area of your web site that should
only be accessed by Bob.
The rest of the site will be publicly accessible.
We will restrict access to URLs that have a path component that starts
like /restricted/...
to keep things simple.
For instance, this URL would be in the restricted area:
https://example.com/restricted/budget.html
How is this done?
Once DACS has been installed, it is an easy, two-step task:
The first step involves adding a few directives to Apache's configuration file:
<Location /restricted>
AuthType DACS
AuthDACS dacs-acs
Require valid-user
</Location>
Only areas of the web site identified in this way will
be controlled by DACS.
We can add more of them as needed.
The second step requires adding an access control rule that will keep out everyone except Bob. If only Bob can be authenticated, the rule need only test if the user requesting access has been authenticated. This rule will suffice:
<acl_rule status="enabled">
<services>
<service url_pattern="/restricted/*"/> 1
</services>
<rule order="allow,deny"> 2
<allow> 3
user("auth") 4
</allow>
</rule>
</acl_rule>
This rule tells DACS that it applies to all URLs that have restricted as their first path component (1), the default behaviour is to deny access to this area (2), and to allow access (3) only to authenticated users (4). Individual resources or sub-areas within the restricted area can have their own rules.
If others can authenticate, or if we would like to be more specific, we could replace (4) with:
user(":Bob")
Or we might restrict access to the IP address of Bob's workstation:
from("10.0.0.123")
Granting access to both Bob and Alice is done as you might expect:
user(":Bob") or user(":Alice")
If we would like to restrict access to staff members and only a staff member can authenticate, then our original rule will suffice. But that rule will not be sufficient if users other than staff members can be authenticated (students or guests, for example). We could list all staff members as part of the rule, but a better solution is to use the roles feature. A user's roles are looked up at the time he authenticates and become part of his credentials. Roles can be obtained by DACS in a variety of ways, depending on how it has been configured.
If we were to assign the role staff only to staff members, we can replace (4) with:
user("%:staff")
After that change, when an unauthenticated user, or a user not assigned the
role staff, tries to access
https://example.com/restricted/budget.html or
https://example.com/restricted/cgi-bin/spreadsheet.cgi,
the request will not be performed by the web server.
New rules, or changes to existing ones, take effect immediately.
Notice that we did not have to do anything else and nothing in the restricted
area of the web site had to be modified in any way.
This rule is still not very interesting. But when we need to, we can easily restrict access to a given date or time, or based on many other things that we can test. We can also inspect the arguments passed to a web service and make our decision based on their values. Complex requirements for granting (or denying) access can be expressed by composing rules, writing expressions that combine tests, or delegating authority.
A difference between DACS and other systems is that a user's credentials do not give him permission to do anything. That is, DACS does not examine his credentials to decide what he can and cannot do. Credentials only identify and describe a user, they do not convey any rights.
There is still much more to DACS than what has been described so far. Please stay tuned.