Access control in Domino - Part 2: Inside your NSF
So you made it into the NSF. What you can do (or not) depends to a great extend on what you see. What you can see depends on your access level and membership in eventual existing Readers and Authors items (we commonly refer to items as fields, but that's not exact. Fields are the placeholders in forms to enable users to enter items, either explicit by typing them in or implicit by executing their formulas. Items is what gets stored in documents).
There is one item and two item types that govern the visibility of a document for all users and servers. The item has already been introduced in Part 1:
The two item types are Authors and Readers items (mostly added by means of Readers and Authors fields). There can be more than one of each per document, but there is a limit per item type of 32k for all entries of all items of that type. The document properties (see below) also allow to specify readers, but that's just some UI. If anything else than "Readers and above" is specified there, an item with the name $Readers gets created and stored in the document.
Read protection gets activated on a document by document basis once one of the items of type Readers in the document has a non-empty value. The presence of Readers items alone doesn't activate read protection. Domino does inclusive access rights. So once you activate Read protection you have to list (explicit or implicit) all readers to a document. Domino doesn't have a concept of "all except ..."
A common fallacy is to add " to ensure access" the server name or server group name to a document into a Reader item (with the help of a computed Readers field). This activates Read Protection even if it might not be necessary (Read protection costs CPU power, so you don't want it when you don't need it). A better approach is to either add them to an Authors item or anyway have only one computed Readers field that has the server group or role in its formula and pulls in other names using Names items (from user entered Names fields). I often included a Authors item with the value
To determine membership in the permitted Authors or Readers Domino evaluates your name, your group memberships and your roles (for local replicas you need to switch on "Enforce consistent ACL" for that to work).
Keep in mind: you can only edit what you can see, but not all you can see you can edit. Here your access level determines what you can do:
While Author items have no effect on Editor or better access level when it comes to write access, they still are useful since they can ensure that you see a document once Read Protection gets activated. Author access (the read box) is the "Access Level sweet spot" since here one effectively can govern write access to individual documents with Author fields. Below it is "Read only", above "Write anyway". A common mis-perception about Author access is that it allows you access to "your documents" (your as in: created by you). This stems from the discussion template where posts and responses have a computed-when-composed field of type Author with the value
This flexible, document level, declarative access control comes at a price. Once you try to draw the rule RDBMS style the complexity becomes obvious. So when you start using Read Protection you need to take care of view performance, consider if you need NoReader or NoAuthor fields and take care of them once you route or copy such documents (Routing is just a fancy way of saying: copied from one database to another, eventually named mail.box). The Readers and Authors items are evaluated in the context of the database where they are located. When your target database is missing a role or the role isn't assigned to the user/server/group the document just might "disappear" ([Joshua] to the rescue).
There is one item and two item types that govern the visibility of a document for all users and servers. The item has already been introduced in Part 1:
$PublicAccess. If this item exists and is set to "1" (Text!!) a document is considered a public document. If the item is missing or "0" the document is considered a standard document.
The two item types are Authors and Readers items (mostly added by means of Readers and Authors fields). There can be more than one of each per document, but there is a limit per item type of 32k for all entries of all items of that type. The document properties (see below) also allow to specify readers, but that's just some UI. If anything else than "Readers and above" is specified there, an item with the name $Readers gets created and stored in the document.
Read protection gets activated on a document by document basis once one of the items of type Readers in the document has a non-empty value. The presence of Readers items alone doesn't activate read protection. Domino does inclusive access rights. So once you activate Read protection you have to list (explicit or implicit) all readers to a document. Domino doesn't have a concept of "all except ..."
A common fallacy is to add " to ensure access" the server name or server group name to a document into a Reader item (with the help of a computed Readers field). This activates Read Protection even if it might not be necessary (Read protection costs CPU power, so you don't want it when you don't need it). A better approach is to either add them to an Authors item or anyway have only one computed Readers field that has the server group or role in its formula and pulls in other names using Names items (from user entered Names fields). I often included a Authors item with the value
[Joshua] without actually having this role in the ACL (Anybody gets the reference?). Authors items do not activate Read Protection but entitle a member of an Authors item to see a document (you only can edit what you see). So we end up with the following read access table:
To determine membership in the permitted Authors or Readers Domino evaluates your name, your group memberships and your roles (for local replicas you need to switch on "Enforce consistent ACL" for that to work).
Keep in mind: you can only edit what you can see, but not all you can see you can edit. Here your access level determines what you can do:
While Author items have no effect on Editor or better access level when it comes to write access, they still are useful since they can ensure that you see a document once Read Protection gets activated. Author access (the read box) is the "Access Level sweet spot" since here one effectively can govern write access to individual documents with Author fields. Below it is "Read only", above "Write anyway". A common mis-perception about Author access is that it allows you access to "your documents" (your as in: created by you). This stems from the discussion template where posts and responses have a computed-when-composed field of type Author with the value
@Username. In reality "Author access" means: "Write any document that explicitly or implicitly includes one in at least one Author item". In the discussion template that is the document creator, but doesn't need to be that way. In workflow applications one can commonly find scenarios where the original creator doesn't have Author access to the documents she created anymore.
This flexible, document level, declarative access control comes at a price. Once you try to draw the rule RDBMS style the complexity becomes obvious. So when you start using Read Protection you need to take care of view performance, consider if you need NoReader or NoAuthor fields and take care of them once you route or copy such documents (Routing is just a fancy way of saying: copied from one database to another, eventually named mail.box). The Readers and Authors items are evaluated in the context of the database where they are located. When your target database is missing a role or the role isn't assigned to the user/server/group the document just might "disappear" ([Joshua] to the rescue).
Posted by Stephan H Wissel on 27 September 2010 | Comments (3) | categories: Show-N-Tell Thursday