|
|
We have already described a little about what DACS can do. Let's take a look at one of its major features, single sign-on. If you have more than one web site, or are interested in somehow working with web servers that belong to someone else, and you need to identify users, then single sign-on might be what you need.
Single sign-on is about making it easier for users to work with two or more web sites that have access-controlled areas and easier (and perhaps less costly) for the owners of those web sites to administer them.
Maybe your web resources are spread out among two or more servers. Web page content might be on one server and a database application on another:
Or two or more "administrative entities" might want to cooperate. These could be different labs or departments belonging to an organization, or independent organizations that need to work together on a project or contract.
We will illustrate single sign-on using a hypothetical organization that has three offices (the head office, and Vancouver and Seattle offices), each with its own web site on the Internet:
Besides the need for multiple servers, we must also have a requirement to identify users before single sign-on is appropriate. We might need to identify users for access control purposes or simply to know who our users are. Our example organization may want to allow anyone to look at the public content but restrict access to corporate software to its staff; therefore, staff must authenticate themselves. We can then differentiate staff from the public, who have not authenticated and so are essentially anonymous.
Instead of explaining at this point what single sign-on does, let's see what happens if our web sites do not have this capability.
Remember Bob? Let's say that he is an employee of this hypothetical organization and needs to access web resources (web pages, files, application programs, etc.) that are distributed among the three web sites. Without single sign-on, here is what he has to do:
Yes, poor Bob has to log in to each of the three sites, quite possibly having to use a different account name and password for each server (or arguably worse from a security point of view, using the same account name and password). Furthermore, each of the administrators of these three servers have to create and maintain accounts for Bob. The problems only get worse as we add servers, if Bob forgets a password, or when Bob resigns and loses his access privileges. And don't forget to multiply these problems by the number of employees.
These are the issues that single sign-on solves. With this capability, Bob can log in exactly once, maybe (but not necessarily) at the head office:
The credentials that Bob's browser receives after he successfully logs in will automatically be recognized at any of the three sites:
DACS makes it easy to set up single sign-on among a group of web servers, called a federation. Authentication can be centralized on one web server (with all user accounts accessed and managed through the head office, as in our example), distributed among all the servers (with each user's account located and managed at her office, for instance), or using any combination of possibilities. Different users can be authenticated in different ways, depending on how DACS is configured. Guest accounts, completely separate from any existing account, can be easily created and administered. Authentication methods can be combined, so that a user can be required to provide a password to her existing account plus a system access password. Two-factor authentication methods are supported.
Revoking Bob's privileges to all of the web sites may simply involve deleting his account at one of the servers, making it impossible for him to authenticate, or a centralized access revocation list can be employed. DACS includes a mechanism for tracking each user's activity through a federation.
We have described single sign-on using some simple examples. Of course, there is much more to this feature. And these are not the only ways of using DACS. The next section looks at how DACS uses access control rules.