Skip Headers

Oracle® Calendar Administrator's Guide
Release 2 (9.0.4)

Part Number B10892-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

C
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

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 to communication between Calendar Servers, as well as between Calendar Server(s) and clients. See "Directory Server Security" later in this chapter 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 later in this chapter.

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 $ORACLE_HOME/ocal/misc/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" later in this chapter for information on extending the sets of supported methods. Consult Appendix C, "Server Parameters" of the Oracle Calendar Reference Manual, for details on these parameters.

Table C-1 ACE configuration parameters
Section Parameter Description

[ACE]

frameworkenable

Enable the ACE framework

 

minbufsizetocompress

Minimum buffer size for compression

 

slibcachecount

Maximum number of shared libraries per type

 

workbufsize

Buffer size for compression and encryption

[ACE_PLUGINS]

sasl_KERBEROS_V4_useridneeded or sasl_GSSAPI_useridneeded

SASL -- userID needed

 

sasl_KERBEROS_V4_mac_realm

SASL -- Kerberos realm for Mac clients

 

sasl_KERBEROS_V4_srvtab

SASL -- Path to Kerberos "srvtab" file

[ACE_PLUGINS_CLIENT]

web_attribute_name

Web authentication - user attribute name

 

web_attribute_type

Web authentication - user attribute type

 

web_attribute_valuemax

Web authentication - maximum size of user attribute name

 

web_cacheexpiresec

Web authentication time-out

 

web_cachesize

Web authentication - cache size

 

web_CAL_sharedkey

Web authentication - Web:CAL shared key

 

web_custom_script

Web authentication - custom user-ID to attribute mapping script

 

web_tmppath

Web authentication - path for custom script temporary files

[ACE_PLUGINS_SERVER]

web_CAL_sharedkey

Web authentication -- shared key

[AUTHENTICATION]

admindefault

Default authentication method for administrators

 

default

Default authentication method for clients

 

keepresourcepwdincaldb

Location of resource passwords for authentication

 

servicedefault

Default authentication method for other servers

 

supported

Supported authentication methods for clients

[COMPRESSION]

admindefault

Default compression method for administrators

 

default

Default compression method for clients

 

servicedefault

Default compression method for other servers

[ENCRYPTION]

admindefault

Default encryption method for administrators

 

default

Default encryption method for clients

 

needsauthenticate

Encryption methods requiring prior authentication

 

servicedefault

Default encryption method for other servers

 

supported

Supported encryption methods

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 C-1 ACE framework architecture

Text description of aceframe.gif follows.

Text description of the illustration aceframe.gif

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 earlier in this chapter. Consult the plug-in documentation to determine <sub-mechanism_name>. For example:

Plug-in Name Keyword

libaut_sasl.so

sasl:GSSAPI

Note that sasl:GSSAPI is 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, consult Appendix C, "Calendar Server Parameters" of the Oracle Calendar Reference Manual.

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 Calendar 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.

Configuring Your Calendar Server

  1. Edit the $ORACLE_HOME/ocal/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:OTMT, to the list of supported authentication methods given in the [AUTHENTICATION] supported parameter. For example:
    [AUTHENTICATION] 
    supported = {cs-standard, web:OTMT} 
    

Configuring Your Calendar Web Client

When you configure your calendar Web client, you will need to specify the calendar user attribute that will be used to match the value of the Web server environment variable. Currently, this parameter may be one of two values:

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.





To configure your calendar client:


  1. Open $ORACLE_HOME/ocas/conf/ocwc.conf file for editing.
  2. Enable the Web authentication plug-in by changing the value of the [ACE] Authentication parameter to web:OTMT. Set this parameter as follows:
    [ACE] 
    Authentication = web:OTMT 
    
    
  3. Modify the 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 varilable.
  4. Modify the 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 = REMOTE_USER
    
    



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. 





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.).




Password Management




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: 





The calendar server 9.0.4 supports passwords of up to 63 characters. Users who set their passwords to more than 15 characters may not be able to sign-in using calendar clients older than 9.0.4 which only support password lengths of 15 characters.




Other configuration parameters to consider are ssignin and ssigninrestrictions in the [LIMITS]  section which control whether a user can use the desktop clients' automatic sign-in feature. Parameter invalidlogin_enable in the [ENG] section can be used to enable the invalid sign-in counting mechanism. The [ENG] allowpasswordchange_user parameter can be used to stop users from changing their password. For more details on these parameters, consult Appendix C, "Calendar Server Parameters" of the Oracle Calendar Reference Manual.




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 calendar 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 calendar (server management) accounts. This would allow root/administrator to detect potential abuses by the calendar 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: 




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 $ORACLE_HOME/ocal/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 15, "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. For more details on these parameters and others, consult Appendix C, "Calendar Server Parameters" of the Oracle Calendar Reference Manual.




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. 




Oracle Web Conferencing Server




The Oracle HTTP server (OHS) allows clients and servers to authenticate over SSL using X.509v3 certificates. The certificates are stored in an Oracle Wallet, a container in which certificates and trusted certificates are stored and managed. 




When communicating with the Web Conferencing server, the calendar server uses a secure HTTP connection (HTTPS) to OHS. To establish an HTTPS connection, a wallet is used with a default certificate which ensures that the information passed between the two servers is encrypted. The location of the wallet is defined by the [CONFERENCING] walletfile parameter  in the unison.ini configuration file. The password of the wallet is defined by the [CONFERENCING] walletpassword parameter.  




It is possible to replace the default certificates in the wallet with ones from another certificate authority. For more information on how to do this, consult the Oracle9i Application Server Security Guide.




The parameter [CONFERENCING] url defines the URL used by the calendar server to access the Web Conferencing server. By default Secure Sockets Layer (SSL) encryption is used and therefore the "https://" URL prefix is used rather than the "http://" to ensure secure access. The password and ID used to authenticate to the Web Conferencing server are defined by the parameters [CONFERENCING] siteid and siteauthkey.




For more information on the Web Conferencing parameters, consult Appendix C, "Calendar Server Parameters" of the Oracle Calendar Reference Manual.