D
Security

Security is a primary concern for any application used to manage sensitive, personal information. A number of options are available to an administrator seeking to enhance or customize the security of a calendar server installation. In addition to increasing the security of the operating environment and implementing good maintenance and monitoring practices, calendar server administrators have access to a configurable, extensible Authentication, Compression and Encryption (ACE) framework.

This appendix describes the structure and configuration of the authentication, compression and encryption methods. Additional security considerations for installations using a directory server are detailed, as well as a number of other measures that may be employed to further protect calendar data.

• ACE framework
• Directory server security
• Other security considerations

ACE framework

The ACE framework was developed to allow administrators to ensure the security and integrity of all data passing between calendar servers, and between server and client.

Data passes between the server and clients, and between multiple servers if nodes are distributed across more than one host. If an external directory is used, data also passes between the calendar server and the LDAP directory server. The ACE framework applies only to communication between the calendar server(s) and clients. See "Directory server security" for a separate discussion of the security options for data passing between calendar servers and their supporting directory servers.

Secure connections may involve the use of compression (to reduce the network bandwidth required for communications) and/or encryption (to enhance the security of network communications). Both compression and encryption increase the amount of CPU time required to prepare the communication for transmission. The impact on performance varies with the methods. In general, the better the compression or the more secure the encryption, the greater the impact on performance.

Secure connections to clients and other calendar servers

Secure connections to calendar clients and other calendar servers are controlled by a configurable set of authentication, compression and encryption methods. These methods are determined at the time the connection is requested. The ACE methods are both configurable and extensible. See "Configuration" for the relevant configuration parameters, and "Extending the ACE framework" for details on extending the available set of methods.

Secure connections to clients

Note: Only desktop calendar clients 5.0 and higher, Oracle CorporateSync 3.0 and higher, Web clients 2.0 and higher and Oracle Outlook Connector support the ACE framework. Other clients including Oracle CorporateSync for Mac 2.1.x require the use of the cs-basic authentication method. If you plan to use Oracle CorporateSync 2.1.x for the Mac, you must add cs-basic to the list of supported authentication mechanisms specified by the [AUTHENTICATION] supported parameter.

The calendar server negotiates with a client as follows.

1. The client starts up and connects to the server.
2. The client queries the server for the supported and default authentication, compression, and encryption methods.
3. The server returns a list of the supported and default authentication, compression and encryption methods.
4. If the client cannot support one of the default methods, the server and client negotiate using the list of supported methods sent to the client in step 3 to agree on a method that both support. Note that one of the supported methods for both compression and encryption is "none", making both compression and encryption optional.
5. The server authenticates the user using the negotiated authentication method.
6. The client and server communicate using the agreed upon methods for the duration of the user session.

   Note: If the client and server cannot agree on authentication, compression and encryption methods, the negotiation fails and the server does not accept requests from the client.

Secure connections to another calendar server

The server negotiates with another calendar server as follows.

1. Server A receives a request from Server B.
2. Server A sends Server B a list of the supported and default authentication, compression, and encryption methods.
3. If Server B cannot support one of the default methods, Server A and Server B negotiate using the lists of supported methods sent in step 2 to agree on a method that both support. Note that one of the supported methods for both compression and encryption is "none", making both compression and encryption optional.
4. Server A authenticates Server B using the negotiated authentication method.
5. Servers A and B communicate using the agreed upon methods for the duration of the connection.

   Recall that communication between two calendar servers is through the uniengd. In this case, the uniengd on Server B asks the unisncd on Server B for a connection to a uniengd on Server A. The methods are in effect until the requesting uniengd on Server B returns the connection to the unisncd.

   Note: If the two servers cannot agree on authentication, compression and encryption methods, the negotiation fails and Server A does not accept requests from Server B.

Configuration

To enable the ACE framework and ensure secure server-to-client or server-to-server connections in a node network, set the [ACE] frameworkenable parameter in the unison.ini file to TRUE.

The following table lists the parameters used to configure the authentication, compression and encryption methods used for communication within a calendar network (server to client, server to server). See "Extending the ACE framework" below for information on extending the sets of supported methods. Consult the appropriate page in the calendar server Reference Manual, Appendix B, "Server Parameters," for details on these parameters.

Table D-1 ACE configuration parameters

