Basics of Using Domino/Notes ACL System. ACL Magic, Part 1

I though that it would be helpful to write a series of small articles concerning the Domino/Notes Access Control System.

These will be aimed at inexperienced or medium experience Domino Administrators.  It will also be suitable for people who have a small Notes system and are running it them selves.  There will be tips for even the experienced administrator.

Ok Lets Start:
The Domino Access Control List, or ACL for short, is the Domino way of controlling access to any Domino Databases, be it a mail file, the Address Book (also called Domino Directory) or any other databases.  Domino have many administration databases, such as events4.nsf,  ddm.nsf, catalogue.nsf.  Each and everyone one of these databases has its own ACL.

When you crate a Domino database or even when Domino is 1st installed an ACL will be created automatically for that database.  So if you create a new user they will be assigned an ACL, normally they will get editor access to that databases and you as the administrator will also have admin access to there mail file.

The purpose of the ACL is to protect. This can be show in this Domino Security diagram, I will cover everything in this diagram in this and subsequent articles.

The Notes Access Control List (ACL) is a highly integrated component of the Domino kernel architecture. Present within Notes from the beginning, its design has stood the test of time and use.  The ACL has been around since the beginning (1989).

At the same time, the ACL has evolved to handle an extraordinary number of tasks that traverse the entire Notes environment. Users sometimes find it difficult to understand why (even, how) the ACL works as it does.

Since I don't want to repeat items already documented, I will focus on tips for using the ACL design. Every Notes user can benefit from this article. You can easily understand and apply the ACL, once you assimilate its core structures: the seven access levels (Manager, Designer, Editor, Author, Reader, Depositor and No Access), the five user types (Person, Server, Mixed group, Person group, and Server group) and database roles. You use all these features from the Basics panel of the ACL dialog box to control user and server access to your database.

When you select a user name, the dialog box displays the user type and access level, as well as the detailed access enhancement or restriction options applicable to the access level. Access levels and user types, taken together, specify the maximum access allowed for any user for a given database.

Keep this key point in mind at all times: users can never be granted more access rights than are assigned to them within the Basics panel of the ACL dialog box. As a database manager, you begin by selecting for each user the core rights that belong to a level (some of which are enabled by default) and then enhance or restrict a user's level as needed by modifying the additional options within an access level. A user's access level and the status of the options within that level determine the user's database rights.

I will explore, in turn, each of the four panels of the ACL dialog box: Basics, Roles, Log, and Advanced.

The Basics panel of the ACL

The core functionality of the ACL is contained within the Basics panel. Since this article does not attempt to duplicate existing documentation, we only briefly outline the structure of the dialog box:

Selecting "Show All" in the People, Servers, Groups field displays every user registered for a given database for all seven access levels. Alternatively, you can request a view of Managers only, Designers only, and so on. You can add, rename, and remove users within the ACL dialog box.

When you select a user name, the dialog box displays the user type and access level, as well as the detailed access enhancement or restriction options applicable to the access level. Access levels and user types, taken together, specify the maximum access allowed for any user for a given database.

No Access

This level is self-explanatory. Zero Access.  Nothing.

Depositors and Readers

Depositors can insert documents into a database, but they can't read those documents. Readers, on the other hand, can read documents, but cannot deposit them. Although opposite in function, they complement each other conceptually because each is dedicated to a single purpose. (One additional right Readers have is that they can run agents.)

Authors

Authors can create and edit their own documents. ACL design becomes challenging at the Author level, since varied sub-choices become available.

For example, you can also allow Authors to delete documents. However, they cannot delete just any document in the database. They can only delete documents that contain an Authors field with their name in it. An Authors field is a field whose type is designated as "Authors." The users, groups, or roles specified in the Authors field(s) on a document are considered "owners" of the document if they have been granted Author rights through the ACL. This applies solely to those granted Author rights; anyone with more or less rights than an Author is not considered the document owner, whether or not their name was specified in the field.

People sometimes find it puzzling that Authors cannot create documents by default. (Why, they wonder, would you deselect "Create documents" rights for an Author?). Actually, authorship rights are assigned either because you yourself created the document, giving you those rights by definition (assuming there was an Authors field on the document when you created it), or your name appears in an Authors field for that document.

If your name is not a member of a document's Authors fields, you can't edit or do anything else with that document other than read it. Should you click an "Edit document" button within that document, nothing will happen, even if you created the document.

What guarantees you can edit a document after you have created it? The database Designer must put an Authors field in the document that grabs your name when you create the document. Or, your name could be added subsequently to the Authors field(s) of a document that you did not create.

Editors

Most access options become available (are not grayed out) at the Editor level. What you can restrict, again, is the freedom to delete documents. With deletion enabled, Editors can delete any document, whether or not their own name appears in the document's Authors field(s).

In fact, the delete rights extend only to deletion of the physical document itself. An Editor can always delete a document's entire content (logically, editing out everything in the document), but not the document itself.

Editors can have the ability to create personal agents, create personal folders/views, and create shared folders/views. In Release 3.0, the ability to create shared folders and views was limited to Designers and above. Release 4.0 extended this capability to an Editor, so that users with Editor access in their mail files are not restricted to creating personal folders and views. Their folders and views can reside in the same hierarchy as the rest of the shared folders and views, and they don't need to have Designer access (which would allow them to modify existing forms and views).

In addition to being able to run formulas and simple agents, you can also give Editors the ability to create LotusScript and Java agents.

Designers

At the Designer level, you can allow users to delete documents and create LotusScript/Java agents. Again, the delete rights only refer to the physical document itself. Designers can certainly modify the design of everything, as well as delete the contents of a document.

As for agents, in addition to being able to create personal agents, Designers can create shared agents. If you don't allow Designers to create LotusScript or Java agents, they are restricted from making any LotusScript or Java changes to the database. Otherwise, their rights are nearly complete.

Managers

Managers receive the ability to do everything. This includes assigning themselves the right (or not) to physically delete documents. Delete capability is restricted, by default, as a convenience check to ensure that accidental deletions are prevented. The same reasoning and dialog box behaviour applies to Designers and Editors.

Access priority is No Access, Manager, Designer, Editor, Author, Reader, Depositor.

One specialty in the ACL are the "Public Access" documents. The name is a little misleading. Public access does not mean these documents are available to the general public, but rather, that they are intended for a wider audience. They are created when a form contains the property "Make available to public access users" (this programmatic and can be added to any form by a Notes programmer). This property creates a Notes item with the name $PublicAccess and sets its value to 1. You can use this field in your applications in code and decide on a document by document basis if a document should be available for public access users. In the Notes mail template Calendar entries and contacts are "Public Access" documents. Calendaring was the reason why "Public Access" had been introduced into Notes R4.5. It allowed to grant people access to see your calendar without allowing them to access your eMail. Without this option every eMail would need to be protected by reader fields which would have interesting consequences for routing and database performance.

All this can be summed up in this table:

Table and some text orgionaly created by my good friend:  Stephan Wissel. 

The recommended access for authorized access is Author.

OK that's it for today, next time we will look at:- Creating Agents & Folders, Reading and Writing Public Docs and Roles and user types.  Plus a couple of other fun bits.

Please feel free to add comments, if they are nice one I might even publish them.