Setting Server Access

The first true layer of Domino security is at the Domino server itself. As you know, Domino servers can be accessed from the Internet (using a Notes client or Web browser), a network (LAN or WAN), or via a dial-up modem connection. The ability to access a given Domino server is dependent on the type of client you're using (Web browser or Notes client) and how the administrator has configured server access. We'll explore each in the following sections.

NOTE

In most organizations, developers don't have access to modify the Server documents. So, you might need to have your administrator make any required changes to your Server document.

 

Notes-Based Server Access

In a Notes/Domino environment, there are some rules that define communications between clients and servers as detailed in the following list:

When communication is initiated, the server uses settings in its Server document (found in the Domino Directory) to determine what happens next . The security tab of the Server document, shown in Figure 23.1, illustrates the settings used to control server access.

Figure 23.1. The Server document's Security tab.

The exact process used at this layer varies based on the value of the Allow Anonymous Notes Connections setting.

Allow Anonymous Notes Connections

When the Allow Anonymous Notes Connections setting is enabled (set to Yes), any client or server can connect to the server. What this really means is that users and servers without a common ancestral certificate or a cross-certificate have the ability to communicate with the server. Although this might sound a little scary at first, it doesn't mean that they have free rein to run roughshod over your data. In fact, if properly configured, the many lower layers of Domino security prevent anonymous users from accessing inappropriate information.

Disallow Anonymous Notes Connections

When Allow Anonymous Notes Connections is disabled (set to No), a much more complex process, known as authentication, takes place before access is granted. Authentication is a process whereby each end of a connection must prove its identity to the other end before communications can continue. Notes/Domino authentication is based on a challenge/response protocol using the certificates stored in the Notes ID. Because Notes IDs play a pivotal role in this process, a brief overview of the Notes ID is prudent.

There are three basic types of Notes ID files: certifier IDs, server IDs, and client IDs. Certifier IDs are used to create all the other IDs and can also create other certifiers. The first certifier ID that's created for a company is the Organization certifier. This ID file creates Organizational Unit certifiers, or in a small company, it directly creates the user IDs and server IDs. An example of a user ID might be Dave Hatter/Libertas Technologies.

In large companies, many OU certifiers are created so that multiple administrators can certify their users and servers; for example, Leslee Hatter/Accounting/Libertas Technologies. This produces a hierarchical tree that frequently resembles the organizational chart of the company. Although the Organization certifier ID can be created at any time from a Notes client, it's usually created along with the server ID and the administrator ID when the first server in an organization is created. A certifier ID that issues another certifier ID is known as an ancestral certifier. Each ID contains certificates from all the certifiers in its lineage. The certificates used in Notes ID are based on the X.509 standard. For more information on certificates, please consult the Lotus Domino Administrator 5 Help database (help6_admin.nsf).

Figure 23.2 shows a hierarchical diagram for the Rearden Steel Company. The company has three departments: Administration, Production, and R&D. The certifiers for an organization usually match the actual corporate organization; for example, the Production department has a certifier called Production. User and server ID files have names listing all the certificates. The top certifier (the Organizational certifier) is listed last. That way, it's easy to find where users are located. It's also a way for a large organization to differentiate among groups of users. Sometimes, organizations are split up geographically , sometimes functionally. Examples of usernames and their certificates are listed at the bottom of the figure.

Figure 23.2. Certificates often match a company's org chart.

Now that you understand how Notes/Domino certificates come into play, you're ready to explore how authentication works. In its simplest terms, one certified entity (either client or server), which I'll call (A), attempts to establish communication with a server, which I'll call (B). (B) sends a list of its certificates to (A) and asks the entity to compare the list with its own list for a certificate that they share in common. (A) sends back a message indicating the certificate they share. (B) sends (A) an encrypted message using the shared certificate to create the message. (A) decrypts the message and sends it back to (B). (B) reads the successfully decrypted message and says, "Come on in!" But (A) at this point says, "Not so fast!" Because (A) is now not sure if (B) is really who he says he is, (A) performs the same process with (B). Not until both are satisfied that each is who he says he is will authentication be successful. If authentication fails, server access is denied .

Another form of authentication is password-enhanced authentication, which requires that a user's password be checked against the password stored in the user's Person document in the Domino Directory. If the password in the Person document is the same as the password in the user ID file, access is granted; otherwise , access is denied. By default, this feature is disabled, but it can be enabled by setting the Check Passwords on Notes Ids field to Enabled in the Security tab of the Server document.

After authentication has transpired successfully, the server uses the settings in the Server Access section of the Security tab (found in the Server document; refer to Figure 23.1) to determine whether the user or server should be granted access. In particular, the Access Server and Not Access Server settings dictate a user's or server's ultimate capability to gain access to the server.

Users and servers named explicitly or implicitly through a group in the Access Server field are granted access, whereas those named in the Not Access Server field are not allowed to access the server. If there are entries in the Access Server field, all users and servers are granted access to the server unless they're named in the Not Access Server field.

Web-Based Server Access

Before a user can access a Domino server over the Web, the server must be running the HTTP task, which by default causes the server to listen for HTTP requests on port 80. If the HTTP task isn't running or your firewall is blocking port 80, Web users won't be able to access your Domino server.

Assuming that HTTP is running, Web users trying to connect to the Domino server have to play by a different set of rules than a Notes client. That's because Web users don't use a Notes ID and the Web uses a different authentication paradigm in which much, if not most, Web content is available to anonymous (unknown) users.

As you know, when a Notes client user attempts to access a Domino server, the certificates stored in both the server's and client's ID files are exchanged during the authentication process. However, on the Web, Domino doesn't ask for identification until a user attempts to access resources (databases, files, and so on) that are explicitly secured. So, there's not a clear apples-to-apples comparison between server access from a Web client and a Notes client.