Section	Parameter	Description
[ACE]	frameworkenable	Enable the ACE framework
[AUTHENTICATION]	supported	Supported authentication methods for clients
	default	Default authentication method for clients
[COMPRESSION]	supported	Supported compression methods
	default	Default compression method for clients
	servicedefault	Default compression method for other servers
[ENCRYPTION]	supported	Supported encryption methods
	needsauthenticate	Encryption methods requiring prior authentication
	default	Default encryption method for clients
	servicedefault	Default encryption method for other servers

Extending the ACE framework

The ACE framework provides an interface to an extensible set of authentication, compression, and encryption plug-ins. This section describes the use of these plug-ins, and details the mechanism for extending the set of plug-ins available in the server.

Figure D-1 ACE framework architecture

Plug-ins

Each plug-in is a shared library under UNIX, or a DLL under NT. The name of the plug-in contains a substring that indicates the type of the plug-in, as shown in the following table.

Substring	Type of plug-in	Examples
aut_	Authentication	aut_cs-standard.dll (NT) libaut_cs-standard.sl (HP-UX) libaut_cs-standard.so (SunOS)
cmp_	Compression	cmp_cs-simple.dll (NT) libcmp_cs-simple.sl (HP-UX) libcmp_cs-simple.so (SunOS)
enc_	Encryption	enc_cs-acipher1.dll (NT) libenc_cs-acipher1.sl (HP-UX) libenc_cs-acipher1.so (SunOS)

Note: The cs-basic authentication plug-in is not a true plug-in in that it is not a shared library. It pre-dates the ACE framework as the authentication method built into the server. The cs-basic authentication plug-in must be enabled manually if older clients are to be used, including Oracle CorporateSync 2.1.x for Mac.

Extending the set of plug-ins

To extend the set of plug-ins available through the ACE framework, first install the plug-in on your system, and then integrate it into the server. The installation of plug-ins is the responsibility of the system administrator. Consult the appropriate documentation for details. To integrate the plug-in into the calendar server, add the appropriate keywords to one or more places in the unison.ini file.

For all methods except those that support sub-mechanisms, derive the keyword from the name of the plug-in in the following manner. Remove the substring "aut_", "cmp_", or "enc_" and all characters that precede it. Remove the filename extension and the period that precedes it. The remaining string is the keyword to add to the unison.ini file.

Plug-in Name	Keyword
aut_cs-standard.dll	cs-standard
libcmp_cs-simple.sl	cs-simple
libenc_cs-acipher1.so	cs-acipher1

In the case of plug-ins which support sub-mechanisms, the keyword has the format <plug-in_name>:<sub-mechanism_name>. Derive <plug-in_name> as described above. Consult the plug-in documentation to determine <sub-mechanism_name>. For example:

Plug-in Name	Keyword
libaut_sasl.so	sasl:GSSAPI

Note that SASL and GSSAPI are not certified with this release of the Oracle Calendar server.

Once you have determined the keyword, add it to the appropriate list of supported methods in the unison.ini file. Add authentication methods to the [AUTHENTICATION] supported parameter, compression methods to the [COMPRESSION] supported parameter, and encryption methods to the [ENCRYPTION] supported parameter. If you want the new method to be the default, also set the appropriate default and/or servicedefault parameters. For more details on these parameters, please consult the calendar server Reference Manual, Appendix B, "Server Parameters."

Web authentication plug-in

The Web authentication plug-in configures the calendar server to trust Web server authentication methods, allowing users to view their calendars without having to sign in explicitly to the calendar server.

This plug-in is supported by Oracle Web clients version 3.0 or greater and Oracle calendar servers of version 5.2 and 5.3. Future versions of the calendar server will feature enhanced Web authentication capabilities through an updated version of this plug-in. The aut_web module must be configured correctly on both the client side and server side.

Note that the Oracle Collaboration Suite installation procedure configures your calendar Web client and server to use this Web authentication plug-in by default, in order to provide support for Single Sign-On. However, the installation utility generates shared keys (see below for an explanation) automatically in the server and client configuration files. It is the administrator's responsibility to ensure that these shared keys match across all calendar Web clients and server components.

How does the Web authentication plug-in work?

