Database Access Control Lists

The third layer of security is enforced at the database level through the database access control list, which is more commonly called the ACL. Each database has an ACL that lists users, groups, and/or servers that have been granted or denied access. In most organizations, it's the role of the database manager to determine the ACL; in other words, to allow or deny access to users, servers, and groups of users. It's the role of the database developer to understand the ACL and its critical impact on the security of their applications.

Seven database access levels can be granted to users, groups, and servers, as shown in Figure 23.7. An explanation for each of these levels is given in Table 23.1.

Figure 23.7. Each database has its own access control list.

Additional granularity can be provided through the use of roles and special fields. Roles are discussed in the section titled "Restricting Use of Forms and Views with Roles." Reader and Author fields are discussed later in this section as well as in the section titled "Implementing Document-Level Security." If the application has multiple databases, the ACL for each of the databases must be considered .

Table 23.1. Domino Database Security Levels

Level	Access Granted
No Access	None. Any user , server, or group with this level won't be able to access the database.
Depositor	Allowed to create and save a document, but cannot edit that document or read any documents ”not even ones they authored .
Reader	Able to read documents, but not create or edit.
Author	Allowed to create and edit their own documents. Can read other documents and delete their own documents.
Editor	Can create new documents and edit documents, even those created by others. Can also delete.
Designer	All privileges listed previously, but also can design databases.
Manager	All privileges listed previously. In addition, can change the ACL and delete the database.

Access Levels Aren t Always Enough

Even with an access level of Author, unless the Create Documents box is also checked, an author will not be able to create a document. She'll only be able to edit a document that contains her name in a field of Authors data type.

An author cannot edit his or her own document unless the form contains a field of Authors data type that contains the author's name.

No one at any level of the ACL can delete a document from the database if the Delete Documents check box is not checked.

Applying No Access

At first glance, you might think that the No Access level wouldn't be involved in the design of a database, but that isn't the case. Each database has a -Default- entry in the ACL. This entry represents everyone who is not otherwise entered in the list, either explicitly or implicitly through group membership, and provides the default access level in the ACL. If the database is not available for general public access, the manager of the database normally sets the default entry to No Access. This determination needs to be made by the designer in conjunction with the owners and users of the system.

Setting Depositor Access

Although not frequently used, Depositor access can be useful for some databases, such as suggestion boxes databases and surveys. Depositor access grants the ability to create documents but not to see any documents, even those that they created. Chances are that you won't come across many applications where this is necessary.

Setting Reader Access

Users, groups, and servers with Reader access can read documents but cannot edit or create any documents. Reader access can be refined by using a Readers field. If a document has a Readers field, any users, servers, or groups not named in the field won't be able to see the document. Reader fields are discussed in more detail in the section titled "Implementing Document-Level Security," later in this chapter. Although you might not always grant Author or Editor access to a database, Reader access is often used as the default.

An example might be a company policy database. Obviously, only certain individuals are capable of authorizing company policy, but everyone needs to know and understand the policies. Granting Reader access to the entire company, and Author or Editor access to a select group of individuals would handle this situation nicely and is a very common usage of reader access.

NOTE

If a document containing Readers fields has been categorized and a user previously had access, the categories show up in views, but the user is unable to open the document.

 

Setting Author Access

Author access usually allows users, groups, and servers to create new documents and, typically, to edit the document that they've authored. Authors fields can refine this further by specifying a list of users, groups, and servers who can edit the document. Authors fields are discussed in more detail in the section titled "Implementing Document-Level Security," later in this chapter. You might wonder why create access could be turned off for an author. A perfect example of how this is used is the Person documents in the Domino Directory. I can edit my Person document, but I cannot create one. The reason I can edit the document is because I am listed as the Author in the ACL, and my name is in the Owner field, which is an Authors data type. Authors can also be given rights to create personal folders and views. This isn't automatic and applies only to Notes clients . There are very good reasons not to give someone the ability to create personal views. A user with this ability can very easily mimic a view that contains documents that they would otherwise not have access to. In this case, Readers fields can be used to block such access.

Setting Editor Access

Editor access allows users, groups, and servers to edit documents, regardless of the document's author. Additionally, editors can also create documents, but the capability to delete documents can be turned off in the ACL. Editors can also be allowed to create shared folders and views, but users granted this privilege should also understand that it isn't a good idea to create a large number of views. Over time, as users request new ways of looking at data, views tend to proliferate. Too many views can make the database slow and difficult to navigate. Be selective when you assign this role to users of the database.

Setting Designer Access

Designer access provides all the capabilities of Editor access, and it also allows users, servers, and groups to create and modify the design elements (forms, views, agents, and so on) in a database. The only optional capabilities are to create LotusScript and Java agents and to delete documents. In fact, a user with Designer access can be given rights to do anything to a database except modify the ACL and delete the database, which are reserved for those with Manager access.

Setting Manager Access

The primary function of Manager access is to manage the ACL of a database. Additionally, users, servers, and groups with Manager access have the privileges of all the other access levels. The only restrictions that can be set for the manager are delete privileges. The person who is assigned Manager access is referred to as the database manager and is usually also the Domino administrator. When a database is created, the ID used to create it is given Manager access by default.

Setting the ACL for Servers

Like users, servers are also constrained by the ACL in a database. If you have only one server in your Domino environment, this won't be a concern. However, if you have multiple Domino servers or you're sharing databases with servers outside your organization, ACL entries for servers must be considered. Typically, the lowest setting assigned to a server is Editor. This allows all documents to be exchanged, deleted, and modified. You should assign Designer access only to the servers that are responsible for propagating any design changes to the other servers.

The -Default- and Anonymous ACL Entries

As previously mentioned, the -Default- entry in the ACL is used to control the access of any users, groups, and servers not otherwise listed, and is added by default to the ACL of every database. This includes unknown (Anonymous) users accessing the database through a Web browser, unless an entry named Anonymous is included in the list. The Anonymous entry takes precedence over -Default- for Web access, as shown in Figure 23.8.

Figure 23.8. An ACL listing with an Anonymous entry.

By adding the Anonymous entry in an ACL, you can control access by unauthenticated Web users. For example, if you add an Anonymous entry and set the access to None, and set the access for the -Default- to Reader, everyone who attempts to access this database via HTTP will be challenged by the server for a name and password. If they don't enter a valid name and password that can be found in a Person document in the Domino Directory and is also either explicitly or implicitly named in the ACL, access is denied.