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:
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.
