Access Control in Domino - The Basics

One of the nice effects of XPages is the influx of "young blood" to Domino development. While they have no problems with " the other skills", all things Domino are new to them. Since the first homework I give them is to subscribe to planetlotus.org and create an account on bleedyellow.com to chat with us, I'll post some more entry level articles to help them along. This post is one of them. It introduces Security and Access Control in Domino.
Access Control is strictly hierarchical in Domino. If any access attempt on a higher level fails it doesn't matter if you would have access on a lower level. The resource is locked away. It is like: "it doesn't help you that your car is unlocked if you can't get into the garage where it is parked". The access levels are: server, directory, database and document.

1. Establish the users identity (or the lack of it). This can be through the Notes PKI, Username and Password, a X509 certificate or one of the supported SSO schemes (like LTPA). Authentication is triggered explicit by a logon request (&Login) or implicit when a resource is accessed that requires more access than the current level (that applies to anonymous and authenticated users in the same way)
2. Once identiy is established Domino checks if that user is allowed to access the directory and NSF
3. The ACL is opened and checked what the user can do. This can range from No Access to Manager

The access to a server is governed by the server document and the Internet configuration documents for your Internet domains/subdomains. Default for all Notes clients is to require authentication. Notes client authentication happens with the use of Notes' PKI infrastructure, so the server must trust your ID, OU or O. This happens implicit when you belong to the same OU or O. Once you are authenticated the Domino server can check your authorization. It uses your full X500 compliant name for that (like CN=Peter Pan/OU=Toons/O=Disney). Using a standard Internet protocol like http(s), pop3, smtp or imap authentication uses username and password. For http(s) there is also an option using X509 certificates. Once you have authenticated you also are "known" to the Domino server with your full qualified name X500 style. That name might look different if you store users not in the Domino directory (or an additional NSF based directory) but in LDAP. Stored in LDAP your name could follow LDAP syntax and look different (like cn=Peter Pan,ou=Toons,o=disney). Quite often your admin will allow anonymous access to your Domino server (for convenience in the Intranet or for general viewing in the Internet). In this case you are known as Anonymous. This is also the case if you use Domino designer to web preview a local NSF. Once Domino has established who you are (Authentication) it checks what you can do (Authorization). So you might successful authenticate but the Domino server figures (based on your identity including group memberships) you are not "on the guest list" and will deny you access.
Once you gain authorised access to the server Domino checks the next level of authorisation. If you access an NSF inside the Domino data directory that would be the Access Control List (ACL) of the respective NSF. However when a database is stored in a directory that is linked using a Domino Directory Link an additional authorization check is performed against the security list in the dir file (I haven't seen much use of that, but it is a valid option - especially if you want to hide the existence of an NSF from fellow server users).
The next level check is the ACL.Domino checks the access level based on your name and your group memberships and grants the highest access right found based on a priority check:

1. First it evaluates the ACL and checks for direct entries of the user's name. If one is found that access right is used. Unauthenticated users are known as "Anonymous" and should have an explicit entry as good admin practice
2. Thereafter wildcard entries are used */O or*/OU/O. The access right with the highest priority is granted (more on that in a second)
3. If neither an explicit name nor a wildcard is found group memberships are evaluated. The access right with the highest priority is granted. The detail rights are merged. E.g. one group has Editor access with no deletion rights and the other group Author rights with document deletion you will get Editor rights with deletion
4. If you are neither explicitly listed nor member of any group then the entry for -Default- is applied. Good practice is to have -Default- set to no access

Access priority is No Access, Manager, Designer, Editor, Author, Reader, Depositor. So if you are member of a group with "Editor" access and one with "No access", then you will get "No access". It is good practice to add the global #domain.sys.noaccess group to all your databases (this is not a reserved name but follows my earlier recommendations). Inside the access level there are several rights which you can grant or revoke. What you can add/remove depends on the level:

The help files provides more details on what each of these levels mean. The recommended access for authorized access is Author. You need to learn about Author and Reader fields to make good use of this level (More about that in a later post).
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 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.

There are a number of use cases where "Public Access" can be used. A HR application could show documents during preparation only to HR employees and once they are valid moved to $PublicAccess=1 for general consumption. A feedback form could contain a checkbox "Make this visible to other users of this application". It is up to your imagination how to use this. Once inside an database application further access is granted through Reader and Author fields. A detailed discussion of them is subject to a future post.

In summary:

• Domino authenticates you once (per session) but checks authorization multiple times
• Authentication is soley an administrative responsibility, while authorisation checks can be included in your application.
• While Domino's access control structure is strictly hierarchical, don't rely on the higher level protection. Don't say: " I don't need to add Anonymous with No access to my ACL since this server is configured to not allow anonymous access ". At some point in time that access level might be changed (the garage isn't locked anymore) by an admin decision and leave your application unneccesarily vulnerable.
• Authorization is strictly hierarchcal. If you don't have write access to a database being named in an author field doesn't grant you write access (other groupware is much messier).
• "Public Access" is a mechanism to make some documents available to a wider audience without the need to resort to reader field protection.

As usual YMMV