The Domino server's job is 1) to store data, 2) to accept data only from users authorized to submit data to it, and 3) to send data only to users authorized to receive it. To achieve these goals, Domino server security involves the following considerations:
Who can authenticate with the server
Who can access the server
Who can access each database
Who can access views, forms, and documents within a database
Who can access fields within a form
Authenticating with the Server
To do its job, therefore, the Domino server usually needs to know who the users are when they make requests for data. To learn its users' identity, it requires them to authenticate. Domino supports three authentication modes:
Anonymous If you're accessing Domino using a web browser client and you request access to data that is not restricted, Domino won't require you to authenticate. You will be anonymous to Domino. An example of unrestricted data would be the information on your company's home page. It's freely made available to the public at large. The server doesn't care who you are and just sends it to you.
Name and password If you're accessing Domino using a web browser client and you request access to data that is restricted, Domino will require you to authenticate. You'll have to enter your name and password, which your browser will submit to the server. If the server can match your name to a Person document in the Domino Directory, and your password matches the password recorded there, the server will consider you authenticated. It assumes you are the person named in the Person document.
Certificate-based If you're accessing Domino using the Lotus Notes client, you will authenticate with the Domino server by sending a certificate to it. The certificate is a signed document stored in your Notes ID file. It states that you are the owner of a public key contained in the certificate. By analyzing the signature, the server can determine whether to accept the certificate. If the server does accept it, it will use the contained public key to encrypt a session key, then send the encrypted session key back to you. If you really are the owner of the public key, you will possess a private key in your Notes ID file that can decrypt the encrypted session key. Your private key is unique to you and is the only key that can decrypt data encrypted with your public key. By possessing it and therefore being able to decrypt the session key, you prove to the server that you are the person named in the certificate. The server now knows who you are; you are authenticated.
While you may use the same password when accessing your mail in a browser as when opening your Notes client, they are not in fact the same password. The password you enter in a web browser is your Internet password, which is recorded in your Person document in the Domino Directory. Your Notes password is recorded in your Notes ID and unlocks it so you can extract your private key from it. To change the first, you have to edit the Internet password field in your Person document (or choose Change Password in Domino Web Access, see Chapter 16, "WebMail and Domino Web Access"). To change the second, you choose File, Security, User Security in Notes, then choose Change Password. Your administrator can optionally set up synchronization of the two passwords, so that changing one causes the other to be changed as well.
Because authentication depends on your private key, it is password protected in your Notes ID file. It is very important that you keep your Notes ID password secret. If I could obtain a copy of your ID file and I knew the password, I could masquerade as you. I could gain access to data that only you are supposed to see. I could sabotage you by sending malicious emails while logged in as you. Don't reveal your Notes ID password to anyone!
If you cannot authenticate with a Domino server, Notes may display one of the following messages: "You cannot log in using the supplied User ID file, smartcard or password" or "The server's Domino Directory does not have any cross certificate capable of authenticating you". If you can't authenticate from a browser, you will receive an "Error 401 User Not Authenticated" message.
Having authenticated with the server, you may still not be authorized to do business with it. You must also be in the server's list of users who can have access to that particular server. Just because you can authenticate does not mean you have authority to access all the servers in the organization.
If, when you try to open a database that resides on a Domino server, an access list blocks your access to the server or the database, you will see a message such as this: "You are not authorized . . . ." (The words not authorized will appear in the message.)
If you see such a message, and you think you should be authorized to access the server or the database, tell your administrator the exact wording of the error message. The administrator controls the server access lists and usually the database access lists as well and should be able to correct the problem.
Access Control Lists
After you establish access to the server, the next step is to gain access to databases on that server. Database access is determined by settings in the Access Control List (ACL) for each database.
When you open a database, the Security button on the status bar displays a symbol representing the level of access you have to that database. Click the Security button on the status bar and the Groups and Roles dialog box appears, indicating your access level.
Each person is granted one of seven levels of access to a database:
No Access This denies you access to the database. You can't read any of the documents in the database, and you can't create new documents.
Depositor You can create documents but can't read any of the documents in the databaseincluding the ones you create yourself. You might be granted this access level to cast a ballot in a voting database, for example.
Reader You can read the documents in the database, but you can't create or edit documents. You might have this level of access to a company policy database so that you can read policies but can't create or change them.
Author You can read documents created by others. You may be able to create documents. You may be able to delete some documents. You may be able to edit some documents or parts of them. Whether you can create or delete documents depends on privileges that must be assigned to you along with the assignment of Author access. Which documents you can edit or delete and which parts of a document you can edit depend on the design of the database. Most commonly, though, you will be able to create documents and to edit and perhaps delete only the documents you created.
Editor Editors can edit every document in a database, except ones that they can't read. Typically only one or two people, who are generally in charge of keeping a database, have Editor access.
Designer A designer can do everything an editor can, and can create or change any design elements of the database. To change the design of a form in a database, you must have designer access. Designers can also control some replication settings of a database.
Manager A manager can access everything a designer can. A manager also can assign and modify the Access Control List (ACL), modify replication settings, and delete a database from the server.
Additional permissions in the ACL control whether you can create documents; delete documents; create personal views, folders, and agents; and replicate and copy documents. Also, some databases may have a class of documents called "public documents." You can have read or write access to public documents independently of your level of access to regular documents. The most notable example of such a database is your mail database. All calendar and to-do documents in the mail database are "public documents." This makes it possible for you to give other people access to your calendar and to-do list without letting them read your mail.
Access Controls within the Database
The database access control list isn't the only control over database access. Within a database, there are additional access lists that control who can use certain views and forms, who can read certain documents, and who can edit what parts of documents. In addition, certain fields within a document may be encrypted so that only some people can read their contents.
In general the designer of the database controls these features. But users can control who is permitted to read documents which they created (or can edit). If you have the right to edit a document, you can limit the authorized readers of that document in its Reader Access List. To do so, follow these steps:
Open the document or select it within a view or folder.
Press Alt+Enter to open the Document Properties box.
Select the Security tab.
Deselect All readers and above, then click the Add read access button to the right of the reader list. The Select Names dialog box will open.
Select the names of the people who you want to be able to read the document. Click OK. Then press Alt+Enter to close the Properties box. Save and close the document if it is in Edit Mode.