| Oracle® Calendar Administrator's Guide Release 2 (9.0.4) Part Number B10892-02 |
|
|
View PDF |
| Oracle® Calendar Administrator's Guide Release 2 (9.0.4) Part Number B10892-02 |
|
|
View PDF |
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.
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 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.
The calendar server negotiates with a client as follows.
The server negotiates with another calendar server as follows.
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.
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.
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.
Text description of the illustration aceframe.gif
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 |
|---|---|---|
|
|
Authentication |
libaut_cs-standard.so (SunOS) |
|
|
Compression |
libcmp_cs-simple.so (SunOS) |
|
|
Encryption |
libenc_cs-acipher1.so (SunOS) |
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 |
|---|---|
|
|
|
|
|
|
|
libenc_cs-acipher1.so |
|
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 |
|---|---|
|
|
|
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.
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.
$ORACLE_HOME/ocal/misc/unison.ini file.[ACE] frameworkenable parameter is set to TRUE.web:OTMT, to the list of supported authentication methods given in the [AUTHENTICATION] supported parameter. For example:
[AUTHENTICATION] supported = {cs-standard, web:OTMT}
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:
userid (default value) which forces the calendar server to identify users by comparing the value of the Web server environment variable with calendar server UIDs (default value); 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. |
To configure your calendar client:
$ORACLE_HOME/ocas/conf/ocwc.conf file for editing.[ACE] Authentication parameter to web:OTMT. Set this parameter as follows:
[ACE] Authentication = web:OTMT
[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.[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.
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.
The following safeguards can be used to enhance the security of calendar data.
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.).
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.
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.
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:
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.
Calendar data is very important and should be backed up regularly. See Chapter 15, "Node Maintenance" for more information.
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.
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.
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.
