Access Control List Fundamentals

The Access Control List, commonly referred to as the ACL, is used to manage database access for users. The ACL is incorporated into all Lotus Notes databases and is an integral part of its operation. It controls not only who can access the database but also what functions they perform and what data they can see (or access). At the most rudimentary level, the ACL consists of the following main components:

• Person, group, or server
• User type
• Access level definition
• Access role

Although the ACL dialog contains many additional settings, these areas are used to determine what functions and data are available for all users and other Domino servers (see Figure 19.1).

Person, Group, and Server

A database user can be characterized as a Person, Group, or Server (see Figure 19.2). A Person is defined as a single Lotus Notes userID (such as Mark Elliott/Raleigh/IBM). Individual users are typically added to the ACL when few in number or when a person needs a specific security setting. However, best practices recommend that individual user names not be added to the ACL directly. Instead, all users should be included in one or more groups that are included in the ACL.

A Group contains one or more persons (or servers) where all members in the group have the same access permission or role in the database. When working with groups, only the group name is placed in the ACL. All persons or servers associated with the group are actually managed via the Domino Directory (see Figure 19.3). This approach should be utilized when managing users that require similar access levels and permissions. A group can be created for persons, servers or a combination of both.

A Server, as the name implies, is defined as a single Domino server. This third type permits other Domino servers to access the database. Again, consider using groups to manage ACL settings for multiple database servers.

User Type

The user type value indicates to the Domino server the category of user that will be accessing the database. This is an additional layer of security that prevents or limits certain database functions when the user and user type values in the ACL fail to match that of the user accessing the database. All users must be associated with one of the following values:

Unspecified Signifies that the users type is unknown or not defined in the ACL.

Person Signifies that the user is a single person.

Server Signifies that the user is a single server.

Mixed Group Signifies that the user is a group that potentially contains one or more persons and/or servers.

Person Group Signifies that the user is a group that contains one or more persons (and does not contain any servers).

Server Group Signifies that the user is a group that contains one or more servers (and does not contain any persons).

Note

Always be sure to associate the user with the correct user type. For example, the user type for groups should be Mixed Group, Person Group, or Server Group. If the user is not correctly associated with the correct user type, access to the entire database may (or may not) be available to the user(s).

Access Levels

The access level determines what actions a given user can perform in the database. There are seven access levels that can be assigned. All users in the database ACL must be assigned one of these access levels. The following describes each level in order from the least to greatest level of authority.

No Access Prevents user access to the database. Users are unable to add the database to the Lotus Notes workspace, open the database, view information, or perform any actions with the database.

Depositor Users can only compose or create new documents. However, no data is visible in any of the views. This access level might be used in a customer survey or feedback database application.

Reader Users can view existing documents and information but cannot create new documents in the database.

Author Users can create new documents and modify/delete their own existing documents. Users cannot modify documents composed by another user. However, its important to understand that security settings on the form can override the database access level settings. If the form contains a "Readers" or "Authors" field, these settings will supercede those set in the database ACL. Note that controlled access sections and encrypted fields may be used to further refine access.

Editor Users can create new documents as well as modify or delete any document (both their own and others) in the database. However, its important to understand that security settings on the form can override the database access level settings. If the form contains a "Readers" field, these settings will supercede those set in the database ACL. Note that controlled access sections and encrypted fields may be used to further refine access.

Designer Users can perform all of the same transactions available to lower access levels, plus they have the ability to modify the database design and create a full-text search index.

Manager Users can perform all of the same transactions available to lower access levels, plus they have the ability to modify the ACL, encrypt the database design, modify replication settings, and delete the database.

Access Role

Another method to refine access to data and design elements is through the use of roles. A role is a special security setting that is defined in the ACL and referenced by the database design. Using roles, you can further refine database functionality, display of information, and ability to edit content. For example, with roles, you can manage

• What views are displayed
• What data is displayed
• What forms can be used to create new documents
• What action buttons are displayed
• Who can modify documents and when
• Who can edit a particular section of data

Each person, group, or server in the ACL can be assigned one or more roles in the database. However, its important to recognize that the creation of roles in the ACL is only half of the equation. The role subsequently needs to be married to functions in the database design. In other words, simply creating and assigning a role to a person has no effect unless the role is utilized and integrated into the database design.

Lets take, for example, a procurement request database where each request requires three distinct approvals before the item can be ordered. Each request must be approved by the persons immediate business manager, finance manager, and an executive manager. Each of these approvals could equate to a role. These roles could then be utilized in the database design.

As in Figure 19.4, you could create a separate set of "Approve" and "Decline" buttons for each of the three roles. Only persons assigned that role could click one of the associated buttons. When a person with the given role clicks the button, fields on the database can be updated and the buttons can be hidden.

In many cases, the role is utilized in the "Hide When" formula for an action button, controlled section, paragraph, or field. They can even be used to control the display of forms, views, and other design elements for the database. Youll learn more about how to create roles later in this chapter.

After one or more roles have been created, they can be integrated into the database design. For example, roles can be used to control the display of the action button through the Hide action if formula is true property. Including a formula similar to the following will allow only users with the "ProcureMgr" role to see and use the button.

@IsMember("[ProcureMgr]";@UserRoles)