Category Show-N-Tell Thursday
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
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
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.
- 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)
- Once identiy is established Domino checks if that user is allowed to access the directory and NSF
- 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
). 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
). 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
. 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
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.