Validation and authentication for Internet and intranet clients

After you set up name-and-password access and create Person documents for Internet/intranet users, Domino® authenticates users either when they attempt to do something for which access is restricted, or Anonymous access is not allowed on the server.

For example, when a user tries to open a database that has an ACL with No Access as the -Default-, Domino® challenges the user for a valid user name and password. Authentication succeeds only if the user provides a name and password that matches the name and password stored in the user's Person document (or in an LDAP directory - some users are authenticated against an LDAP directory rather than a Person record) and if the database ACL gives access to that user. Anonymous users are not authenticated.

You can use name-and-password and anonymous access with TCP/IP and SSL.

This section also applies to Web clients who are accessing a Domino® Web server for which session authentication has been enabled.

Note: The Domino® Web Server Application Programming Interface (DSAPI) is a C API that you use to write extensions to the Domino® Web server. Using these extensions, or filters, you can customize the authentication of Web users. For more information on DSAPI, see the Lotus® C API Toolkit for Domino® and Notes®.

How validation and authentication works

This example describes how a client (Andrew) uses TCP/IP to connect to a server (Mail-E).

  1. Andrew tries to access a database on Mail-E.
  2. The server checks the Internet Site document (or Server document) to determine if anonymous access is enabled for TCP/IP. If it is, then:
    1. The server checks the database ACL for an entry named Anonymous. If Anonymous exists and the level of access for Anonymous is Reader or higher, then Andrew will access the database anonymously.
    2. If the ACL does not contain an entry named Anonymous, the server checks the -Default- access in the database ACL. If the -Default- access is Reader or higher, Andrew accesses the database anonymously using the -Default- access level.
  3. If anonymous access is disabled for the protocol or if the database ACL does not allow anonymous access, then the server checks the Internet Site (or Server document) to determine if name-and-password access is enabled for TCP/IP. If name-and-password access is enabled, then:
    1. The server prompts Andrew for his user name and password.
    2. The server looks up the user name that Andrew entered in the browser. The server uses either More name variations with lower security or Fewer name variations with greater security as the lookup mechanism to search all directories for the name entered.
    3. If a match is found for the user name Andrew entered, and the password that Andrew entered matches the password in the Internet password field of his Person document, then Andrew will be authenticated. The server checks the primary Domino® Directory for the Person document. The server also checks secondary Domino® Directories and LDAP directories if it is configured to search secondary Domino® Directories and LDAP directories.
      Note: When Domino® authenticates an Internet user, it uses the distinguished name (DN), which is the first name that appears in the Full Name field of a Person document. This name should be used in entries for groups, delegated server administration, database ACLs, and file protection documents.

    For users who do not have Person records, and instead have their records in a secondary LDAP directory, the user's LDAP name might appear on the ACL. To allow access to the user, the ACL should include the user's LDAP name (unless the user's name is being mapped to a corresponding Domino® name by Directory Assistance, in which case the Domino® DN should appear on the ACL).

    1. Next, the server compiles a "grouplist," which contains Andrew's distinguished name, plus any wildcard entries and any groups of which he is a member on that server.
    2. The server then checks the database ACL to determine if Andrew's name is listed explicitly on the ACL, or if any of the grouplist entries for his name appear in the ACL.
    3. If Andrew's distinguished name, or the name of any group of which is a member, matches an entry in the ACL, then Andrew gets access to the database using the access level specified for that entry in the ACL. Otherwise, he is denied access.