What is DACS?

The goal of this document is to introduce you to DACS with as little technical complexity as we can manage.

An Introduction to DACS

DACS is really only about two things: authenticating users and checking for authorization. It is most commonly used for controlling access to a web server's resources and providing single sign-on across two or more web servers.

But what does that mean?

Let's say that you operate a web site through which any user can access three web pages: index.html, alice.html, and bob.html.

Imagine a user sitting in front of a web browser, requesting index.html:

The network in the illustration is probably the Internet, but it could be some other kind of network (a LAN, WAN, VPN, etc.). With no security measures in place, your web server will happily respond to any request that it receives for index.html (or any other of its resources) and return it to the user's browser.

Exactly what do we mean by a web server's resources? Technically, we mean anything, named by a URL, that the web server can retrieve, generate, or execute. Common examples are web pages, data files, images, CGI programs, and servlets.

What if you need to restrict who can look at bob.html, for example? Maybe bob.html is a homework assignment, sales figures, an address book, or some other content that needs to be kept private.

Let's say that only Bob should be allowed to see bob.html. How do we do that?

The solution is to install DACS on your server and configure it to manage access to your web server's resources. Now when your web server receives a request, it asks DACS how to proceed. DACS consults a set of rules that you provide. The rules tell DACS which requests it should grant and which requests it should deny. Because DACS is invisible to the programs that it secures, it does not matter what those programs do, what language they are implemented in, or who implemented them, and they do not need to be modified in any way.

We can add a rule that says "Only Bob is allowed to access bob.html" and another that allows public access to the other web pages. Now Bob is authorized to access bob.html:

When Alice now tries to access bob.html, your web server denies her request because she is not authorized to see that page:

Of course, we can easily add a rule that says "Only Alice is allowed to access alice.html", and leave index.html publicly accessible. Alice's request for alice.html will be granted:

And that's your introduction to authorization.
What about authentication?

We have skipped an important point: how does DACS know that Bob is really Bob and Alice is really Alice?

Before we can place restrictions on who may access something, we must have some way of reliably identifying users. That is the purpose of authentication, and it is a key component of any access control system.

In the most common case, a user identifies himself to DACS by providing an account name and the account's password. This is exactly what you do whenever you login (or "sign in" or "sign on") to your account at a web site.

It is possible to create accounts that are used only by DACS. But organizations typically already have password-protected computer accounts for their users. It is often very desirable, both for an organization and its users, to reuse those accounts as much as possible instead of creating new ones. Although account information can be accessed in many ways and stored in many formats, DACS understands the most popular methods - it can ask your existing software whether an account name and password are valid. So it is often unnecessary to make new accounts in order to use DACS. Because DACS takes an extensible and modular approach to authentication, new authentication methods can be added fairly easily.

To fill in the missing piece above, Bob might enter his computer account name and password to DACS for authentication. If authentication succeeds, credentials are returned to Bob's browser within a cookie. The credentials identify Bob to DACS and are automatically sent by his browser with each of Bob's requests to the server. After checking the credentials, DACS knows that a request really is being sent by Bob because credentials are very difficult for a Bad Guy to capture or forge.

There's a great deal more to DACS than what has been described here - we have only touched on a few of its capabilities! Although the core technologies upon which DACS is built can be applied to a wide variety of problems, we have outlined just one of its applications. It can be used in other ways and applied to different problems.

The second section of this article continues with a look at DACS and its single sign-on capability.

The technical documentation provides additional information about the current release of DACS, its components, and how it is configured.