Securing Your Application
Back to Main Menu
Overview
Introduction
Controlling Access to Notes/Domino Data
Tools
The Access Control List
Setting Up and Refining the ACL
Access to Database Elements
Participants
Partners in Securing an Application
Web Users
Anonymous Users
Case Studies
Problems
Solutions
Overview
Introduction
How do I use this Learning Byte?
As a database designer, you can control who has access to an application you create, at every level in the application. Notes/Domino provides a variety of security mechanisms that allow you to control access to applications on several levels. This Learning Byte will help you understand how these mechanisms fit together to secure your application.
As the developer of a Notes/Domino database, you can control user access to both the design elements and the data in your database. Use this learning byte to help you design a comprehensive scheme for controlling how users will access the data in your application. Work closely with your system administrator, because the choices you make have an impact on system performance.
Use this Learning Byte to help you decide how to:
Develop a plan that provides the required security for your data and appropriate access for each user
Set up an access control list (ACL)
Restrict access to database elements
Create roles to manage access for groups of users
Control document access
Back to Table of Contents
Controlling Access to Notes/Domino Data
Access to elements in a database is twofold: It can restrict users from viewing or creating certain elements, or it can be a convenience for users, allowing them to view only what they need to see in a form that is easy to read and use. The database access control list (ACL) and encryption features provide true security. Creating access lists and hiding design elements let you hinder access, but are not true security features. They also provide user convenience, along with computed subforms, hide-when features, and collapsible sections.
Overview of Notes/Domino security architecture
The Domino environment is made up of several components, all of which can be secured. If access is allowed to:
The network, server tests are applied
The server, database tests are applied.
The database, design factors are tested
Design elements, encryption is checked
The following diagram shows the places in the database structure where access tests are applied. These are the elements you will be concerned with in securing your application at the database level:
Tools for controlling access
Setting up the ACL establishes who can access to the database as a whole.
You can further restrict access to database elements by using the following Notes/Domino tools:
Access lists for documents, forms, and views
User roles in the ACL
Authors and Readers fields on a document
Hide-when capabilities for fields, actions, and sections
Controlled-access sections
To control users' access to Notes/Domino data, consider the following situations.
If you want to:
Allow anonymous users access to your site
Create an Anonymous entry in the database ACL.
Define server authentication at the user level for Web users
Create Web users and passwords in the server Public Address Book (PAB).
Restrict access to database elements to specific users
Create access lists for documents, forms, and views, and consider creating user roles in the ACL.
Control Web users' access to parts of your site
- Add the group "Domino Web users" to the ACL
- Choose which databases can be accessed by Web users and what level of access to provide for each database
- Authenticate any Web client accessing a Domino server, database, view, or document
Restrict access to specific documents
Create Authors and Readers fields on a document, or create a document access list.
Control display of database elements within forms
Use hide-when capabilities for fields, actions, and sections, or create a controlled-access section.
Secure field information
Apply encryption techniques.
Display different information for Web users and Notes users
Use @ClientType to enable a computed subform.
Provide an extra layer of security
Add encryption to HTTP transactions by activating Secure Sockets Layer (SSL) at the server. (See Notes Help for more information on SSL.)
Back to Table of Contents
Tools
The Access Control List
Introduction to the ACL
Every database includes an ACL which Notes uses to determine the level of access that users and servers have to that database.
When a user opens a database, Notes classifies the user into an access level that determines privileges. Access level for a user may vary in different databases.
The access level assigned to a user determines the tasks the user can perform in the database. The access level assigned to a server determines what information the server can replicate within the database.
Only someone with Manager access can create or modify the ACL of a database located on a server.
This section covers:
Displaying the ACL
User and server access levels
Displaying the ACL
You examine the access control list of a database to see all the servers, groups, and users who have access to the database.
To display the access control list of a database:
1. Select the database on your workspace.
2. Choose File->Database->Access control:
User and server access levels
A database's ACL determines the level of access that users, groups, and servers have. Someone with Manager access to the database assigns levels to the users, groups, and servers listed in the ACL.
Click here to display a table describing the available access levels.
Server access levels are often the cause of databases failing to replicate as expected. Keep the following points in mind:
Servers not specified in the ACL have the access level assigned to the -Default- group.
Listing a server with Manager access in the ACL lets people know which server has Manager access.
To allow a replica to receive changes made by people with Author access, assign the server Editor access or higher in the replica ACL.
Back to Table of Contents
Setting Up and Refining the ACL
When you set up the access control list (ACL), you can refine access for users in several ways, beyond simply specifying an access level:
Users, groups, and servers
When you enter users in the ACL, you can specify whether they are user, groups, or servers.
User types
User types you specify help you manage security and establish certain rights and privileges for the groups, individuals, and servers you enter.
Access options
Assigning access options allows you to further refine user access.
User roles
Roles allow you to define responsibilities in the application and refine access rights to database elements.
Users, groups, and servers
A group is a list of users and / or servers which have something in common. Using a group helps simplify many administration tasks. For example:
A group of users can be given access to a database in the ACL.
A group of servers can be designated as permitted to replicate with a database.
A group of users can be denied access to a resource.
Note: Groups you specify in the ACL must be listed in the server address book.
There are two default server groups in the ACL:
LocalDomainServers are servers in the local domain.
OtherDomainServers are servers in other domains. These are usually servers in other companies with whom users in your company need to communicate.
Adding users and groups
You must be a Manager in a database to add users to its ACL. To add users, follow these steps:
1. Choose File->Database->Access Control to Display the ACL.
The Basics page appears:
2. Click Add. The Add User dialog box appears:
3. Enter the name of a user, group, or server.
(Alternatively, you can click the icon button to display the PAB and select a user or group name.)
4. Click OK.
5. Select a user type from the User type drop-down list:
6. Select an Access level from the Access drop-down list:
7. Close the ACL window when you are finished adding users.
User types
The ability to specify user types lets you clearly indicate whether a name is that of a person, server, or group.
You can assign a user type on a case-by-case basis or assign a user type to all Unspecified names, except for the -Default- entry, which is always listed as Unspecified. Click here to display a table that describes each user type.
Assigning user types for additional security
Assigning user types can provide additional security. Specifying names in the ACL as a Person, Server, or Server group prevents someone from either:
Creating a group in the PAB with the same name and adding his or her name to it to access the database through the group name
Accessing the database from a Notes workstation using the server ID
Note: Designating a name as a Server or Server group is not a fool-proof security method. It is possible to create a Notes add-in program that gains access to the database from a workstation through the server ID, since the add-in program behaves like a server.
Access options
When you add users and groups, you can specify individual options that further refine user access. For each ACL entry, you can specify slightly different options:
Click here to display an access options table.
You can specify the availability for public access of a database element at the bottom of the Security tab in its Properties box:
Roles in the ACL
When a group you want to add to the ACL does not exist in the PAB, you may want to create a special group or role for users of the database. Roles let you define responsibilities in the application and further define access to database elements.
What is a role?
A role is a subset of the ACL that is controlled by the database manager. A role can be used anywhere a group or user name can be used. Users and groups are assigned roles to refine access to particular views, forms, sections, or fields of a database. Instead of assigning access to a design element to users and groups, you assign access to the role.
Some advantages of using roles are that they:
Provide a flexible method of restricting document access to a specific set of users
Can be used in formulas
Provide group control if you do not have the right to create groups in the PAB, or if you want to create groups just for the database
Make it easier for you to modify access when users leave or new users join
To use a role in an application:
1. Add the role to the ACL.
2. Assign roles to users and groups in the ACL.
3. Include the role in access lists, just as you do with users and groups.
You can use roles along with users and groups in access lists, or in place of them.
Adding roles to the ACL
To add roles to an ACL, follow these steps:
1. Open the database's ACL.
2. Click Roles in the contents pane.
3. Click Add. The Add Role dialog box appears:
4. Enter a role name no longer than 15 characters and click OK. The role name appears in brackets in the role list.
Assigning roles to users
To assign a role to a user:
1. Open the database's ACL.
2. Select the user's name in the list of People, Servers, and Groups.
3. Click one or more role names in the Roles list.
4. Confirm roles by highlighting a user:
A checkmark appears next to the user's role or roles.
Back to Table of Contents
Access to Database Elements
Notes/Domino provides a number of tools that can override the ACL in granting or denying access to individual design elements or data for specific users. The following overview has links to information about these tools:
Access tools
Views
Creating a view read access list lets you specify who can see the view.
Forms
Creating a form create access list lets you specify who can create documents using the form.
Documents
Creating a form read access list lets you specify who can read documents created with the form.
Readers fields let you control who can read documents.
Authors fields let you control who can edit documents.
Encryption features
Use encryption to secure data at the field level.
Programming considerations
You can use programming techniques to control the user's access to documents and design elements.
View Access List
To control which views each user has access to when he or she opens the database, create a view read access list. The list can contain any users, groups, servers, and roles that are in the ACL for the database.
Caution: By default, when a user opens a database for the first time, the "Default" view is displayed. Therefore, never restrict the default view for the database. Users will not be able to open the database if they are restricted from the default view.
Creating a view access list
To create a view read access list:
1. Open the view in design mode.
2. Select Design->View Properties to open the Properties box for the view.
3. Click the Security tab (key icon).
4. Deselect All readers and above (the default). The list in the window displays the contents of the ACL:
5. Click one or more of the users, groups, servers, and roles to which you want to give access to the view. A checkmark appears next to the names you click.
6. Click the blue person button to add names, roles, and groups to the list from the address book, and make sure they are added to the ACL.
To deny access to the view, click a name to remove the checkmark.
Form Access Tools
You can control access to a form in several ways:
Exclude the form from the create menu and make it available to a select set of users with a view action button.
Control the form used under differing circumstances by creating a form formula in a view.
Create a form create access list that specifies who can create documents with the form
Create a form for Public Access users with Read or Create rights in the access control list (ACL)
Making a form available to a select list of users
This method has two parts:
Exclude the form from the Create menu.
Create a view action button that is available to a select set of users.
To prevent a form from appearing on the Create menu:
1. Open the form in design mode.
2. Select Design-> Form Properties to open the Properties box for the form.
3. On the Basics tab (the default display), deselect the option: "Include in: Menu"
To create the action button:
1. Open a view that displays the form in design mode.
2. Create a view action using the formula @Command([Compose];"formname").
3. Open the Action Properties box and click the Hide tab.
4. Write a formula to hide the view from everyone except the users and groups you specify.
Creating a form formula in a view
When a user opens a document in a view, the form formula controls which form is used to compose or display a document under different conditions. The form formula is optional.
To set the form formula for a view:
1. Open the view in design mode.
2. Open the View Properties box to the Advanced (beanie icon) tab:
3. Click the Formula Window button for the Form Formula selection.
4. Enter the appropriate formula to display documents with the proper form. Note that the formula must evaluate to the name of a form.
Example: The following formula creates new documents using the "Open New Discussion" form and accesses existing documents using the "Main Topic" form:
@If(@IsNewDoc; "Open New Discussion"; "Main Topic")
Form access lists
Form access lists override the ACL and allow only those in the list access to the form or documents created with it:
A form create access list allows only those in the list to create documents using the form.
A form read access list allows only those in the list to read documents created with the form.
Creating a form create access list
To create a form create access list:
1. Open the form in design mode.
2. Select Design->Form Properties to open the Properties box for the form.
3. Click the Security tab (key icon).
4. In the "Who can create documents with this form" section, deselect All authors and above (the default).
The list in the window displays the contents of the ACL.
5. Click one or more of the users, groups, servers, and roles to which you want to give the ability to create documents with the form. A checkmark appears next to the names you click.
6. Click the blue person button to add names, roles, and groups to the list from the address book.
(Make sure they are added to the ACL before you make the database available to users.)
To deny access to the form, click a name to remove the checkmark.
Creating a form for public access users
A public access list works with the database ACL to expand user access to specific views, forms, and documents. Creating forms and views enabled for public access allows you to provide users with No Access or Depositor access the ability to view specific documents, forms, and folders without giving them Reader access to the entire database. Users who have this access level in the database ACL will see only documents, folders, and views specified as available for public access in the Form/Folder/View Properties box.
Public documents are useful for calendar applications where one user might delegate to another user the ability to read or create appointments on his or her behalf.
To create a form for public access:
1. Choose Design->Form Properties.
2. Click the Security tab.
3. Select "Available to Public Access users."
4. Create a field and open its Properties box.
5. In the Name field, enter $PublicAccess.
6. In the Type field, select Text and Computed when composed.
7. In the design pane, enter 1 as the default value for the field and click the green check mark to accept the value.
8. To hide this field from users, select the Hide tab and specify hide-when conditions in the Field Properties box.
9. Save the form.
Document Access Tools
Individual documents can contain sensitive information. Notes/Domino security provides several mechanisms that can restrict access to a document. You can control both reader and editor access to documents:
Restrict Reader access to documents in two ways:
-- Create a read access list for all documents created with a form.
-- Use a Readers field.
Restrict Editor access to documents to those named in the Authors field.
Combine Readers and Authors fields.
Read access list for a form
A read access list for a form refines the ACL by allowing only those named in the list to read documents created with the form.
The $Readers field
When you create a read access list for a form, Notes adds the internal field $Readers to the form. The value of the field is the form's read access list. Each document that users create with the form contains the $Readers field's list of readers. If there is no read access list for the form, the documents do not have a $Readers field.
Note: The Author or an Editor of a document can change the read access list of a document by going to the document properties box and changing the selection in the read access list of the security tab.
Creating a Form Read Access list
To create a read access list for a form:
1. Open the form in design mode.
2. Select Design->Form Properties to open the Properties box for the form.
3. Click the Security tab (key icon).
4. Disable the default (All readers and above). The list in the window displays the contents of the ACL:
5. Select (click) specific users, groups, servers, and roles to which you want to give read access for documents created with the form. A checkmark appears next to the names you select.
6. Click the blue person button to add names, roles, and groups to the list from the address book.
(Make sure they are added to the ACL before you make the database available to users.)
To deny read access for documents created with the form, click a name to remove the checkmark.
Readers fields
A Readers field is a field data type that restricts readership for the document to those users and servers that are listed in the field. There are two ways to create a Readers field on a document:
The Designer places a field with the Readers Data Type on a form.
The Author or an Editor of the document opens the document properties and sets the read restriction in the security tab. This automatically creates a $Readers field in the document.
Readers fields have the following characteristics:
Readers fields are an excellent way of restricting replication to users, as only the documents for which a user is listed in the readers field will be replicated.
If a document contains multiple Readers fields, all entries from all Readers fields have read access to the document.
Readers fields restrict reader access on individual documents only; access to each document may be different based on the contents of its readers field.
Editable Readers fields allow authors and editors to enter names of authorized readers.
Caution: If you allow users to enter names of authorized readers, you should also have a separate, hidden, computed Readers field that contains the names of any servers that should replicate the document. Without the server names in the Readers field, the document will not be replicated.
Creating a Readers field
To create a Readers field:
1. Add a field to a form.
2. Select Readers as the field's data type.
3. Specify readers by using one of the following methods:
- Enter user names, roles, or groups directly.
- Use a formula to compute user names, roles, or groups.
- Make the field editable so Authors and Editors can select and change readers.
Authors fields
An Authors field is a Notes reserved field that lets you give users Editor access to their documents when they have Author access to the database.
An Authors field:
Works only in a database located on a server, or on a local replica when the setting "Enforce a consistent ACL" has been selected.
Refines the ACL but does not change it.
-- To allow users with Author access to edit documents they create, you must include them in the
documents' Authors field.
-- Users with Editor access can edit the document even if they are not in the Authors field. (Use Readers
fields to prevent users with Editor access from reading the document, since if Editors cannot read the
document, they cannot edit it.)
-- Users with No Access, Depositor access, or Reader access cannot edit the document even if they are in
its Authors field.
If you add only one Authors field to a document and it contains a null value, then only an Editor or above can edit the document.
Creating an Authors field
To create an Authors field:
1. Add a field to the form.
2. Select Authors as the field's data type.
3. Specify who the authors are by:
-- Entering user names, roles, or groups
-- Using a formula to compute user names, roles, or groups
-- Making the field editable so Authors and Editors can select and change authors.
Combining Readers and Authors fields
Use this table as a quick reference in determining how Readers and Authors fields protect your document.
Encryption Features for Notes Field Security
Encryption allows you to secure information at the field level. You can encrypt the contents of any field so that only readers who have the encryption key can access the message or field. (Note that database managers can encrypt an entire database.)
Users who need to:
Create and save documents with a form must have at least one of the encryption keys you selected in the Default encryption keys list.
Read the encrypted fields must also have at least one of the encryption keys used to encrypt the fields.
Caution: This does not work with Web browser users, as the encryption key must be held in the Notes ID. Do not rely on encrypted fields if Web users are authorized to read documents that contain encrypted fields.
How encryption works for fields
Encryption prevents unauthorized access to critical data in selected fields. Encryption is enabled using encryption keys:
The system administrator distributes the encryption keys to authorized users when deploying the application by mailing the key or giving it to users in a file.
When users receive an encryption key, they merge it with their user ID files.
Encryption methods
You need to choose an encryption method and design for it. There are three ways you can apply encryption:
Automatically: When the user saves the document. You can design a form to automatically encrypt all encryptable fields whenever someone saves a document composed with that form.
Manually: When authors and editors encrypt the document by selecting an encryption key in the document's Properties box
Manually or automatically: When you create a field that generates a list of encryption keys from which the author or editor can choose a key, or when you create a field that contains a formula that selects the key.
Manually encrypting documents
Document authors and editors can manually encrypt a document after they save it. They do this by:
Selecting the document in the view.
Opening the document's Properties box.
Selecting an encryption key.
Encrypting fields within documents
A document can be encrypted only if it contains at least one field designated as encryptable.
To encrypt a document:
Create an encryption key.
Enable encryption for a field.
Creating an encryption key
To create an encryption key:
1. Choose File->Tools->User ID.
2. Click the Encryption icon.
3. Click New.
4. Enter a name that describes the purpose of the key.
5. Enter a comment (optional).
Include the names of the database, form, and fields that use the encryption key in case you need the information later.
6. Click North American if users are going to use the key only in Canada or the US. Click International if users are going to use the key in additional countries.
7. Click OK.
Protect the encryption key by specifying a password for the key when you export it. In this way, only those who know the password can import the key into their user IDs.
Additionally, you can specify that a user who receives the encryption key cannot give it to another user.
Enabling encryption for a field
You can enable encryption for a field manually or automatically. To allow Editors and Authors to specify keys to encrypt their documents, you need to manually enable encryption on the field.
To manually enable encryption on a field:
1. Create a field in a form.
2. Open the field's Properties box.
3. Click the Options tab.
4. Select Security Options: Enable encryption for this field.
To enable automatic field encryption:
1. In the form Properties box, click the Key tab.
2. From the Default encryption keys list, select one or more encryption keys in your ID.
If you select more than one encryption key, all the encryptable fields will be encrypted with all the keys.
Programming Considerations
Notes/Domino provides several @functions that help you control Notes behavior based on the user, or on the client type:
@UserRoles returns a list of roles for the current user.
@UserName returns the user name or server name.
@ClientType returns a text string to differentiate Notes and Web clients.
Using @UserRoles
Use @UserRoles in formulas to either:
Determine what to do for a particular set of users, without needing to use the user's name in the code.
Direct one set of users to one page and another set of users to another page when the user clicks a button.
The @UserRoles function:
Takes no arguments:
@UserRoles
Returns a text list whose value is the role or roles of the current user.
You add code to perform an action based on the returned value.
Note: @UserRoles only works on a server-based database unless "enforce a consistent ACL" is selected.
Examples
To display an action only to people in the DeptManagers role, enter the following Hide-when formula for the action:
@IsMember("[DeptManagers]" ;@UserRoles)
To hide a database element from Web users who have not registered in the address book, create a Registered role in the access control list (ACL) and enter the following formula in the element's hide-when tab:
@IsMember("[Registered]" ; @UserRoles)
You can also use @UserRoles to hide elements based on a role in the ACL or a predefined role such as $$WebClient.
Using @UserName
@UserName returns the current user name. Using @UserName allows you to make the current user's name available to formulas. You can use it to:
Restrict the Edit action in documents created with a particular form based on whether @UserName is equal to the author of the document.
Hide portions of documents in hide-when formulas based on the user name.
Example
The following view selection formula selects only documents created by the current user to display in a private view:
SELECT @UserName=MyView
Using @ClientType
@ClientType returns a text string to differentiate Notes and Web clients. Use @ClientType in formulas for which the outcome is different depending on client type.
Example
Used in a computed subform formula, the following formula inserts the subform "WebHead" if the form is to be displayed on the Web, and the subform "NotesHead" if the form is to be displayed on a Notes client:
@If(@ClientType = "Web"; "WebHead"; "NotesHead")
Back to Table of Contents
Participants
Partners in Securing an Application
Securing a Notes/Domino application is a joint effort. The database designer must work closely with the system administrator and the database manager to successfully design, create, and deploy a secure application.
Depending on the company, the database designer, the database manager, and the system administrator may be one person or three separate people. The system administrator often takes over the responsibility of database Manager when the database is launched. The table shows the tasks that are the responsibility of each participant in an application.
Database Designers
The Designer's role in security
While the designer must design the security plan for the application, it is usually the system administrator who has responsibility for implementing and maintaining the security plan. Therefore, it is essential that you work out your plan carefully, so that you can document it for the database manager. Designers need to:
Work with the server administrator while designing the application so that access levels and replication can be set up properly.
Let the server administrator know whether there are any applications that require anonymous access.
Determine which users and groups have access to which parts of the application.
Decide what roles need to be added to the ACL for each database in the application.
Document design changes for the server administrator so that they can replicate appropriately.
Note: All users and groups need to be listed in the server public address book (PAB) before they can be added to the access control list (ACL) in a database.
Key design issues
Before setting up the ACL for an application, you need to create an access scenario. Use the following questions to create the scenario:
Who is responsible for setting up and maintaining the ACL?
The system administrator usually has charge of the ACL, and the designer documents what is needed for the administrator.
Which users need what kind of access?
The designer needs to inform the system administrator about what access levels to set for which users, servers, and groups.
Can you determine groups of users who need the same kinds of access?
The system administrator needs to make sure the groups are listed in the PAB before adding them to the ACL.
How is the database distributed: by direct replication or by design template?
Design templates allow you to change and replicate the design without disturbing the production database. Design changes happen automatically through the designated template on the same server.
Is there a hub server responsible for replication?
If so, you set up replication so that changes are added to the hub replica, then the hub adds the changes to other servers.
Will this application be deployed on the Web?
If so, it is advisable to always have an Anonymous entry for Web users so that you can specify exactly what Web users can do without registering.
Servers
Server documents in the public address book (PAB) contain restrictions that are used to control access to a server. The database access control list (ACL) refines these restrictions, but cannot override them.
Caution: You cannot use server lists to control access by Web clients. The clients are not authenticated until they try to access a database.
Servers in the database ACL
If there are replicas of a database, add server names and server groups to the ACL. Server access levels affect what information can be exchanged between the replica databases.
It is important to understand which design changes replicate and which do not, and how the database ACL and other replication settings affect the distribution of design changes:
Servers need to have Editor access at minimum, so they can replicate data changes.
Servers must have Designer access to replicate design changes.
Database Managers
Securing servers and controlling access to a domain is the responsibility of the server administrator. In addition, in a production environment, it will be the system administrator who is assigned the role of database manager in the access control list (ACL) for purposes of setting up and maintaining the ACL. The database manager should receive the following kinds of information from the designer:
A list of users, groups, and roles in each database
A comprehensive security plan for each database, so that it can be maintained on the server
All changes that are made in user and group access
Updates to access levels and restrictions
Back to Table of Contents
Web Users
Using basic Web authentication
Users are granted access to the Domino Web server through basic authentication-- the standard for Web security that is based on a challenge / response protocol.
Authentication succeeds if:
When challenged, the user name and password supplied by the user match the user name and HTTP password fields in the Person document of the address book on the server.
The challenge is in response to a request to open a database, and the user is also be listed individually or as part of a group in the database access control list (ACL).
The Web user can be challenged upon initial access to the Web site if restricted, or upon request to open any database that is restricted by the default entry in the ACL of "No Access", or an Anonymous entry in the ACL of "No Access."
All Web users have access to any database on the server that has a default access of Reader. If the database is restricted, a Web user must be listed in the public address book (PAB) with an HTTP password.
You can define additional access privileges and refine the ACLs for an authenticated user for a server, database, document, and so on.
Creating a registration database
You can create a special database through which Web users can register themselves. Notes/Domino provides a sample database for a Domino registration application that you can use as a template to create a Guest Book for your Web application. This sample database is part of a set of samples that are provided with the Domino server software in the Domino/samples folder.
You may not want to keep a list of all of the Web Users who register themselves in your main PAB. You can create a PAB just for Web users to be listed.
Manually registering Web users
To manually register Web users, follow these steps:
1. Open the server's address book and navigate to People.
2. Click Add Person.
3. Enter the Web user's first name and last name.
4. Enter the Web user's full name in the User name field.
5. Enter a password in the HTTP Password field. The password will be encrypted when you save the document.
6. Click Save, and then click Close.
Controlling Web access to Notes data
To set up Web access to your Notes data, you:
Authenticate any Web client accessing a Domino server, database, view or document.
Define server authentication at the user level by creating Web users and passwords.
Choose which databases can be accessed by Web users and what level of access to provide for each database. It is a good practice to create a separate database for the home page and use ACL restrictions to all other databases.
Determine how to handle anonymous users.
Add encryption to HTTP transactions by activating Secure Sockets Layer (SSL) at the server (optional step).
Back to Table of Contents
Anonymous Users
Who are anonymous users?
You can control the level of access to a database for users who are not recognized by the system. This includes both Web users and Notes users who do not share a certificate in common with the server. Such users are considered anonymous users.
Anonymous access to servers
Before anonymous users can be granted access to a database, they must be allowed server access. In the security section of the server document, the administrator defines the security settings in the following ways:
If "Compare Notes public keys against those stored in the Address Book" is:
Yes, then the Notes user must have an entry in the public address book (PAB) to access the server.
No, the Notes user does not have to exist in the PAB to access the server.
If "Allow anonymous Notes connections" is:
-- Yes, then All notes users in the world can access the server.
-- No, then only Notes users who have a certificate in common with the server can access the server.
Anonymous access to databases
You can handle anonymous users in one of the following two ways:
Define an anonymous entry in the ACL and specifically define access privileges for anonymous users.
Allow anonymous users the same access as the Default entry in the ACL.
Note: Any application that will be deployed on the Web should have an Anonymous entry in the ACL.
Differentiating Default and Anonymous access
If Anonymous is not listed in the ACL, Domino grants the user access based on the database's default access level. This may be a higher access level than you want for anonymous users.
Access Level definitions:
Default -- A user not specified in the ACL
Anonymous -- A user without a valid Notes ID for that organization
Controlling database access by anonymous users
If you allow anonymous access to a server, you can still control access to databases. To control database access by anonymous users, follow these steps:
1. Add a user with the name "Anonymous" in the Add user dialog box of the ACL.
2. Click OK.
3. In the Access drop-down box, select either:
"No Access" to prevent access by anonymous users
"Reader" to allow access to an information database
"Author" to allow access to an interactive database.
Caution: If the database ACL does not contain an "Anonymous" entry, all anonymous users receive the Default access.
To protect the databases from unregistered users, you can establish the Default as No Access. If Default access needs to be higher, create an Anonymous entry in the database's ACL and grant it No Access.
Opening Notes databases to the Web
When granting access to unauthenticated Web clients, you will want to grant Anonymous users the least access practical that still allows them to use the database effectively. For example, you might grant Anonymous users:
Reader access for an information database
Author access for an interactive database
Back to Table of Contents
Case Studies
Problems
Technical Information Published on the Web
You are rolling out an application on the Web to provide technical information about the widgets you sell. The users will be of two types:
The anonymous Web user who has purchased your products and will access the database and read the documents that have been created.
A group of employees who will enter the technical information into documents from a Web client.
How will you set up the access control list (ACL) and why?
Solution
Internal sales records
You have a database that stores all of the sales information for the salespeople in your company. Security requirements are as follows:
Each of the salespeople should be able to see his or her own documents, but not anyone else's.
The manager for each region should be able to see the documents for the people in his or her region but not other regions.
The vice president of sales wants to be able to see everything.
The sales people will be replicating the database to their laptops.
What should you use to secure the data and how? What will your access control list (ACL) look like and why?
Solution
Database discussion deployed on the Web
You have a database that will be used for discussion purposes on the Web.
Users who are not registered can only read documents.
Registered users can create and edit their own documents.
What should you do to ensure that the person creating a document can edit it, and how will you set up the access control list (ACL)?
Solution
Back to Table of Contents
Solutions
Technical Information Published on the Web - Solution
In the ACL:
1. Create an Anonymous entry in the ACL and give it Read access.
2. Add all employees who will enter technical information to the ACL to a group as Web editors. Give them Author access.
For the main document form:
1. Create an action to display the main document form in the main view on the Web.
2. Hide the action from everyone except the Web editors.
Internal Sales Records - Solution
1. Give salespeople Author access in the ACL.
2. Create two roles in the ACL: one for region managers and one for the vice president.
3. Create a Readers field on the form that lists the manager of the region and the vice president of sales.
Database Discussion Deployed on the Web - Solution
1. To ensure that the person creating a document can edit it, create an Authors field on the forms they can create.
2. Create a registration database as part of your Web site.
3. The ACL should contain an Anonymous entry in the ACL with Read access, and a Registered users role with Author access.
Back to Table of Contents
| 