Over the Web, there are four ways that security comes into play when accessing a Domino server:

The particular Web authentication options for a Domino server are found in the Ports tab of the Server document, which as you know, is in the Domino Directory. Figure 23.3 shows these settings.

Figure 23.3. The Web tab of the Server document's Ports tab contains the server's Web authentication options.

As you can see in Figure 23.3, there are TCP/IP authentication options and SSL authentication options.

TCP/IP Authentication Options

In the TCP/IP authentication options area of the Server document, you have two choices: Name & Password and Anonymous. If you want to allow anonymous access, set the value of the Anonymous field to Yes; otherwise, set it to No, which does not allow anonymous access. Similarly, you can set the value of the Name & Password field to Yes to allow Web users to authenticate with the server using basic authentication (name and password) or No to disallow it. If you're going to be providing Web-based applications that require security, be sure to set the Name & Password field to Yes.

For a more comprehensive discussion of TCP/IP authentication options, please refer to the Lotus Domino Administration Help 6 database (help_admin6.nsf).

SSL Authentication Options

In the SSL authentication options area of the Server document, you have three choices: Client Certificate, Name & Password, and Anonymous. To allow anonymous access over SSL, set the value of the Anonymous field to Yes; otherwise, set it to No, which won't allow anonymous access over SSL. To enable users to authenticate over SSL using basic authentication (name and password), set the Name & Password field to Yes; otherwise, users won't be able to authenticate using name and password over SSL. Finally, if you need to support user authentication using X.509 client certificates, you can set the Client Certificates field to Yes. If you're going to be providing Web-based applications that require security over SSL, be sure to set the Name & Password field to Yes.

For a more comprehensive discussion of TCP/IP authentication options, please refer to the Lotus Domino Administration Help 6 database (help_admin6.nsf).

NOTE

For more information about SSL and encryption in general, please visit some of the following resources:

http://csrc.nist.gov/pki/

http://verisign.netscape.com/security/pki/understanding.html

http://www.ietf.org/html. charters /pkix-charter.html

http://wp.netscape.com/security/techbriefs/ssl.html?cp=sciln

http://www.rsasecurity.com/

 

Authentication Types

There two types of Web-based authentication that can be used when restricting access to Web-based resources: standard authentication and session-based authentication. Like most things, each method has its pros and cons.

Standard Authentication

By default, the Domino Web server uses standard authentication when Web users attempt to access restricted resources. Under standard authentication, when a Web user attempts to access a restricted resource, the server challenges the user to supply a username and password. This causes the browser to prompt the user with a dialog box similar to the one shown in Figure 23.4.

Figure 23.4. The standard authentication challenge prompt requires that the user supply a username and password.

The user then enters a username and password, which are sent to the server. If SSL is enforced on the resource, the logon information is encrypted before it is sent. If SSL is not enforced, the logon information is sent as clear text. When the Domino server receives the response, it looks for Person document in the Domino Directory that corresponds to the supplied username. If a Person document is found, the server checks the password supplied against the Internet password stored in the Person document. If a match is found, access is granted; otherwise, access is denied.

Each subsequent request to the server for a restricted access causes the browser to send the username and password back to the server for authentication.

Session-Based Authentication

Although standard authentication is often sufficient for many applications, Domino also supports session-based authentication, which provides numerous benefits over and above standard authentication, including substantially improved security.

When a Domino server is configured for session-based authentication, the server serves up a customizable HTML form (consult the Lotus Domino Administration Help 6 database for information on customizing this form) that's used to challenge the user for his name and password. An example of this form is shown in Figure 23.5.

Figure 23.5. A customized session-based authentication login form.

Much like the standard authentication process, when the Domino server receives a response, it looks for a Person document in the Domino Directory that corresponds to the supplied username. If a Person document is found, the server checks the password supplied against the Internet password stored in the Person document. If a match is found, access is granted; otherwise, access is denied.

However, there are several key differences between standard authentication and session-based authentication. First, and most importantly from a security standpoint, the user's password is encrypted. Second, after access is granted, the user's information is stored in a cookie on the workstation, which means that the logon information is sent to the server only once and is read from the cookie for subsequent requests. The two key differences significantly increase the security of Web-based authentication.

NOTE

Obviously, to use session-based authentication, your Web users must use a browser that supports cookies and isn't set to disable cookies.

 

There are three additional features of session-based authentication that make it more attractive and useful than standard authentication. First, session-based authentication supports session expiration, enabling you to configure the amount of time a session can be inactive before a user is automatically logged out. Second, you can specify a maximum number of sessions, which can help control the load placed on your Domino server at any given time. Finally, as previously mentioned (and illustrated in Figure 23.5), you can customize the login form to make it more aesthetically appealing.

NOTE

There are other benefits to session-based authentication that transcend the scope of this chapter. For more information about Session-based authentication, consult the Lotus Domino Administration Help 6 database (help_admin6.nsf).

 

The configuration options for session-based authentication can be found in the HTTP subtab of the Internet Protocols tab of the Server document, which is shown in Figure 23.6.

Figure 23.6. Configuring session-based authentication is easy.

To enable session-based authentication, simply change the value of the Session Authentication field to Single Server if you want users to be authenticated only on the current Domino server. Use the Multi-server setting if you want to support enterprisewide Web authentication. Specify a time-out threshold in the Idle Session Timeout field and the maximum number of sessions to support in the Maximum Active Sessions field. When you've configured these three fields, simply save the Server document and reboot your Domino server and voila! You're now using session-based authentication.

Related

Категории