1. The Web authentication plug-in identifies itself to the calendar server when the Web client FastCGI is started. This is done through comparing the values of two parameters, one stored in the calendar Web client configuration file (webcal.ini), and one stored in the calendar server configuration file (unison.ini). If the values of these shared keys are the same, the calendar server will trust the Web authentication plug-in as a proxy authenticator.
2. When a user is authenticated with the Web server and attempts to access a FastCGI application, the server stores some of that user's attributes in environment variables.
3. When that user attempts to view his or her calendar, the Web calendar client application calls the Web authentication plug-in.
4. The Web authentication plug-in then retrieves the user information stored in the Web server environment variables, and uses that information to identify the current user to the calendar server. It passes the value of a specified environment variable to the calendar server, and indicates what user attribute in the calendar database that environment variable represents. Currently, the only attribute supported is the user's UID.
5. The calendar server looks for a user whose UID matches the value submitted. If it finds a match, the user is signed directly in to their Web calendar.

Configuring your calendar server

1. Edit the users/unison/misc/unison.ini file.
2. Ensure that the [ACE] frameworkenable parameter is set to TRUE.
3. Add the Web authentication plug-in, represented by the string web:CAL, to the list of supported authentication methods given in the [AUTHENTICATION] supported parameter. For example:

   [AUTHENTICATION] 
   supported = {cs-standard, web:CAL} 
   
   

4. Create a new section called [ACE_PLUGINS_SERVER] and a new parameter called web_CAL_sharedkey to specify the shared key to be used by the Web authentication plug-in. The value of this parameter should be a simple plain-text password. For example:

   [ACE_PLUGINS_SERVER] 
   web_CAL_sharedkey = mypassword
   

Configuring your Web calendar client

1. Edit the webcal.ini file.
2. Enable the Web authentication plug-in by changing the value of the [ACE] authentication parameter to web:CAL. Set this parameter as follows:

   [ACE] 
   authentication = web:CAL 
   
   

3. Create a new section called [ACE_PLUGINS_CLIENT] and a new parameter called web_CAL_sharedkey to specify the shared key to be used by the Web authentication plug-in. The value of this parameter must match the value you set for the calendar server unison.ini [ACE_PLUGINS_SERVER] web_CAL_sharedkey parameter. For example:

   [ACE_PLUGINS_CLIENT] 
   web_CAL_sharedkey = mypassword 
   
   

4. Add a new parameter, [ACE_PLUGINS_CLIENT] web_attribute_type, to specify the calendar user attribute that will be used to match the value of the Web server environment variable. Currently, this parameter may take either of two values:
   • userid, which forces the calendar server to identify users by comparing the value of the Web server environment variable with calendar server UIDs, or
   • custom, which processes the value of the Web server environment variable through a separate script before comparing it with calendar server UIDs.

   For example:

   web_attribute_type = userid 
   
   

   If you choose to use the custom option for the [ACE_PLUGINS_CLIENT] web_attribute_type parameter, then you must add another parameter, [ACE_PLUGINS_CLIENT] web_custom_script, to specify the script to be used. For example:

   web_custom_script = /usr/local/apache/ctw-bin/lexacal/custom.sh
   
   

   Sample script: This sample shell script (UNIX only) takes e-mail addresses stored in the Web server environment variable SSL_CLIENT_S_DN_Email, strips off the @ character and all characters following, and returns the remaining characters to be matched against users' calendar server UIDs:

   #!/bin/sh
   echo userid
   echo $SSL_CLIENT_S_DN_Email | sed s/\@.*//g
   
   

   To use this script, save it as an executable on your Web server, and supply the path and file name using the web_custom_script parameter. Use this script as a template for designing your own custom scripts. Output must be two lines: the attribute type on the first line and the value on the second.

   Note: If more than one Web client application is running on the same UNIX machine using the custom option, each Web client must run under a different user name.

5. Add a new parameter, [ACE_PLUGINS_CLIENT] web_attribute_name, to specify the Web server environment variable to use for identifying calendar users. For example:

   web_attribute_name = SSL_CLIENT_S_DN_UID 
   
   

   Any environment variable may be used. When the web_attribute_type parameter is set to userid, the value of the environment variable specified by the web_attribute_name parameter must be equivalent to the calendar server UID. When the web_attribute_type parameter is set to custom, the specified script must convert the value of the environment variable specified by the web_attribute_name parameter into a valid calendar server UID.

