Server-level security

You can design your application to access a Domino server via the following modes of authentication:

1. Anonymous authentication: Logs onto the server as an anonymous user. Only accesses databases and servers that are marked to "Allow Anonymous Access." No user name or password values are required.

2. Specified user authentication: Logs onto the server as the user specified in the user attribute and verified by the password provided in the password attribute of any of the following top-level tags:

db, document, form, ftsearch, session, view, mailto, agentrun

The user name specified must be present in the Domino Directory for the server and the password specified must match the user's Internet password, as defined in their person record, or an exception is thrown.

You can cache the user and password attribute values for the duration of a session of a web application using by setting default JSP attribute values.

Note You must be using the Advanced Edition WebSphere server and must have the container authenticate you against the Domino Directory.

You initiate container-managed access in one of the following ways:

• Set the user attribute value in one of the top-level tags to *webuser
• Set the user attribute value in the preset or default tags to *webuser
• Create an initialization parameter for the application by including the following code in the web.xml file:

<context-param>
<param-name>lotus.domino.default.user</param-name>
<param-value>*webuser</param-value>
</context-param>

When *webuser is specified as the user attribute, no value is required for the corresponding password attribute.


To access databases on a server other than the server that the authentication session was created on, add the server to the "Trusted Server" field of the Domino directory.

If you are accessing the Domino server remotely via the Internet Inter-ORB Protocol (IIOP), you must:

• specify the remote Domino server in the host attribute of the session tag or as the default host attribute for the page.
• create a standard Java properties file named security.properties that resides in the Servlet container. This file should contain the SSO secret key that allows for secure propagation of the container's authentication information to the Domino server.
Note With Release M12, support for the security.properties file is not yet implemented.
• If you are doing Single Sign On (SSO), setting the user variable equal to *webuser enables you to use the SSO token for authentication with the Domino server. No security.properties file is required for propagating the container authorization information via IIOP.
Note You must be using the Advanced Edition WebSphere server to use SSO.

Once you have authenticated the user to the server, you can set up conditional access to the database based on the user's:

• access to the database, as defined in its ACL by using these tags:

  ifauthor, ifdepositor, ifdesigner, ifeditor, ifmanager, ifreader, ifnoaccess

• custom roles, as defined in the database ACL by using this tag:

  ifdbrole

Though you can encrypt and sign database fields in the Notes client, you cannot encrypt or sign document items in JSPs.

You restrict document access by creating readers and authors items that contain the names of only those users who are allowed to read or author that document. You set these item values in a JSPs by doing the following:

1. Create a single- or multi-value item using one of the following tags:

• input
• setitem

3. Provide the user name or names of those people you want to give special access to the document to as the item value.

You can display and execute code selectively based on these special authorization settings using the following tags:
• ifdocauthor
• ifdocreader

The Domtags tag library

Glossary