6. Specify the default page to load if the calendar server is unable to match the authenticated user. Set the [href] login_fail_url parameter to the desired path and file name, enclosed in quotes. For example:

   [href] 
   login_fail_url = "<filename>" 
   
   

   Note: By default, errors and warnings will be logged to a file in the same directory as the Web calendar client application. To specify another directory for the log file, use the [ACE_PLUGINS_CLIENT] web_logfile parameter.

Directory server security

Secure Sockets Layer (SSL) encryption is used by default for all connections to Oracle Internet Directory to protect the data that flows between the calendar server and the directory server, and prevent passwords from being sent across the wire in clear text.

Other security considerations

The following safeguards can be used to enhance the security of calendar data.

Dedicated Server

We recommend that the calendar server, if financial resources permit, be placed on a dedicated computer. Additionally, turn off any TCP and UDP services on the host which are not critical to the calendar server (e.g., ftp, NFS server and client, X server, etc.). There should be only two accounts configured on the system: unison and root (UNIX) or administrator (NT).

Password Management

Note that user passwords may not be set using calendar administration tools or calendar clients. Users and administrators should take advantage of the other directory administration tools provided for password management. For calendar server SYSOP passwords, the following are policy/procedure recommendations:

• Passwords should never be empty (or blank). This is especially important for the SYSOP or node administrator password.
• Passwords should never be words, names, or personal information which would be easy for others to guess.
• Passwords should be at least 8 characters long, and contain a combination of letters and numbers.
• Avoid using the same password to access the calendar server and other mission-critical systems (although this may not be possible if these applications all use the same directory server).

Trust Management

Even if the server is dedicated to the calendaring application, there are still additional security safeguards to consider.

If you have security servers within your organization, consider sending audit trail information from the calendar server to your central security server. Turn on auditing for the server and conduct spot audits of the commands issued by the unison user. The server protects a great deal of aggregate data; ensure that your backups are protected from theft. Consider separate ownership of the root/administrator (auditing account) and the unison (server management) accounts. This would allow root/administrator to detect potential abuses by the unison owner.

Networking

It is more secure to run mission-critical applications within firewall-protected intranets. Make sure that the dial-up connections to your intranet are protected. This can be improved by using one-time password technology (e.g. SecurID). As with many TCP/IP protocols, promiscuous listening (where the attacker monitors network traffic) is a threat in any broadcast network. A number of steps can be performed to reduce the risk of this threat:

• Physically protect hubs and routers. Use switched hubs when possible, especially on the server itself. Some hubs will block unauthorized, or unregistered MAC (or ethernet addresses) on the LAN.
• Consider router filtering between untrusted internal networks.
• Use commercial firewalls to allow more complex TCP/IP filtering rules.

Auditing

The server generates a number of useful audit trails. It is important to become familiar with these audit trails, and to check them regularly. Many commands will create log files on error conditions. Routinely check for the existence of new log files, and review their contents. Monitor the /users/unison/log/act.log for login attempt abuses. You can detect login attempt abuses from the originating IP addresses. After the application is initially installed, record the file dates, file sizes, and checksums of all the binaries (the unicksum utility generates a checksum for a file). Periodically check that none of the binaries have been edited by comparing the current file dates, file sizes, and checksums with those recorded. Review <temp> directories for any suspicious files as they can be used as work areas.

Backup and Recovery

Calendar data is very important and should be backed up regularly. See Chapter 10, "Node Maintenance" for more information.

Application Security

The server supports a very rich set of user-controlled access privileges (or rights). It is important to train end-users on how these capabilities can be managed, so that the users' information is protected from unauthorized access.

Try to limit assigning designate rights. You should only give designate rights to trusted individuals.

The default designate rights should be no designate rights. Set the viewing rights to no privileges, and add privileges as needed.

There are a number of overall limits, set by the server administrator, that can be set for all users.

Disabling attachments ([LIMITS] allowattachments) can prevent users from propagating proprietary information improperly. Setting maximum attachment size ([LIMITS] maxattachmentsize) can help prevent denial of service errors caused by very large files that cause a server to run out of disk space.

Calendar Administrator

It is recommended that you always use Secure Sockets Layer (SSL) encryption to access the Calendar Administrator, in order to protect sensitive information. Always use the https:// URL prefix instead of http:// to ensure secure access.