| Oracle® Collaboration Suite Security Guide 10g Release 1 (10.1.1) Part Number B14489-02 |
|
|
View PDF |
| Oracle® Collaboration Suite Security Guide 10g Release 1 (10.1.1) Part Number B14489-02 |
|
|
View PDF |
This chapter discusses security in Oracle Collaboration Suite Applications. It contains the following topics:
Oracle Collaboration Suite enables administrators to delegate administration responsibilities to other users. For example, the administrator may choose to assign responsibilities to users, as follows:
Oracle Calendar
SYSOP: Start, stop, and manage the Oracle Calendar server
Users: Manage groups and holidays on a calendar node
See Also:
Oracle Calendar Administrator's Guide and Oracle Calendar Reference Manual for more informationOracle Content Services
Application Administrator: Manage users, quota, libraries, categories, content, and records at the Site and Container level
System Administrator: Manage the Oracle Content Services domain by starting and stopping nodes, services, and servers, tuning the system to ensure reliability and performance, creating, modifying, and deleting sites, as well as registering custom workflows
See Also:
Oracle Content Services Application Administrator's Guide for more informationOracle Mail
System Administrator: Change process settings and start and stop servers
Domain Administrator: Maintain users and user quota within a specific domain
See Also:
Oracle Mail Administrator's Guide for more informationOracle Real-Time Collaboration
Business Monitor: Monitor or analyze the administrative details of a conference, for example, conference start or end times, attendee join or exit time etc. It also gives you access to a variety of reports, such as Usage, Feedback, Quality of Service and Security.
Business Administrator: Start up or shut down Oracle Real-Time Collaboration processes, access log files, configure a new or existing Oracle Real-Time Collaboration host, and manage sites
Note:
Each of these roles could be granted Oracle Real-Time Collaboration system wide or for a specific site.See Also:
"Oracle Real-Time Collaboration Administration Features" in Chapter 1 of Oracle Real-Time Collaboration Administrator's Guide for more informationUsing Oracle Collaboration Suite, you can access your content, such as files, e-mail messages, Web conference, and appointments, through a variety of clients, including browsers, native clients, and wireless devices. Oracle Collaboration Suite uses Oracle Application Server to deliver content to Web and mobile devices. Oracle Application Server uses Secure Sockets Layer (SSL) to secure network traffic between the Web server and the client. SSL, in turn, uses Public Key Infrastructure (PKI) certificates to enable, both network encryption between the client and the server and server authentication. In server authentication, a certificate is provided for a specific server by a Certificate Authority (CA) that the browser trusts.
SSL can be preconfigured for Oracle Collaboration Suite but with a self-signed certificate. When a browser accesses Oracle Collaboration Suite that is using the self-signed certificate, the browser displays a message that the certificate is not trusted. It is important that you obtain a real certificate from a well-known CA such as Verisign.
You need only one certificate for all the Applications tier servers because of the virtual server capabilities of Oracle Application Server. This certificate enables you to secure all Web applications, such as Oracle Calendar, Oracle Mail, Oracle Content Services, and OracleAS Portal.
Using a Wireless Access Protocol (WAP) device to access Oracle Collaboration Suite is a special scenario. A WAP device implements a standard known as Wireless Transport Layer Security (WTLS). A WTLS-compliant WAP gateway must be used to provide the conversion between WTLS and SSL. When this conversion takes place, there is a small period of time for which the content you are reading will exist in the unencrypted format in the memory of the WAP gateway at your service provider. If this is a major concern, then you can implement your own WAP gateway and dial-up infrastructure. The majority of PDA browsers now implement SSL.
This section contains the following topics:
Oracle Internet Directory can manage the public keys of users. An advantage of using PKI is the ability to implement client authentication. You authenticate yourself to servers through user names and passwords.
In the case of PKI, clients can use certificates for authentication. Most browsers have wallets to store client SSL certificates. By enabling certificate-based authentication with the OracleAS Single Sign-On server, you will not have to type or remember user names and passwords but will be authenticated to the server and other Web applications using local certificates.
To perform administration tasks for all Applications tier components by using the Application Server Control for Oracle Collaboration Suite or the Grid Control, administrators use an HTML form. Unless Oracle HTTP Server and Oracle Enterprise Manager are configured for SSL, unencrypted passwords are transmitted over the network.
By default, Java Database Connectivity (JDBC) does not encrypt network connections between Applications tier components and Oracle Database. Sites can opt to use Oracle Advanced Security to encrypt these connections.
You can choose whether or not to use SSL to connect to Oracle Internet Directory. If you do not choose to use SSL, then unencrypted passwords may be sent over network connections between Applications tier processes and Oracle Internet Directory.
See Also:
Oracle Internet Directory Administrator's Guide for information about configuring SSL for use with Oracle Internet DirectorySecurity 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 an Oracle Calendar server installation. In addition to increasing the security of the operating environment and implementing good maintenance and monitoring practices, Oracle Calendar server administrators have access to a configurable, extensible Authentication, Compression, and Encryption (ACE) framework.
This section 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. This section contains the following topics:
The ACE framework was developed by Oracle to allow administrators to ensure the security and integrity of all data passing between Oracle 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 Oracle Calendar server and the directory server. The ACE framework applies to communication between the Oracle Calendar servers, as well as between the Oracle Calendar servers and clients. Refer to Directory Server Security for a separate discussion of the security options for passing data between the Oracle 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. This section contains the following topics:
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. Refer to Available Plug-Ins and Configuration for the relevant configuration parameters, and Extending the ACE Framework for details on extending the available set of methods.
Note:
Only Oracle Calendar desktop clients 5.0 and higher, Oracle CorporateSync 3.0 and higher, Oracle Calendar Web clients 3.1 and higher, and Oracle Connector for Outlook 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 Oracle Calendar server negotiates with a client as follows:
The client starts up and connects to the server.
The client queries the server for the supported and default authentication, compression, and encryption methods.
The server returns a list of the supported and default authentication, compression, and encryption methods.
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 can be none, making both compression and encryption optional.
The server authenticates the user using the negotiated authentication method.
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.The server negotiates with another calendar server as follows:
Server A receives a request from Server B.
Server A sends Server B a list of the supported and default authentication, compression, and encryption methods.
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 can be none, making both compression and encryption optional.
Server A authenticates Server B using the negotiated authentication method.
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.Oracle Calendar provides support for a number of different authentication, compression and encryption methods. This section discusses the plug-ins that are included in a typical Calendar installation. Moreover, they do not require any additional encryption software on the desktop client workstation.
The methods packaged with the Oracle Calendar server are:
Authentication
Standard Authentication (cs-standard)
A secure authentication method where the user's password is encrypted with a secure encryption method using 3DES, and has a unique session key. The transmission between the client and the server is verified for integrity with a cyclic redundancy check to prevent a replay attack.
SyncML MD5 1.01 Authentication (challenge:SYNCMLMD5_V101)
This authentication plug-in is used by SyncML version 1.01 devices when performing challenge-response based authentication.
SyncML MD5 1.1 Authentication (challenge:SYNCMLMD5_V110)
This authentication plug-in is used by SyncML version 1.1 devices when performing challenge-response based authentication.
Compression
Run Length Encoding Compression (cs-simple)
This plug-in will compress all data transferred between the Oracle Calendar client and server using a run length encoding compression algorithm.
Encryption
Affine Cipher (cs-acipher1)
This plug-in will encrypt all data transferred between the client and server using an affine cipher algorithm.
Light Encryption (cs-light)
This plug-in will encrypt all data transferred between the client and server using a light and fast encryption algorithm.
Oracle AES (oracle:AES)
For information about AES Encryption, refer to Advanced Encryption Standard.
Oracle DES (oracle:DES)
For information about DES Encryption, refer to DES Encryption.
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.
Table 2-1 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). Refer to Extending the ACE Framework for information on extending the sets of supported methods. Refer to Chapter 3 of the Oracle Calendar Reference Manual, for details of these parameters.
Table 2-1 ACE Configuration Parameters
This section describes the use of the ACE plug-ins, and details the mechanism for extending the set of plug-ins available in the server.
To extend the set of plug-ins available through the ACE framework, first, if the plug-in is not already installed, install the plug-in on your system, and then integrate it into the server. The installation of third-party plug-ins is the responsibility of the system administrator. Refer to the appropriate documentation for details. To integrate the plug-in into the Oracle Calendar server, you will need to 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.
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 section.
See Also:
Table 2-2 for more information on submechanism names and a full list of supported plug-in names and librariesPlug-In Libraries
Each plug-in is a shared library under UNIX, or a DLL under Windows. The name of the plug-in contains a substring that indicates the type of the plug-in. The following table lists shared library and DLL names for all supported methods of authentication, compression and encryption:
Table 2-2 ACE Configuration Plug-Ins
| Substring | Plug-In name | Shared Library or DLL name |
|---|---|---|
aut_ |
Authentication:
|
libaut_cs-standard.so (Linux/Solaris)
|
aut_ |
Authentication: challenge:SYNCMLMD5_V101
|
libaut_challenge.so (Linux/Solaris)
|
aut_ |
Authentication: gssapi:kerberos5 |
libaut_gssapi.so (Linux/Solaris)
|
aut_ |
Authentication: web:CAL
|
libaut_web.so (Linux/Solaris)
|
cmp_ |
Compression:
|
libcmp_cs-simple.so (Linux/Solaris)
|
enc_ |
Encryption:
|
libenc_cs-acipher1.so (Linux/Solaris)
|
enc_ |
Encryption:
|
libenc_cs-light.so (Linux/Solaris)
|
enc_ |
Encryption:
|
libenc_oracle.so (Linux/Solaris)
|
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.Once you have determined the keyword, you must 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 in the appropriate [AUTHENTICATION], [COMPRESSION] or [ENCRYPTION] section of the $ORACLE_HOME/ocal/misc/unison.ini file. For more details on these parameters, refer to Chapter 3 of the Oracle Calendar Reference Manual.
ACE Configuration Example
Howard administers his organization's installation of Oracle Collaboration Suite. Having done some research, he realizes that some changes must be made to the Oracle Calendar server in order to comply with his organization's security policy.
The only acceptable methods of authentication are either Standard Authentication (cs-standard) or SyncML MD5 1.1 Authentication (challenge:SYNCMLMD5_V110), and moreover, the default should be the former. In order to enforce this policy, Howard edits the [AUTHENTICATION] section of the Oracle Calendar server's $ORACLE_HOME/ocal/misc/unison.ini file with the following parameter modifications:
[AUTHENTICATION]supported = {cs-standard, challenge:SYNCMLMD5_V110}default = cs-standard
In terms of compression, Howard chooses to allow users to decide whether or not they wish to compress the data sent between the Oracle Calendar server and Oracle Calendar clients using cs-simple. As a default, compression is not required. In order to enforce this policy, Howard edits the [COMPRESSION] section of the Oracle Calendar server's $ORACLE_HOME/ocal/misc/unison.ini file with the following parameter modifications:
[COMPRESSION]
supported = {cs-simple, none}
default = none
Lastly, Howard would like all data to be encrypted using the cs-acipher1 plug-in. In order to enforce this policy, Howard edits the [ENCRYPTION] section of the Oracle Calendar server's $ORACLE_HOME/ocal/misc/unison.ini file with the following parameter modifications:
[ENCRYPTION]
supported = {cs-acipher1}
default = cs-acipher1
Setting Different ACE Configuration Settings for Each OCAS Plug-In
Each Oracle Calendar Application System (OCAS) plug-in (Web, Web services, and Sync) has a specific configuration file. Each plug-in configuration file can be used to set different ACE configurations. The following example demonstrates how to set different ACE configuration settings for each OCAS plug-in.
Consider the following scenario:
Oracle Calendar Web client needs to use the web:CAL authentication scheme.
Oracle Calendar Web services needs to use the cs_standard authentication scheme.
Oracle Mobile Data Sync needs to use the enc_cs-light encryption scheme.
The configuration settings are as follows:
Modify the following parameters in the OCAS configuration file (ocas.conf):
[ACE_PLUGINS_CLIENT] web_attribute_type=userid web_attribute_name=REMOTE_USER web_CAL_sharedkey=123456789 aut_web_loglevel = 3 [ACE] Authentication=default Compression=default Encryption=default
Modify the following parameters in the Oracle Calendar Web client configuration file (ocwc.conf):
[ACE] Authentication=web:CAL Compression=default Encryption=default s
Modify the following parameters in the Oracle Calendar Web services configuration file (ocws.conf):
[ACE] Authentication= cs_simple Compression=default Encryption=default
Modify the following parameters in the Oracle Mobile Data Sync configuration file (ocst.conf):
[ACE] Authentication=default Compression=default Encryption=enc_cs-light
The standalone Oracle Calendar Web client comes with its own login page that allows calendar users to provide their user information and password to access the Oracle Calendar server. For most deployments, this infrastructure is sufficient. However, some customer deployments need to integrate the Oracle Calendar Web client into a solution that includes many other services. When a number of heterogeneous systems are grouped into one solution, it is usually a good practice to offload the security and authentication of users to a service that will harmonize and abstract the various underlying security schemes.
This section describes how to integrate the Oracle Calendar Web client with a third-party authentication framework. It contains the following topics:
Note:
The example in this section demonstrates how to configure Apache to secure the Oracle Calendar Web client directory using the Apache distributed configuration files architecture (.htaccess files). You can follow the same procedure for any third-party authentication framework.The following requirements must be met to configure the Oracle Calendar Web client to integrate with a third-party authentication framework:
Oracle Calendar Web client 9.0.4.X and above
Apache 1.3.X and above
Oracle Calendar server 9.0.4.X and above
Administrator access to the Apache, Oracle Calendar Web client and Oracle Calendar server directories and applications
Caution:
Oracle recommends that both the Oracle Calendar Web client and the Oracle Calendar server be deployed and tested using the Oracle Calendar Web client login page. After you verify that all systems work as expected, you can change the configuration settings.To configure the Oracle Calendar server:
Edit the $ORACLE_HOME/ocal/misc/unison.ini file.
The list of supported authentication methods is specified in the [AUTHENTICATION] supported parameter. To add the Web authentication plug-in, represented by the string web:CAL for standalone Calendar server deployments, and by web:OTMT for Oracle Collaboration Suite deployments, include the appropriate string within the list of supported methods, as follows:
[AUTHENTICATION]
supported = {cs-standard, web:OTMT, challenge:SYNCMLMD5_V101, challenge:SYNCMLMD5_V110, web:CAL}
default = cs-standard
servicedefault = cs-standard
Add and configure the following parameters in the [ACE_PLUGINS_SERVER] section:
[ACE_PLUGINS_SERVER] cs-standard_coexistence = TRUE web_CAL_sharedkey=123456789
Note:
Theweb_CAL_sharedkey parameter is a string composed of ASCII characters.Save the unison.ini file.
Restart Oracle Calendar server.
See Also:
"Configuration Parameters" in Chapter 3 of Oracle Calendar Reference Manual for information about the Oracle Calendar server configurable parameters in theunison.ini fileTo configure the Oracle Calendar Web client:
Open the $ORACLE_HOME/ocas/conf/ocwc.conf file for editing.
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
Note:
web:CAL authentication can only be specified in Oracle Calendar standalone deployments. If you are using Oracle Calendar with an Oracle Collaboration Suite deployment, set the Authentication parameter to web:OTMT.Open the $ORACLE_HOME/ocas/conf/ocas.conf file for editing.
Modify the [ACE_PLUGINS_CLIENT] section, as follows:
#----------------------------------------------------------- # This section is used to provide ACE configuration settings # required by the ACE plugins. #----------------------------------------------------------- [ACE_PLUGINS_CLIENT] web_attribute_type=userid web_attribute_name=REMOTE_USER web_CAL_sharedkey=123456789 aut_web_loglevel = 3
Note:
You need to ensure that the value of theweb_CAL_sharedkey parameter matches that specified in the unison.ini file.See Also:
"OCAS.CONF" and "OCWC.CONF" in Chapter 4 of Oracle Calendar Reference Manual for information about theocas.conf and ocwc.conf configuration parameters, respectivelyTo configure the Apache distributed configuration files architecture, perform the following steps:
Modify the following lines in the $ORACLE_HOME/ocas/conf/ocal.conf file:
<Directory "%ORACLE_HOME%/ocas/bin/">
SetHandler fastcgi-script
AllowOverride All
Options None
Order allow,deny
Allow from all
<IfModule mod_ossl.c>
SSLOptions +StdEnvVars
</IfModule>
Set up your users and the login password they will need to use when accessing the protected directory, as follows:
Change to the Apache/bin directory.
Type the following command to encode the user ID and password:
./htpasswd -c $ANY_DIRECTORY/htpasswd $ANY_USERID
Where
$ANY_DIRECTORY is a directory where the htpasswd file will be written to and $ANY_USERID is the user ID an Oracle Calendar user would use to log in to the Oracle Calendar Web client using the login page.
Note:
The$ANY_USERID must be the same as the Calendar user ID for this example to work.You will be prompted to enter a password for $ANY_USERID. Type any password. This password does not need to be your calendar password.
Create a file called .htaccess in the $ORACLE_HOME/ocas/bin directory with the following content:
AuthUserFile "$ANY_DIRECTORY/htpasswd" AuthName "My Company custom login" AuthType Basic require valid-user
Note:
Make sure that theAuthUserFile parameter points to the location where you created your htpasswd file.Restart Apache and the Oracle Calendar Web client.
When you type the following URL, you should be prompted for a user ID and password:
http://myhost/ocas-bin/ocas.fcgi?sub=web
If the login is successful, you will automatically be redirected to the Oracle Calendar Web client without having to go through the Calendar Web client login page.
Figure 2-2 illustrates the components involved while integrating the Oracle Calendar Web client with a third-party authentication framework.
The working of the components is described, as follows:
Initially, Apache sets the REMOTE_USER environment variable in the FastCgi request environment.
The Oracle Calendar Web client uses the configuration file and identifies the REMOTE_USER environment variable (web_attribute_name=REMOTE_USER).
The Oracle Calendar Web client retrieves the REMOTE_USER environment variable and passes it to the Oracle Calendar server through the secure link.
In addition to the REMOTE_USER variable, the Oracle Calendar Web client also informs the Oracle Calendar server about the nature of the value that is sent to it (web_attribute_type=userid).
The Oracle Calendar server verifies the password (web_CAL_sharedkey=123456789) provided by the Oracle Calendar Web client. After the Oracle Calendar server verifies the credentials, the user is allowed to log in.
Using the Custom Solution
To avoid using the Oracle Calendar Web client login page and provide your custom secure solution, you must keep in mind the following:
The Oracle Calendar Web client will always look for an environment variable to get the user credentials. Your secure solution must set that environment variable.
You can always change the name of the value to be retrieved from the environment variables. For example, web_attribute_name=SOME_CUSTOM_ENV.
You can also instruct the Oracle Calendar Web client to run a shell script that performs some operation to set the environment variable, as follows:
[ACE_PLUGINS_CLIENT] web_attribute_type=custom web_attribute_name=REMOTE_USER web_CAL_sharedkey=123456789 aut_web_loglevel = 3 web_custom_script=/home/custom/script.sh
Where script.sh could perform some operation to set the REMOTE_USER variable. The script can be useful if the user credential used to authenticate against your custom solution is not exactly the same as the one used to log in to the Oracle Calendar server. The script can be used to control the environment variable value to fit what the Oracle Calendar server would expect.
In the case of errors, check the following:
Double-check the ocas_log file for errors.
Refer to the auth_web.log file in the $ORACLE_HOME/ocas/bin directory for information about what could be wrong with the web:CAL authentication.
Refer to the Oracle Calendar server log files or Apache log files for more information.
Within the ACE framework, Oracle offers the option of configuring the Oracle Calendar server to use Kerberos 5 as an authentication method. This section contains the following topics:
Kerberos was developed by MIT as a means of performing secure authentications across an insecure network. In this type of environment, a Kerberos server is used as a central authority for authentications. A user gets a ticket from the Kerberos server that represents their identity, and then uses this ticket to request access from services that also authenticate using Kerberos. When the service verifies that the ticket is valid, the user is granted access to the service.
The Oracle Calendar server uses the aut_gssapi ACE plug-in to interface with Kerberos. This interface then allows users to log into the Oracle Calendar server with a valid Kerberos ticket. Because the user's user ID is taken from the Kerberos ticket, there is no need, on the client side, to provide a user name or password.
There are two parts to configuring an Oracle Calendar server to use Kerboros 5:
This section explains the steps that must be carried out on the Kerberos 5 server in order to use Oracle Calendar as a service. Although descriptions of the requirements are provided herein, the detailed technical steps are not. For detailed information relating to Kerboros 5 configuration, refer to MIT's Kerberos V5 System Administrator's Guide at the following URL:
http://web.mit.edu/kerberos/www/krb5-1.4/krb5-1.4.1/doc/krb5-admin/index.html
The Kerberos server must be configured to recognize the Oracle Calendar server as a Kerberos-enabled service. This can be achieved in four steps:
Define a principal name:
In order to be recognized by the Kerberos server, the Oracle Calendar server service must have a principal name defined. The principal name can be any string of characters that you wish to use to identify the service. Although the principal name can be any value, Oracle recommends using uniengd, as it is the default value that the Oracle Calendar server assumes when the service principal is not specified.
Note:
If multiple instances of Oracle Calendar server exist on the same host, it is recommended to give each instance its own distinct principal name.Define a principal instance:
The principal instance must be defined using the fully qualified domain name of the machine hosting Oracle Calendar server.
Export the service principal's credentials:
Export the service principal's credentials into a keytab file that the Oracle Calendar server will be able to read. The keytab file must be readable by the owner of the Calendar uniengd process, and for best security should not be readable by any other users.
Specify the location of the service principal's exported keytab file:
Specify the full path of the persistent encrypted ticket (defined by the default_keytab_name parameter) in the Kerberos 5 workstation's krb5.conf file.
Once the Kerberos 5 setup is complete, the Oracle Calendar server must be configured to allow the use of Kerberos 5 as an authentication method. This is accomplished in five parts, with various steps outlined below:
Associate the plug-in with the principal name:
Open the $ORACLE_HOME/ocal/misc/unison.ini configuration file.
On the last line of the file, add the following section, if it does not already exist, otherwise proceed to the next step:
[ACE_PLUGINS]
Directly under [ACE_PLUGINS] section, add the following line:
gssapi_serviceprincipal=<kerberos principal name>
Where <kerberos principal name> represents the principle name defined in Step 1 in Preparing for Kerberos 5 Authentication.
Note:
If
uniengd was used as the Kerberos principal name on the Kerberos server, then this parameter does not need to be added. If the parameter is not specified, the Oracle Calendar server assumes that it is the default: uniengd.Save the file.
Add Kerberos as a supported authentication mechanism:
Open the $ORACLE_HOME/ocal/misc/unison.ini configuration file.
Within the [AUTHENTICATION] section of the file, add the following string to the supported parameter list:
gssapi:kerberos5
Note:
If you wish to define Kerberos 5 as the default authentication method, the[AUTHENTICATION] default parameter must also be set to gssapi:kerberos5 .Save the file
Set your environment variables:
OCAL_ADDITIONAL_LIBPATH should include the path to the Kerberos 5 libraries.
Note:
For Oracle Calendar server deployments on Microsoft Windows, the host computer must be restarted so that this environment variable takes effect.KRB5_CONFIG is the location of the krb5.conf file, including the file name. This environment variable does not need to be set if the krb5.conf has been installed in the default location: /etc/krb5.conf.
Note:
These environment variables must always be set prior to starting the Oracle Calendar server.If Calendar has been deployed with Oracle Collaboration Suite, a modification must be made to the opmn.xml file in order to apply these configuration changes. If your Calendar server is a standalone deployment, skip this step, and go to Step 5.
Open the $ORACLE_HOME/opmn/conf/opmn.xml file.
Locate the <ias-component id="CalendarServer"> section of the file.
Within the <environment> sub-section of the <ias-component id="CalendarServer"> section add the following variable ID:
<variable id="KRB5_CONFIG" value="<pathtoKRB5.conf>"/>
Where <pathtoKRB5.conf> is the location of the krb5.conf file, including the file name. For example, if your krb5.conf file is located in the /etc directory, the <environment> subsection should have the following entry:
<variable id="KRB5_CONFIG" value="/etc/krb5.conf"/>
Note:
krb5.conf is the Kerberos configuration file on Unix operating systems. On Microsoft Windows, the Kerberos configuration file is krb5.ini.Save the opmn.xml file.
Force a reload of the opmn.xml file by running the following command from the $ORACLE_HOME/opmn/bin directory:
% opmnctl reload
Register the changes to Distributed Configuration Management using the following command:
dcmctl updateconfig -ct opmn
Restart the Oracle Calendar server. For information on restarting the Oracle Calendar server, refer to Chapter 4 of the Oracle Calendar Administrator's Guide.
When implementing Kerberos with supported third-party directory servers, some additional configuration steps are required. These steps are not required when Calendar is deployed with Oracle Collaboration Suite, or in standalone installations with an internal directory.
Open the $ORACLE_HOME/ocal/misc/unison.ini configuration file.
Add the following parameter to the [DAS] section of the unison.ini file:
dir_usewritednforadmin=TRUE
Add the following parameters with the appropriate values to the [LDAP] section of the unison.ini file:
writedn=<writedn> writednpassword=<encryptedwritednpassword>
See Also:
Chapter 3 of the Oracle Calendar Reference Manual for more information about thewritedn and writednpassword parametersSave the file
The Oracle Mobile Data Sync server offers direct two-way synchronization with the Oracle Calendar server over any standard Hypertext Transfer Protocol (HTTP) connection, opening up the calendar infrastructure to any SyncML-compliant device or application with Internet access. If secure synchronization of data is a high priority for your organization, then use devices that support SSL synchronization. The list of devices on the Oracle Technology Network site (http://www.oracle.com/technology/index.html) specifies which devices support SSL synchronization. Oracle Mobile Data Sync supports SSL connections that are properly configured on the appropriate port during Oracle Collaboration Suite installation and configuration. The combination of using SSL with SyncML basic authentication should be sufficient for most deployments. However, for added security, the Oracle Mobile Data Sync server can be configured to support SyncML MD5 authentication. Note that not all SyncML-compliant mobile devices properly support MD5.
The following section identifies the post-installation steps required to enable MD5 authentication. It contains the following topics:
Enabling the Dynamic Verifier in Oracle Internet Directory for Passwords
Enabling the Dynamic Verifier in Oracle Internet Directory for PINs
Ensuring that the Dynamic Verifier Is Enabled Correctly for Passwords
Ensuring that the Dynamic Verifier Is Enabled Correctly for PINs
Note:
The instructions provided explain how to enable MD5 authentication for both the single sign-on password and the Wireless PIN. The Oracle Mobile Data Sync server and the Oracle Calendar server can be configured to allow authentication with either the single sign-on password or the Wireless PIN, regardless of whether or not MD5 is being used. In 10g Release 1 (10.1.1), the Wireless PIN is the default. If applications are configured for PIN, then only the steps given for PINs need be performed and vice-versa for passwords.To enable the dynamic verifier in Oracle Internet Directory for passwords, perform the following steps:
Create a file containing the following information:
dn:cn=PwdPolicyEntry,cn=Common,cn=Products,cn=OracleContext,<basedn> changetype: modify replace: orclpwdencryptionenable orclpwdencryptionenable: 1
Where
<basedn> is the value provided during install. For example, during test installs, the value is "dc=ca,dc=oracle,dc=com".
Run the following command where the port is usually 389:
more filename.ldif | ldapmodify -h <OID host> -p <OID port> -D cn=orcladmin -w <password>
Where
filename.ldif is the file that was created in Step 1.
To enable the dynamic verifier in Oracle Internet Directory for PINs, perform the following steps:
Create a file containing the following information:
dn:cn=DefaultSharedPinProfileEntry,cn=Common,cn=Products,cn=OracleContext changetype: modify add:orclpwdverifierparams;orclpasswordverifier orclpwdverifierparams;orclpasswordverifier: crypto:3DES
Run the following command where the port is usually 389:
more filename.ldif | ldapmodify -h <OID host> -p <OID port> -D cn=orcladmin -w <password>
Where
filename.ldif is the file that was created in Step 1.
To ensure that the dynamic verifier has been enabled correctly for passwords, perform the following steps:
Run the following command to check for the password dynamic verifier:
ldapsearch -h <OID host> -p <OID port> -D cn=orcladmin -w <password> -b "cn=PwdPolicyEntry,cn=Common,cn=Products,cn=OracleContext,<basedn>" -s base "objectclass=*"
Search for the orclpwdencryptionenable attribute and ensure that it is set to 1.
To ensure that the dynamic verifier has been enabled correctly for PINs, perform the following steps:
Run the following command to check for the PIN dynamic verifier:
ldapsearch -h <OID host> -p <OID port> -D cn=orcladmin -w <password> -b "cn=DefaultSharedPinProfileEntry,cn=Common,cn=Products,cn=OracleContext" -s base "objectclass=*"
Search for the orclpwdverifierparams;orclpasswordverifier attribute and ensure that 3DES is listed.
You must reset your single sign-on password from the main preference page and the Wireless PIN from the Mobile Preferences page after the dynamic verifier has been enabled. Failure to do so will result in authentication errors.
Note:
You need not change the single sign-on password and Wireless PIN while resetting them.To enable MD5 on the Oracle Calendar server, perform the following steps:
In the $ORACLE_HOME/ocal/misc/unison.ini file, add the following line under the [ENG] section:
syncml_allowmd5auth = TRUE
By default, the Oracle Mobile Data Sync server authenticates using the Wireless PIN. To change the option, set the syncml_authcredlabel parameter to PSW. The password to use for basic and MD5 authentication can be further customized by setting the syncml_basicauthcredlabel or syncml_md5authcredlabel to PSW or PIN, respectively, thus overriding the value set in syncml_authcredlabel.
Restart the Oracle Calendar server.
The following safeguards can be used to enhance the security of calendar data:
Oracle recommends that the Oracle Calendar server, if financial resources permit, be placed on a dedicated computer. In addition, turn off any TCP and UDP services on the host, which are not critical to the Oracle Calendar server (e.g., FTP, NFS server and client, or X server).
Users and administrators should take advantage of the other directory administration tools provided for password management. For Oracle Calendar server SYSOP passwords, the following are the policy or 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 Oracle Calendar server and other mission-critical systems (although this may not be possible if these applications all use the same directory server).
Use the unioidconf or unipasswd utilities in the $ORACLE_HOME/ocal/bin directory to change the SYSOP password. For more information on changing SYSOP passwords, refer to Chapter 4 of the Oracle Calendar Administrator's Guide.
The Oracle Calendar server 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 older Oracle Calendar clients 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 on feature. Parameter invalidlogin_enable in the [ENG] section can be used to enable the invalid sign on counting mechanism. This parameter should only be used when Calendar has been deployed in standalone mode. The [ENG] allowpasswordchange_user parameter can be used to stop users from changing their password. For more details on these parameters, refer to Chapter 3 of the Oracle Calendar Reference Manual.
Even if the server is dedicated to the Oracle Calendar server, there are still additional security safeguards to consider.
If you have security servers within your organization, consider sending audit trail information from the Oracle 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, so ensure that your backups are protected from theft. Consider separate ownership of the root or administrator (auditing account) and the calendar (server management) accounts. This would allow root or 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:
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.
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 log on attempt abuses. Enable the act.log by setting the [ENG] activity parameter to TRUE in the $ORACLE_HOME/ocal/misc/unison.ini file. For more information on this parameter, refer to Chapter 3 of the Oracle Calendar Reference Manual. You can detect log on 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. Refer to Chapter 14 in Oracle Calendar Administrator's Guide for more information.
Denial of service attacks usually attempt to exhaust or destroy any resource required by a system to deprive users of the services they would normally expect. The most common kind of denial of service attack is simply to send more traffic to the network address of an application than the application can handle.
This section focuses on the class of denial of service attacks that take place while the Oracle Calendar server is running, and for which the attacker has not obtained direct access to the system on which the Oracle Calendar server is running.
The Oracle Calendar server can be configured to warn and protect against such attacks, by configuring parameters in the [ENG] section of the $ORACLE_HOME/ocal/misc/unison.ini file. The following is a list of configurable parameters, including brief descriptions, which can be used to warn and protect against denial of service attacks:
dos_maxsessionsperaddr - Control the number of client connections from a specific IP address.
dos_maxsessionsperaddrblacklist - Restrict connections to the Oracle Calendar server based on IP address.
dos_maxsessionsperaddrredline - Specify the maximum number of client connections from one IP address before logging begins.
dos_maxsessionsperaddrwhitelist - Specify a list of IP addresses that are exempted from being blocked.
dos_timeoutdatareceived - Timeout value for non-header data.
dos_timeouthandshake - Timeout value for handshake data.
See Also:
Chapter 3 of the Oracle Calendar Reference Manual for more information on these parametersThe 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 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 attacks caused by very large files that cause a server to run out of disk space. For more details on these parameters and others, refer to Chapter 3 of the Oracle Calendar Reference Manual.
It is recommended that you always use Secure Sockets Layer (SSL) encryption to access the Oracle 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 Oracle 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.
The parameter [CONFERENCING] url defines the URL used by the Oracle 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 Real-Time Collaboration Web Conferencing parameters, refer to Chapter 3 of the Oracle Calendar Reference Manual.
Oracle Collaboration Suite 10g Content Services (Oracle Content Services) provides the basic security infrastructure required by any shared, network-accessible system, including authentication and authorization. This section describes the architecture and configuration of security in Oracle Content Services. It contains the following topics:
Authentication is a process in which a user provides some proof of identity (called a credential, which is often constructed from a user's password by means of a hashing or encryption algorithm) before that user can attempt to access objects in the system. Oracle Content Services uses Oracle Internet Directory, Oracle's LDAP-compliant directory service, for authentication.
Users provide their user name and password to the client software. These are passed to the Oracle Content Services protocol servers, which, in turn, pass them to Oracle Content Services for authentication. Then, Oracle Content Services passes the user name and password to Oracle Internet Directory. Oracle Internet Directory determines whether the user name and password are valid for the user.
This section describes the security considerations for protocol servers and contains the following topics:
Note:
The defined behavior of some industry-standard protocols is not inherently secure. Oracle has no control over the defined behavior of these protocols, and these security issues do not represent defects in Oracle software.The File Transfer Protocol (FTP) sends unencrypted user passwords across the network, which means that if one of these passwords is intercepted, then it could provide access to all systems controlled by Oracle Internet Directory for that user. To provide more security, users should create an FTP password (rather than the default Oracle Internet Directory password) to authenticate against FTP.
The FTP password is stored in Oracle Internet Directory and is different from and in addition to the regular Oracle Internet Directory password. Each user can have only one FTP password in one Oracle Content Services domain. FTP requires users to log in with an FTP password rather than an Oracle Internet Directory password.
Users can set their FTP password on the User Preferences page in Oracle Content Services. Users can also use the Oracle Internet Directory Self-Service Console to set their FTP password, by setting the content password entry that appears in the Application Passwords section of the Change Password page.
As an alternative, users can use FTPS. FTPS is FTP with the added option of Secure Socket Layer (SSL) security. FTPS does not require an FTP password.
By default, FTP and FTPS are disabled.
See Also:
Oracle Content Services Administrator's Guide for detailed information about how to enable FTP and FTPSThe HTTP/WebDAV protocol allows digest (hashed challenge/response), Single Sign-On (from the browser only), and persistent cookie (if the domain and then the user enables the feature) authentication. Whether HTTP/WebDAV uses SSL depends on the configuration of Oracle HTTP Server and on whether Oracle Content Services has been configured for SSL.
Oracle Drive is a desktop client that uses the WebDAV protocol to access Oracle Content Services. After it is installed, Oracle Drive appears as a mapped drive in Windows Explorer. Oracle Drive also provides file synchronization capabilities between your local computer and Oracle Content Services.
The FTP and HTTP/WebDAV protocols do not encrypt the network channel by default. This means that files transferred using these protocols are susceptible to interception. If you are unwilling to accept this behavior, then you should disable these protocols or configure them to use SSL (HTTP/WebDAV only).
Because user quota is managed asynchronously through the Quota Agent, it is possible for a malicious user to upload a very large file for filling up disk space. To prevent such attacks, you can limit the size of any single file uploaded to Oracle Content Services by setting the IFS.DOMAIN.MEDIA.CONTENTTRANSFER.ContentLimit domain property. If you try to upload a file beyond the specified limit, then the upload fails. This limit does not apply to administrators.When this property is set to 0, the default value, the content limit is disabled. You will be able to upload any file whose size is within the last calculated available quota, as of the beginning of the upload.
See Also:
Oracle Content Services Administrator's Guide for more information about theIFS.DOMAIN.MEDIA.CONTENTTRANSFER.ContentLimit domain propertyThe client session timeout period is the number of minutes of idle time after which a Web user interface session expires. By default, the client session timeout for Oracle Content Services is set to 30 minutes. To change this value, perform the following steps:
Access the Oracle Collaboration Suite Control and navigate to the Collaboration Suite Home page.
Select OC4J_Content and click Stop.
Click OC4J_Content to navigate to the OC4J_Content Home page.
Click Applications, then click content in the Deployed Applications table.
On the Applications: content page, click content in the Web Modules table.
On the Web Module: content page, in the Administration section click General under the Properties heading.
In the Session Configuration section, change the value for Session Timeout (minutes).
Click Apply, then click OK on the Confirmation page.
Return to the Collaboration Suite Home page, select OC4J_Content, and click Start.
If you have enabled Oracle Records Management, then you can also set the client session timeout period for Oracle Records Management. Repeat these steps for OC4J_RM to change the client session timeout period for Oracle Records Management.
Perform the following steps only if you configured Oracle Content Services prior to configuring HTTPS:
Access the Application Server Control for Collaboration Suite.
Sign in as the ias_admin user.
In the Collaboration Suite Home Page, click Content Services.
Click Domain Properties.
Edit IFS.DOMAIN.APPLICATION.ApplicationPort to point to the HTTP Server SSL Port.
Set IFS.DOMAIN.APPLICATION.ApplicationUseHttps to TRUE.
Restart all OPMN processes:
ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=Content ORACLE_HOME/opmn/bin/opmnctl starproc ias-component=Content
You can configure Oracle Content Services to use SSL. Before you do this, you must configure Oracle HTTP Server to use SSL.
You can also use SSL to connect to Oracle Internet Directory. Before you do this, Oracle Internet Directory must be configured for SSL.
You can provide SSL settings after Oracle Content Services has been installed and configured. Before you do this, Oracle Internet Directory must be configured for SSL.
The Oracle Content Services schema password is stored in the following locations:
Oracle Database
Oracle Internet Directory
Any Oracle Content Services Applications tier where you are running repository metrics
See Also:
Oracle Content Services Administrator's Guide for more information about repository metrics, and Oracle Collaboration Suite Administrator's Guide for more information about changing the Oracle Content Services schema passwordOracle Records Management is a records management application that ships with Oracle Content Services.
When you install Oracle Content Services, Oracle Records Management is installed automatically, but the application is disabled by default. You can use the Oracle Collaboration Suite Control to enable Oracle Records Management. You can also configure records management-related metrics.
See Also:
Oracle Content Services Administrator's Guide for more information about enabling Oracle Records ManagementOracle Content Services provides retention hardware capabilities through partnerships with Network Appliance and EMC. You can use the Oracle Collaboration Suite Control to integrate Oracle Content Services with Network Appliance SnapLock or EMC Centera.
To integrate Oracle Content Services with a records management retention device, you must first install the hardware (either EMC Centera or Network Appliance SnapLock). Then, you must specify credential information for the hardware and set retention-related domain properties using the Oracle Collaboration Suite Control.
Once you have created a file plan and defined retention policies in Oracle Records Management, Oracle Content Services will designate appropriate content as records to be stored in a records management retention device.
See Also:
Oracle Content Services Administrator's Guide for more informationThis section describes how to secure Oracle Collaboration Suite 10g Mail. It contains the following topics:
Configuring SSL Between Oracle Collaboration Suite 10g WebMail and Oracle Internet Directory
Implementing Secure Multipurpose Internet Mail Extension (S/MIME)
A thick client that is used to connect to the Oracle Mail message store uses one of the Internet standard e-mail protocols, Post Office Protocol version 3 (POP3) or Internet Mail Access Protocol version 4 (IMAP4). Regardless of the protocol used to connect to the protocol server, you need to provide a user name and password. The server confirms the user name and password against the Lightweight Directory Access Protocol (LDAP) server of Oracle, Oracle Internet Directory.
Secure Sockets Layer (SSL) is a protocol for transmitting private documents over the Internet. SSL works by using a public key to encrypt data that is transferred over the SSL connection. Many Web sites use the protocol to obtain confidential user information, such as credit card numbers. By convention, URLs requiring an SSL connection start with https: instead of http:. You can configure the IMAP and POP protocol servers to use SSL for securely communicating with and authenticating clients. Two separate server instances are required to use both SSL and non-SSL connections because one server instance cannot manage both types of connections. Administrators can choose to configure an existing server instance or create a new instance. By default, server instances are configured to manage only non-SSL connections. The default listening end points for both IMAP and POP protocol servers are created in the listener.ora file during installation. It is necessary to ensure that the client connects to the new IMAP/SSL listener. Almost all e-mail clients have an option that enables you to connect securely using SSL.
The primary goal of the Transport Layer Security (TLS) protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers, the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol, such as TCP, is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties:
The connection is private
The connection is reliable
TLS enables the communication between either client and server, server to server, or both to be secured (more so than traditional SMTP which passes most of its data in clear text over its communication channel).
The security is negotiated between the two sides, so enabling it for a server does not force all other parties to use it, which is important since many mail servers might not support it, or require it. Essentially, TLS allows the user to use the best available security on the server they are using.
The IMAP and POP protocol servers can be configured to use SSL for securely communicating with and authenticating clients. To use the SSL client connections, administrators can configure an existing server instance or create a new instance. Two separate server instances are necessary to use both SSL and non-SSL connections. One server instance cannot manage both types of connections. By default, server instances are configured to manage Internet connections only. The default listening end points for both IMAP and POP protocol servers are created in the listener.ora file during installation.
To configure an SSL server instance:
Log in to Oracle Enterprise Manager 10g Application Server Control Console.
Select the application server instance where Oracle Mail is installed.
Click Mail Application.
Click IMAP Server or POP Server.
Click the process instance.
Select IMAPSSL, POPSSL, or Custom from the Presentation Name drop-down list in the General Parameters section.
If you select Custom:
Provide a specific presentation name in the corresponding field.
Change the SSL Enabled parameter to True and verify that there is a description entry in the listener.ora file for the presentation name you specified.
Verify in the listener.ora file on the Oracle Collaboration Suite Applications Tier host that the SSL presentation specific PROTOCOL is set to TCPS and that the PORT is set to the default SSL port number of the protocol server. The default SSL port number for IMAP is 993 and for POP it is 995.
Obtain an SSL certificate and configure the network listener for SSL as described in "Certificates and Oracle Wallets".
See Also:
"Managing Oracle Mail Servers and Instances" in Chapter 3 of Oracle Mail Administrator's Guide for more information about configuring Oracle Mail protocol serversOracle Collaboration Suite 10g WebMail (Oracle WebMail) relies on Oracle Internet Directory for authentication, through Oracle Application Server Single Sign-On, to look up users in the directory, and to access the user's address book. The connection between Oracle WebMail and Oracle Internet Directory can be secured by configuring SSL.
To configure SSL for the connection between Oracle WebMail and Oracle Internet Directory, add the following properties to the oc4j.properties file:
oracle.mail.ldap.connectssl=true oracle.mail.ldap.sslport=4031
See Also:
"Oracle WebMail Client Properties" in Chapter 4 of Oracle Mail Administrator's Guide for a complete list of Oracle WebMail client propertiesTLS is used to provide a layer of security for the protocol servers that do not have a dedicated port for handling SSL connections, such as the SMTP Inbound server.
For those protocol servers that must handle both SSL and non-SSL traffic on the same port, the ability to switch over to SSL mode at the will of the client, is necessary. With TLS configured, clients can connect in non-SSL mode, check the server capabilities, and, if SSL is supported, issue a STARTTLS command and switch over to SSL mode.
To configure a TLS server instance:
Log in to Oracle Enterprise Manager 10g Application Server Control Console.
Select the application server instance where Oracle Mail is installed.
Click Mail Application.
Click IMAP Server or SMTP Inbound Server.
Click the process instance.
Specify the wallet location in the Wallet Location for TLS Support parameter in the General Parameters section. Enter file: followed by the absolute path to the directory in which the SSL wallet is located.
Set the Support STARTTLS Command parameter to True.
Obtain an SSL certificate and configure the network listener for SSL as described in "Certificates and Oracle Wallets".
Simple Authentication and Security Layer (SASL) is a method for adding authentication support to connection-based protocols. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If the use of SASL is successfully negotiated, then a security layer is inserted between the protocol and the connection.
To configure SASL for Oracle Mail:
Configure Oracle Internet Directory to generate dynamic password verifiers.
Oracle Internet Directory generates the attribute orclrevpwd when you provision a user if the attribute orclpwdencryptionenable in the realm password policy entry is set to 1. Therefore, you must set orclpwdencryptionenable to 1 before you provision users. Alternatively, if users were provisioned before you set orclpwdencryptionenable, all users must reset their user passwords to trigger the generation of the encrypted value.
Use Oracle Enterprise Manager to edit the following protocol server parameters at the default level:
Allow Clear Text Login: False
SASL Authentication: Enabled
SASL Protection: Confidentiality
See Also:
"Managing Oracle Mail Servers and Instances" in Chapter 3 of Oracle Mail Administrator's Guide for more information about configuring protocol server parametersE-mail viruses have long been a concern in any IT-enabled industry. Viruses cause lost productivity and consequent losses in revenue. As a result, it is important to eliminate viruses wherever and whenever possible. According to the Radicati Group, the economic damage caused by computer viruses is likely to rise from almost $30 billion in 2003 to over $70 billion in 2007.
Viruses can enter a system through infected e-mail messages. The first and best place to detect and eliminate e-mail viruses is where they enter the system, which is at the Message Transfer Agent (MTA)/Simple Mail Transfer Protocol (SMTP) level. Oracle currently provides tight integration at the MTA level with Symantec's antivirus offering, but any SMTP-based antivirus scanner can be used to relay to the SMTP_IN MTA of Oracle.
These third-party virus-scanning software offerings scan each message that passes through the SMTP server. The virus-scanning software can be set to reject the infected message on arrival or fix the virus (if possible), preventing the virus e-mail from entering the e-mail system. If there is a virus outbreak before the third-party software has a chance to upgrade itself, then some virus e-mail messages may already be present in the e-mail message store.
There will always be a lag between the time that a new virus spreads and the time that antivirus vendors fingerprint the virus, update their signature database, and you apply the update to your antivirus scanner. So, there is always a possibility that a virus could enter the message store. The Oracle Mail virus scrubber process, described in Prescanning Using the Virus Scrubber, can be used to scan the entire message store, repair, or remove virus e-mail messages.
See Also:
"Symantec AntiVirus Scan Engine" in Chapter 6 of Oracle Mail Administrator's Guide for more information about Oracle Mail virus protectionThe Oracle Mail virus scrubber is a server process that scans for and cleans up virus-infected e-mail messages already in the message store. When rapid measures are required to immediately clean virus-infected messages, the virus scrubber prescans a message store to isolate suspect messages from a system, based on headers, subject, or attachment names. Prescanning isolates suspect messages so that users are not able to access them and possibly cause damage. Prescanning never deletes a message. After prescanning, the virus scrubber uses the external scanner to individually scan the isolated messages. A message that is deemed clean or repaired by the virus detection software is restored to its original folder.
If a message is identified as infected and not repairable, then the administrator can either delete the message immediately or quarantine it to a special folder for later processing. For example, an infected message can be quarantined to wait for a future release of virus definitions that may be able to repair the message. Oracle Mail can be configured to send a message to either the mail recipient or sender notifying them that it was identified as infected. Such notifications are useful to explain to users why some of their messages seem to have disappeared.
The e-mail message store of Oracle Collaboration Suite is Oracle Collaboration Suite Database, which has been tuned to excel at sifting, sorting, and operating on large amounts of data. Using the MAIL_AV antivirus packages within the message store database, administrators can scrub the entire message store very quickly and efficiently with no downtime for their users. Oracle Global IT, for example, was able to scrub 2.5 terabytes of e-mail to quarantine over one million infected e-mails in well under half an hour, while users experienced no downtime. Compare this with a distributed message store, where each store that has been scrubbed is often reinfected by an infected e-mail from a to-be-scrubbed store, or bringing offline all the message stores while they are individually scrubbed.
The Oracle Mail virus scrubber is different from the SMTP-based virus scanner that filters out virus-infected messages before they enter the system. The Oracle Mail virus scrubber is a necessary complement to the SMTP-based virus scanner because new types of viruses continue to appear before virus detection software can be updated to detect and repair them. There is always a possibility that by the time the virus software is updated, some infected messages have already entered the system. The virus scanner can be used to retroactively rid the system of such viruses. This message store-based scanner can also be used to scan viruses coming in through a non-SMTP route such as IMAP append.
Another widespread issue related to e-mail is that of unsolicited commercial and bulk e-mail, which is commonly referred to as spam. A study released by Ferris Research has estimated the cost of spam to U.S. corporations at $8.9 billion a year.
As in the case of virus control, Oracle Collaboration Suite defers to vendors who specialize in complex spam management, but provides routing control that can prevent some spam from entering the Oracle Mail system.
When routing control is utilized, every e-mail passing through the Oracle Mail MTA is subject to checks for both trusted and nontrusted e-mail features in the:
Sender's address
Sender's domain
Recipient's address
Recipient's domain
IP address of sending computer
IP address of receiving computer
Sender/recipient pairs
E-mail headers with specified values
Attachment names with specified values
Oracle Collaboration Suite also provides Denial of Service prevention. If more than a specified number of connections or messages are received from a host within a given time interval, then all further messages from that host are blocked. The time period and count are both configurable. If the MTA cannot perform reverse DNS lookups for e-mail sending domains due to deployment reasons, then you could use SMTP-AUTH, but security is still required.
See Also:
"Oracle Mail Routing Control" in Chapter 8 of Oracle Mail Administrator's Guide for more information about configuring Oracle Mail to reject spamAlthough server-based mailing lists or distribution lists are useful, they can be abused if they are not effectively controlled and managed. The mailing list server in Oracle Collaboration Suite provides the ability to manage subscriptions to lists and also control who can or cannot send e-mail to the list.
Mailing lists can be of the following types:
Announcement: Users can send messages to the list but replies to the entire list are not allowed.
Discussion: Users can send messages and also reply to the list.
Edited: Only designated editors can post messages to the list. Messages from other users are rejected. The list owner specifies editors for the list.
Moderated: A moderator chosen by the list owner screens all messages. Only approved messages are posted to the list.
Mailing lists may also have one of the following subscription criteria:
Unrestricted or open lists: Open to subscription by all users.
Restricted lists: New subscribers need to be approved by the list owner.
Closed lists: A user is invited to join the list to subscribe.
These subscription criteria ensure that content for mailing lists is sent and received by users.
Although it is possible to secure network traffic between the client and server when you authenticate and retrieve your e-mail, any e-mail that is sent is subject to transmission through several computers on the Internet. The Internet standard for relaying e-mail between servers is SMTP, and although this protocol has an SSL-like extension called TLS, there is no guarantee that every SMTP server relaying your message will use TLS.
Many e-mail clients support the use of S/MIME, and Oracle Collaboration Suite also supports the use of this feature. S/MIME allows a certificate, similar to those used for enabling SSL on servers, to be imported into a client wallet within the browser or e-mail client. Therefore, any S/MIME compatible client can be used with Oracle Mail.
When you compose an e-mail, it can be electronically signed using the certificate in your local wallet. The e-mail is sent in the clear, but the recipients can detect whether the e-mail content has changed in transit and also verify that the senders are indeed who they say they are. You can also choose to encrypt the e-mail for the recipients, so that only the recipients can read that e-mail by using their local certificate to decrypt the e-mail.
For example, if Alice wants to send Bob an encrypted e-mail, then Alice needs the public part of Bob's key. Similarly, for Charlie to verify an e-mail signed by Alice, Charlie needs the public part of Alice's key. It is easy to see that for a large organization, expecting every user to keep the public part of every other user's key is unreasonable. Oracle Internet Directory can be used to store a central repository of public keys of users so that S/MIME implementation becomes easy.
See Also:
Chapter 6 of the Oracle Mail Administrator's Guide for information about Oracle Mail securitySecurity in Oracle Collaboration Suite 10g Mobile Collaboration is provided by the underlying technology in Oracle Application Server Wireless.
Oracle Application Server Wireless combines advanced content transformation, device adaptation, and network adaptation services with end-user customization, providing enterprises, mobile operators, content providers, or wireless ISPs with a platform to create and deploy mobile applications.
See Also:
Oracle Application Server Wireless Administrator's Guide for information about OracleAS Wireless securityAdditionally, security for Oracle Mobile Data Sync is provided by the underlying technology in Oracle Calendar.
See Also:
Securing Oracle Calendar for more informationThis section contains the following topics:
Mobile Push Mail provides an always-available e-mail experience on supported mobile devices. Mobile Push Mail is implemented as a client-server system. The client side code is referred to as Push Mail Client and the server side code is referred to as Push Mail Server.
The Push Mail Client contains three major components: an e-mail application, a client message store, and an e-mail transport. The e-mail application (such as the Inbox application on Microsoft Windows mobile devices) provides a user interface for manipulating messages in the client message store. The e-mail transport synchronizes the client message store with the e-mail server. The e-mail transport for the Push Mail Client is called the P-IMAP Transport because it uses the P-IMAP protocol to communicate with Push Mail Server.
Push Mail Server supports the P-IMAP protocol over several bindings. In 10g Release 1 (10.1.1), it supports P-IMAP bindings over the HTTP and HTTPS protocols. In addition, Push Mail Server also supports notification delivery to mobile devices using connectionless, Short Messaging Service (SMS) channel or UDP/IP channel. It also has a device management service that, among other things, installs, updates, uninstalls, and wipes Push Mail Client on the mobile device over the air (OTA). Push Mail Server communicates with the Oracle Collaboration Suite Mail server, which is where all the e-mail messages are stored. Each client message store has a corresponding server message store in the e-mail server.
The Mobile Push Mail System Architecture is shown in Figure 2-3.
Push Mail Client runs on a mobile device and has three major components: e-mail application, client message store, and P-IMAP Transport.
The e-mail application (such as the Inbox application on Microsoft Windows mobile devices), provides the user interface for mobile users. The e-mail application may support multiple client e-mail accounts.
In response to the user's actions, the e-mail application invokes the methods provided by P-IMAP Transport, or performs operations on the client message store. For example, if a user clicks Connect in the e-mail application, the e-mail application calls the connect method of P-IMAP Transport. If the user reads or otherwise manipulates a message, the e-mail application sets the appropriate flag associated with the message in the client message store. In response to this operation, the client message store generates events. P-IMAP Transport receives these events through a call back function it registers with the client message store. The call back function processes the events and inserts appropriate P-IMAP client events into the event queue.
In addition to providing a method for the e-mail application and responding to events generated by the client message store, the Command Processor component of P-IMAP Transport communicates with the Command Processing service of Push Mail Server to send and receive updates and apply these updates to the client message store. This communication is done using the P-IMAP protocol.
The Command Processing service of Push Mail Server establishes a session (server session) with Oracle Collaboration Suite Mail Server on behalf of the user. The communication protocol used in this session is IMAP. Push Mail Server uses this session to update the server message store and get changes for the client message store. This session may use the IDLE command of IMAP protocol to get unsolicited server updates. Alternatively, it may occasionally issue the FETCH command to poll the server for changes on the client. The server session is kept alive for an optimal period of time.
P-IMAP defines two ways in which a client can receive data pushed (notification) from a server. The first, called In-Band, uses the IDLE command of P-IMAP so that the client can listen to the server on the same channel it uses to communicate with the server. The second, called Out-Band, requires the server to use a separate channel to push the data. In Oracle Collaboration Suite 10g Release 1 (10.1.1), the separate channel can be a Short Message Service channel or UDP/IP channel. If a client chooses to use Out-Band notification with the UDP channel, the P-IMAP Transport establishes a UDP/IP session with the server.
The Notification Processor component of P-IMAP Transport waits for the arrival of a notification from the Notification Delivery Service of Push Mail Server either by intercepting and inspecting the incoming SMS messages, or by listening for notifications from the server through a UDP/IP channel. When a notification is received, Notification Processor inserts an appropriate event into the event queue, depending on the content of the notification.
Oracle Collaboration Suite Mail Server publishes notification messages for users who have registered to receive notifications for certain events. The Notification Collection service of Oracle Collaboration Suite Push Mail Server registers the P-IMAP notification filters for each user and retrieves the notifications from the notification message queue. The Notification Delivery Service of Oracle Collaboration Suite Push Mail Server then delivers the messages to the mobile devices through the selected Out-Band notification channel, the encrypted UDP/IP channel or the Short Message Service channel.
The Network Monitor component of the P-IMAP Transport monitors network connectivity of mobile devices. It calls back registered observers whenever there is a change in network connectivity. Network Monitor gathers information about available networks, make a decision as to which network to use, and passes relevant information about the network to the callback functions. The information passed by Network Monitor enables callers to determine the type of network (cradle, WiFi, GPRS, and others). Observers can decide what to do based on the network status.
The Device Management service is responsible for installing, updating, and removing P-IMAP Transport and other client programs, and setting/resetting some registry entries for users.
To better understand the security features of Mobile Push Mail, it is important to know the steps a mobile user takes to install and use the Mobile Push Mail:
Register and download Push Mail Client
The user must first use the Mobile Preferences web page through a desktop browser in order to identify himself and register his device. Based on the device capability, the user is shown a menu of client programs available for installation. If the device can run Push Mail Client, and the binary code for the client for the device is available in Push Mail Server, then the user is presented with the option to install Push Mail Client. If the user chooses to install the client, the Device Management service sends an SMS message to the device. The SMS message contains a URL constructed for the device. When the user goes to the URL, the Device Management service installs the necessary binaries on the device and sets the registry entries.
Normal use with In-Band notification
The user uses the Mobile Push Mail feature with a client that uses In-Band notification mechanism. This applies to all users using the Windows Mobile client supplied by Oracle Corporation or the BlackBerry client supplied by Consilient Corporation.
Normal use with Out-Band notification
The user uses the Mobile Push Mail feature with a client that uses Out-Band notification mechanism. This applies to many Nokia and Sony-Ericcsson clients supplied by Consilient Corporation.
Upgrading the Push Mail Client
Whenever a new version of Push Mail Client is available (that is, uploaded to Oracle Collaboration Suite Push Mail Server), the Device Management service of Push Mail Server notifies the user with an SMS message. The user can upgrade the client program by going to the URL contained in the message.
Loss of device
When the user loses a device, the device must be locked down and wiped cleaned of all programs and data. The user or the administrator can do this by using the remote lock down feature of Push Mail Server. The mobile user can also do it by accessing the Mobile Preferences page and deleting the device from your list of devices.
Preventing malicious actions against the client or the server
In these days of increasing sophistication in attack against computing system on the Internet, Mobile Push Mail has been designed to prevent and withstand malicious use of both the client and the server. This requires the server to be deployed properly, as described in the guidelines in Oracle Collaboration Suite Deployment Guide.
The security features in each step are described in the following topics:
To use the Push Mail feature, users must first be created as valid users, and be provisioned to access e-mail. The user then must register each of his mobile devices to be able to download the Push Mail client. To register a device, the user must first log in to the Oracle Collaboration Suite portal using the single sign-on password. This interaction is done through HTTPS, which provides mutual authentication of client and server, privacy, and message integrity.
From the portal page, the user chooses the Mobile Preferences page on which the user registers the mobile device. For each device, the user is presented with the mobile client programs available for the device. If the user's device is one of the supported devices, then the user can select the appropriate choice, and click Configure. The Push Mail Server performs the following tasks to install the push mail client program on the device.
The Push Mail Server generates a unique key over a very large key space that is practically impossible to guess.
The server associates the key with the user and his device. It then constructs a URL to the server with the key as a parameter, and sends the URL through an SMS message to the user's device.
The user can go to the URL to download a bootstrap program to set up the Push Mail Client. For those devices that are not capable of receiving SMS messages or for additional security, the URL with the key is also displayed to the user so that the user can enter it in the browser's address bar on the device. In any case, the key is good until the user completes the installation or returns to the Mobile Preferences page to download the client for the same device. This is to prevent replay attack on the server.
Depending on the device type, the bootstrap program will differ, and the user may be required to take slightly different actions. Regardless of the differences, the bootstrap program will use HTTPS protocol to download the Push Mail Client. Again, the use of HTTPS guarantees authentication of client and server, privacy of communication, and integrity of the messages being exchanged between the client and the server.
The bootstrap program will also set appropriate registry or environment variables for the Push Mail Client.
The security features designed for normal use with In-Band notification are: mobile device security, security of communication between the P-IMAP Transport and the Push Mail Server, and security of Push Mail Server. These features are discussed in the following sections:
If not managed carefully, a mobile device can become a weak link in enterprise security. In 10g Release 1 (10.1.1), some aspects of mobile device security are built into the system while others are provided as recommended guidelines the mobile users should adhere to. It is imperative to recognize that the mobile user is the first line of defense against attacks on the Push Mail system.
When the Oracle Collaboration Suite Push Mail account is used on a mobile device, the e-mail application prompts the user for single sign-on password. The e-mail application passes the password to P-IMAP Transport, which uses it to connect the user to the Push Mail Server. The e-mail application may provide an option to store the password. The mobile user should carefully consider the convenience of not reentering the password frequently against the risk to enterprise security before storing the password.
Many e-mail applications also permit the user to specify the idle time period after which the application is locked requiring the user to reenter the password after the application has been idle for that time period. Although security is enhanced by a short idle time period, it also increases the inconvenience associated with using the application. Users must choose an idle time period that strikes a good balance between the conflicting goals of security and convenience. It should be noted that even if the e-mail application is locked, the P-IMAP Transport continues to receive pushed messages from the server.
The application lock out feature is necessary, and prevents a casual thief from obtaining the information stored on the device, but it is not sufficient to prevent a determined thief from getting the information. To further strengthen mobile device security, enterprises should install file encryption software on the device. These encryption software work transparently with any applications and they encrypt all data stored in the device using well-known encryption algorithms with varying key lengths.To further minimize the risk of a mobile device being used for malicious purposes, the user should wipe the device as soon as it is lost or stolen. There are two ways to wipe the device. One way is for the user to log in to Oracle Collaboration Suite server, go to the Mobile Preferences page, and remove the device from the list of communication devices. As a result of this action, the Mobile Push Mail server sends a lock down message to the device. The device removes the message store associated with the account, removes the P-IMAP Transport, and resets the appropriate registry entries.
Alternately, the user can inform the administrator who can use Enterprise Manager to remotely wipe the device using the lock down command.
Other defensive measures against malicious use include not installing any software on the device that is not provisioned by the enterprise administrator and not browsing any sites whose URL is not provisioned by the enterprise administrator.
Push Mail Client uses P-IMAP to communicate with Oracle Collaboration Suite Push Mail Server. In 10g Release 1 (10.1.1), P-IMAP is tunneled through the HTTPS protocol, which provides authentication of client and server using digital certificates, privacy of message using encryption, and integrity of message (to make sure that the message is not tampered with in transit) using message digest.
To enable server authentication by the client, a public key certificate issued by a Certificate Authority (CA) known to the client, must be installed on the server. The HTTP software on the client checks the certificate to authenticate the server. For example, Microsoft Windows mobile devices have built-in root certificates from several well-known CAs, and can validate certificate issued by these CAs.
The server may authenticate the client by simply requiring the client to enter a valid single sign-on password. This password is used by the Command Processing Service of the Push Mail Server to log in to the Oracle Collaboration Suite Mail server. The Oracle Collaboration Suite Mail server uses Oracle Application Server Identity Management service to authenticate the user.
To further strengthen the client authentication, a public key certificate can also be installed on the client. Oracle Application Server includes a Certificate Authority that can be used to generate client certificate that Oracle servers can use to authenticate the client.
For Microsoft Windows mobile clients, Microsoft has added support for the installation of local digital certificates. Local digital certificates can be used to allow specific devices such as the Pocket PC to access a Web site while preventing other devices that do not have the certificate installed. Network administrators can install their own root and local certificates, as well as manage the certificates on the Pocket PC. Because the certificate manager user interface is available to users of the Pocket PC, network administrators should tell users not to delete certificates or they may not be able to access some SSL Web sites.
The SSL client on the device negotiates with the SSL program on the server to agree on the encryption algorithm and session key to be use for encrypting messages.
Once the secure HTTPS channel is established, Push Mail Server sends an encryption key for the device management commands to the client. The client stores the encryption key in a registry.
Oracle Collaboration Suite Deployment Guide includes various deployment configurations for Oracle Collaboration Suite Push Mail Server. Because Push Mail Server must communicate with Push Mail Client over a wireless network, Push Mail Server should be placed behind a firewall that can filter the incoming traffic from the Internet and reject malicious use of the server.
For Oracle Collaboration Suite Push Mail Client using In-Band notification, Oracle Collaboration Suite Push Mail Server must be set up to listen to HTTPS port (port 443) for Internet traffic. No other port needs to be opened for the Internet traffic.
The Notification Delivery Service of Push Mail Server is used for device management purposes only, and device management messages are sent to the device using the normal SMS channel. The messages are encrypted using the key sent to the client during the bootstrap process.
Push Mail Server communicates with the Oracle Collaboration Suite Mail server using IMAP, with the SMTP server using SMTP, and with Oracle Database using the SQL*NET protocol. These communication ports must be opened for Push Mail Server but must not be opened for general Internet traffic.
With Oracle Collaboration Suite Push Mail clients using the Out-Band notification mechanism, the client establishes a UDP/IP channel with Oracle Collaboration Suite Push Mail Server in addition to the HTTPS channel. The server sends notifications regarding the events relevant for the client through this UDP channel. This section describes how this channel is established and used securely. The Mobile device security is the same as in normal use with In-Band notification. This section contains the following topics:
The Command Processor of the client that uses Out-Band Notification first establishes an HTTPS session with the Command Processing service of the Oracle Collaboration Suite Push e-mail server. Once authentication is done and a secure HTTPS channel is established, the Command Processor sends a P-IMAP command to select either SMS or UDP/IP as the desired mechanism for receiving notification. Push Mail Server then sends relevant information (such as the host IP address and port number) of the Notification Delivery Service along with an encryption key and a single use key (called a limited entry visa). The visa is a secure random number generated by the Oracle Collaboration Suite Push Mail Server over a very large range of numbers and almost never reused. The encryption key depends on the client. For Microsoft Windows 2003 mobile devices, the encryption algorithm used is Triple-DES and the combined key length is 128 bits. For BlackBerry devices, the encryption algorithm is AES and the key length is 128 bits. The client then uses the visa to communicate with the Notification Delivery Service of Oracle Collaboration Suite Push Mail Server to set up the UDP/IP channel. The message payload is encrypted with the encryption key provisioned by the server.
Push Mail Server can be configured to expire the encryption key used for Out-Band notification every so often. Whenever the encryption key has expired, the Notification Deliver Service issues a command to the Notification Processor that informs the client that the server wants to change the encryption key. The Notification Processor then requests the Command Processor to go through the process of obtaining a new key. It then resumes the process of communicating with the Notification Delivery Service using the new encryption key.
Server security for Oracle Collaboration Suite Push Mail Server that support Out-Band notification is identical to the servers that support In-Band notification except that the server that supports Out-Band Notification has the Notification Delivery Service that listens to UDP/IP messages on a certain port. This requires the firewall in front of the Oracle Collaboration Suite Push Mail Server to open the port and filter the messages to screen out malicious use.
The limited-entry visa used to establish the UDP/IP session with Push Mail Server can prevent Denial of Service attacks as those UDP/IP messages that do not carry a valid visa will be rejected right away with very little resource utilization.
Whenever a new version of Push Mail Client is available, the administrator can use Enterprise Manager to upload the client to Push Mail Server. When the upload is complete, Push Mail Server sends out an SMS message to each user affected by the new client. The SMS message contains the URL to download the new client.
Before downloading the new client, mobile users must ensure that the SMS came from the right phone number or short code and that the URL uses the HTTP scheme and refers to the enterprise Push Mail Server.
Oracle Collaboration Suite Push Mail Server can remotely wipe a mobile device clean of data and code. This feature is designed to clean up a lost device.
When a user loses his device, the user can do one of two things to wipe the device clean of enterprise e-mail content and the Oracle Collaboration Suite Push Mail Client program. The user can visit the Oracle Collaboration Server Portal page, go to the Mobile Preferences page and to the Advanced page to delete the device from the My Communication Devices section. Malicious use of this feature is prevented by user authentication required to access the Portal page.
The user can also inform the administrator who can then use Enterprise Manager to wipe the device. Malicious use is prevented by requiring the administrator with the right privilege to take the action.
Although malicious use of mobile devices has not been a concern up to now, this may change soon as mobile device usage increases. The mobile device user is the first line of defense against intruders attempting to enter enterprise information systems.
The Web browser on the device is the most vulnerable point in the defense of the device. As mobile device browsers become more and more powerful, they become susceptible to the same kind of attacks that desktop browsers suffer from. Enterprises should have a mobile device usage policy that includes permissible Web sites for browsing from mobile devices.
Other points of attack are the various listeners listening on various ports on mobile devices. For example, the User Agent Server component of SIP agent may be listening on a port for a SIP command and hackers may try to enter the mobile device using this port.
The Push Mail Client may open up to two ports on the mobile device. The first is an HTTPS port, which is always required. The HTTPS channel is not a general listener. It is a client-initiated point-to point channel to Push Mail Server that is securely established and used. Therefore, this port is secure.
The second is the UDP/IP port used only by Push Mail Client that uses the Out-Band notification mechanism. The UDP/IP channel is always initiated by the Notification Processor of the P-IMAP Transport running on the client. Thus, the client can be protected by a proxy server such as the Access Point of a cellular wireless network.
The client uses two mechanisms to ensure security of the channel: the visa and the encryption key. The client obtains the visa and the encryption key along with host address and port number of the Notification Delivery Service from Push Mail Server using the secure HTTPS channel. Thus, the identity of the client and the server are already verified by the HTTPS protocol.
The client will reject all the messages it receives on the UDP port that it cannot decrypt using the encryption key. As a result, the client can reject malicious UDP communication without using up too much of its resources.
The Notification Delivery Service of Push Mail Server will also reject all attempts to establish a UDP/IP session with it if the first UDP message does not contain a valid visa or the message payload cannot be decrypted. After that, the client and server negotiate a UDP time-out value. Once the time-out is agreed upon, the server will invalidate the visa and any attempts to establish a UDP channel with the server using the visa will be rejected. This prevents a replay attack on the server.
The Notification Delivery Service will change the encryption key from time to time. When the Notification Delivery Service wants to change the encryption key, it sends a message to the client. The client then goes through the entire process again to obtain the new key and establish a new channel to the server.
Push Mail Server is also designed to mitigate the effects of Denial of Service attacks. For example, several P-IMAP commands, such as LOGIN and CAPABILITY can be issued to the server without the user being authenticated. If the client does not carry a public key certificate, the server could be swamped with such requests sent from an attacker. To mitigate the effects from such attacks, Push Mail Server is designed to use as few resources as possible to respond to these requests.
In the simplest case, you can deploy Oracle Collaboration Suite on a single server that has a Network Address Translator (NAT) firewall with a public IP address in front of it. You can forward port 443 to Oracle HTTP Server port 443 for HTTPS and another, say 9300, for UDP if you want to support Oracle Collaboration Suite Push Mail Clients using Out-Band notification. You can then register your domain name with the IP address of the NAT firewall. For example, your domain name could be MyCompany.com. You can configure Oracle HTTP Server to route the incoming traffic on port 443 with the URL, MyCompany.com/pushMail to the port the Push Mail Server is listening on. You can also route the URL, MyCompany.com/nds on port 9300 to the port the Notification Delivery Service is listening on.
Although this scheme will work, in reality, you may want to protect your server with more advanced firewalls such as those that perform packet filtering or stateful inspection to defend against Denial of Service attacks. Depending on your IT budget and your security needs, you may also consider setting up a demilitarized zones. Refer to Oracle Collaboration Suite Deployment Guide for more information on this topic.
Mobile devices are inherent weak links in enterprise information security. The Mobile Push Mail feature of Oracle Collaboration Suite is designed to minimize the security risks associated with using mobile devices to access enterprise e-mail.
With a combination of guidelines of mobile device usage and the built-in features of Oracle Mobile Collaboration Server, enterprises can safely deploy Mobile Push Mail features.
Oracle has had the security of Mobile Push Mail assessed by independent security consultants. All issues identified by them have been addressed in 10g Release 1 (10.1.1).
This section describes the features of Oracle Real-Time Collaboration that keep your data secure and prevent unwanted access to your system. It covers the following topics:
Oracle Real-Time Collaboration User Management and Authentication
Oracle Real-Time Collaboration User Roles and User Privileges
The components of the Oracle Real-Time Collaboration Server are designed to provide appropriate levels of security for the entire enterprise. Figure 2-4 shows the basic components of the system.
Figure 2-4 Oracle Real-Time Collaboration High-Level Architecture
Table 2-3 provides a brief overview of security features for the components in the Oracle Real-Time Collaboration architecture.
Table 2-3 Security Features in Oracle Real-Time Collaboration Architecture
| Component | Security Features |
|---|---|
| Oracle Real-Time Collaboration Consoles (Clients) | Use the Oracle Identity Management infrastructure to authenticate users and provide single sign-on. Clients can connect directly within your company firewall, over the Internet, and over the Internet from behind a firewall. |
| Oracle Real-Time Collaboration Application Pages | Use the Oracle Identity Management infrastructure to authenticate users and provide single sign-on, supporting centralized management of user accounts. The application pages can be deployed with any type of standard security and network devices, such as hardware load balancers and SSL accelerators. |
| Programmatic Access through Integration Services | Use standard SOAP and XML over HTTP/HTTPS protocols. All services utilize AuthenticationService Web Service for authentication. AuthenticationService works with Oracle Real-Time Collaboration SiteID/AuthToken and the S2S authentication framework of Oracle Internet Directory. |
| Communication Services | Client connections can be direct or through standard ports in a firewall (Port 80 and Port 443) with no additional configuration. The client connections can be either SSL or non-SSL. |
| Oracle Real-Time Collaboration Services (data, voice, and presence) | Protected behind the Communications Services. |
| System Services and Application Services | Oracle Real-Time Collaboration application administrative pages and the rtcctl utility allow administrators to monitor the system and status of instances and components. However, administrators do not have privileges to join a conference to which they have not been invited, or participate in a message that was not sent to them. |
| Oracle Real-Time Collaboration Repository | Stores user roles, user documents, conference details, and conference and message archives is never directly accessible to users. Administrators access it through a secure database account. The full set of Oracle database features protect the data. |
The Oracle Real-Time Collaboration system provides secure access for clients from within the intranet, from the open Internet or across transparent proxies, and from behind a firewall. Figure 2-5 shows these connections.
Figure 2-5 Client Connections to Oracle Real-Time Collaboration
The Oracle Web Conferencing and Oracle Messenger console clients attempt to connect to the Oracle Real-Time Collaboration system using one of the following methods, attempting them in the following order until successful:
Direct connection: Clients within a corporate intranet connect directly to the RTC Redirector, which hands off connections to the Client Connection Manager (for instant messages) or Multiplexer (for Web conferences), using Jabber XMPP/XMPPS protocols for messaging, or proprietary protocols (MX) with TCP/IP or SSL for Web conferences.
HTTPS direct: Clients in the open Internet or across transparent proxies connect through HTTPS. The mod_imeeting plug-in uses the Oracle HTTP Server as the single listening point over port 443, then hands the socket off to the Connection Manager or Multiplexer.
HTTPS tunnel: Clients in a different intranet coming through their own internal proxy provide the console with proxy information from the browser settings. The console establishes a connection to the Oracle HTTP Server, which hands the connection off to the Connection Manager or Multiplexer over an HTTPS tunnel through the remote proxy. Again, the listening port is 443.
Note that for scenarios 2 and 3 to succeed, port 443 must be open to the Internet. In addition, the Oracle Real-Time Collaboration Applications tier must have an Internet-routable address, or you can use a Network Address Translator (NAT) to map the internal IP address to an external IP address.
Third-party XMPP clients for instant messaging, such as Gaim, can connect only using the direct TCP/IP method, assuming the client's user is provisioned in the Oracle Internet Directory. To allow third-party client access to instant messaging over the Internet, you must open the XMPPS port (by default, port 5223). Alternately, you may use a Network Address Translator (NAT) to map the internal IP address to an external IP address, and map port 5223 to the externally accessible port 443.
An administrator can set an entire Oracle Real-Time Collaboration deployment, or just an Oracle Real-Time Collaboration site, to use Secure Sockets-Layer encryption connections during Web conferences or when sending instant messages.
Administrators set these options using Oracle Real-Time Collaboration properties. Refer to "Configuring SSL Security" in Chapter 3 of Oracle Real-Time Collaboration Administrator's Guide for details about SSL-related properties.
Note:
Using controls provided in Oracle Collaboration Suite, an administrator can mandate use of SSL for some or all URLs in the Oracle Real-Time Collaboration Web application pages. Therefore, even if SSL encryption settings are not enabled as outlined in this section, users could be directed to a secure URL for the Web pages.The administrator can use Oracle Real-Time Collaboration properties to do any of the following:
Enable SSL-encrypted conferences and messaging, so that conference hosts can choose the SSL option when scheduling a conference, or the servlet that supports Oracle Messenger connections can choose XMPPS or HTTPS to make the connection.
Force SSL-encrypted conferences and SSL-encrypted messages on this system. Conference hosts and messaging users cannot choose non-SSL connections.
If SSL-encryption has been enabled, but not forced, then Web conference hosts can specify that a conference should use SSL encryption in either of the following ways:
To set a specific conference to use encryption, users select Oracle Web Conferencing Console on the Schedule tab and set Secure Communications on.
To set all conferences they host to use encryption by default, users select Oracle Web Conferencing Console from the Preference page, and set Secure Communications on.
If SSL-encryption has been enabled, but not forced, the servlet that chooses connections for Oracle Messenger will try to make HTTPS or XMPPS connections before attempting HTTP or XMPP connections. This happens automatically, provided Oracle Messenger users have set their Connection option to "Automatic Configuration for RTC Connection," in the Options command under Tools. (Automatic Configuration is the default option for all Oracle Messenger clients.)
Voice chat encryption is done using symmetric keys. The keys are generated for each voice session and the key length and algorithm are negotiated between the clients starting from the most secure AES 256 bit to RC40 bit. Clients could be running on different operating system versions. Therefore, the key length and algorithm varies across operating systems. The encryption is implemented using Microsoft Windows Crypto API. The following algorithms are supported by Oracle in the current implementation:
AES 256 (Windows XP, Windows Server 2003)
3DES 168 (Windows 2000, Windows NT)
RC2 40 (All Microsoft Windows platforms)
After the encryption mechanism is negotiated, the keys and the algorithm are exchanged over the secure SSL channel between the Oracle Real-Time Collaboration messengers through the Oracle Presence Server. Because the keys are exchanged over the primary connection to the Oracle Presence Server, if this is connection is not secure, that is, SSL is not used, then voice chat encryption is turned off. In essence, voice chat is encrypted only when the clients connect to the Oracle Presence Server over SSL.
Note:
The lock icon on the upper-right corner of the Oracle Messenger screen indicates whether or not the voice chat session is encrypted.The Oracle Real-Time Collaboration system, like the rest of the components in the Oracle Collaboration Suite, uses the Oracle Internet Directory to manage user data and the Oracle Internet Directory store, which uses LDAP (Lightweight Directory Access Protocol), to authenticate users. The Oracle Internet Directory host is specified at installation. All users of this Oracle Internet Directory can be provisioned to use Oracle Real-Time Collaboration. This supports centralized management of user accounts and privileges.
Users outside of the Oracle Internet Directory can be allowed limited access to Oracle Real-Time Collaboration services, or can be explicitly prevented from using those services. In addition, users within the Oracle Internet Directory can be assigned additional privileges for monitoring or managing the Oracle Real-Time Collaboration system. Refer to "Oracle Real-Time Collaboration User Roles and User Privileges" for more details about guest user and administrative user roles.
Users log in to Oracle Real-Time Collaboration Web pages and clients using their Single Sign-On user name and password. Only users who log in to the Web Client may download the Oracle Messenger client or the Oracle RTC Add-In to Microsoft Office, schedule or host Web conferences, or view archived records of conferences and chat sessions. Only users who log in to the Oracle Messenger client can send or receive instant messages, hold chat conferences, or publish their presence to other clients.
An administrator should inform users that it is important to log out and close browser and client windows whenever they have completed their tasks with Oracle Real-Time Collaboration. This prevents unauthorized access to system features and to archived records, reports or other data that should remain confidential.
The Oracle Real-Time Collaboration Integration Services are SOAP and XML services that provide access to Oracle Real-Time Collaboration features and functions. Integrated Services are supported by creation of a site, which is assigned a unique ID and associated authentication token when the site is created. When external clients access the services, those services pass the site ID and token to authenticate the client during the session for the provided service.
An administrator can choose to enable or disable access to some or all integration services using Oracle Real-Time Collaboration properties. Refer to "Enabling Integration Services" in Chapter 3 of Oracle Real-Time Collaboration Administrator's Guide for details.
For more information about Oracle Real-Time Collaboration integration services, refer to Oracle Real-Time Collaboration Application Developer's Guide.
An end-to-end test of Oracle Messenger checks whether a user can successfully pass a message to another user through the Oracle Presence Server. The test is run automatically on the Oracle Real-Time Collaboration system at periods defined by the administrator. Administrators can also run this test manually by using the imtest option with the rtcctl runTests command.
Two test user accounts are automatically provisioned for use by this test. The passwords for each account are different for each instance of the Oracle Real-Time Collaboration components and these passwords are generated by the system based on a base64 encoding of part of the instance key. The account names are test.user@im-agents.your_domain.com and im.test.user@your_domain.com.
There are two basic categories of users who may access the Oracle Real-Time Collaboration system:
nonregistered user: Also called a guest user. A user who is not provisioned in the Oracle Internet Directory. Users who are not provisioned through the Oracle Internet Directory can be invited to public conferences, or allowed to participate in instant messages in a "live help"-type session supported through Integration Services. These users are allowed only limited ability to use Oracle Real-Time Collaboration features.
registered user: A user provisioned in Oracle Internet Directory. This user is assigned an end-user role by default. Registered users can upload documents, host conferences, record and publish conferences, and can participate in conferences that are restricted to registered users only. Registered users can also download the Oracle Messenger client and use all of its features to send and receive messages, publish their presence, hold chat conferences, and so forth.
Administrators can choose to prevent nonregistered user access. By setting the Oracle Real-Time Collaboration property GuestUserAccessEnabled to false, administrators limit access to Oracle Real-Time Collaboration features:
The Archive tab, the Conferences in Progress, Scheduled Conferences, and New User sub-tabs, and the Join Conference area are removed from the prelogin Home page.
Instant conferences default to the "Registered Users" audience setting. (The normal default is for Instant conferences to be available to "All Users.")
Registered users scheduling conferences cannot choose the "All Users" audience setting to allow guest users.
When conference hosts publish URLs to let users join a conference, play back a conference, download the conference recording, or view conference summary and details, users who access those URLs must log in before they can do any of these tasks.
Oracle Real-Time Collaboration Integration Services prevent other scheduling applications from scheduling a conference that allows guest users. Such applications include both Oracle Collaboration Suite components such as Oracle Calendar, and any integrated applications that call Oracle Real-Time Collaboration APIs.
Oracle Real-Time Collaboration Integration Services will not support nonregistered users in chats. Therefore, integrations to support a "live help" scenario, allowing guest users to chat with users of Oracle Messenger, will not work.
Note:
If
GuestUserAccessEnabled is set to false, and you are using Oracle Calendar to schedule Web conferences, then you must set the allowguestusers parameter in Oracle Calendar to false as well. If the allowguestusers parameter is true, then when you try to create Web conferences that include nonregistered users through Oracle Calendar, the conference will not be created.In addition to the basic role allowed for registered users, Oracle Real-Time Collaboration administrators can assign additional roles to registered users that allow different levels of privileged access to Oracle Real-Time Collaboration management features.
business monitor: A registered user who has been assigned the ability to monitor the system and access system reports.
business administrator: A registered user who has been assigned the ability to start, stop, configure, and administer the system deployment. This user has the greatest number of privileges on the system.
site business monitor or site business administrator: A registered user who has been assigned the business monitor or business administrator privileges described previously, but only for a specific site.
Users with the business administrator role can set a number of Oracle Real-Time Collaboration properties that control some of the options available to users as they participate in Web conferences or instant messages. Other properties control what features are available in the Oracle Real-Time Collaboration Web application pages. Chapter 3 of Oracle Real-Time Collaboration Administrator's Guide has a complete list of available properties.
Users also have the option to set defaults for Web conferences using the Preferences command from the Web application, or defaults for instant messaging using the Options command under the Tools menu. Any settings by the administrator that affect these options can supersede these preferences. For example, if the administrator has disabled the desktop sharing interface inside all Web conferences, then that feature will not be available, even if the user has chosen it as a default.
Administrators can set properties at a system, site, instance, or Oracle Real-Time Collaboration component level. Typically, user privileges are set at the system or the site level. If a property is set on a system, then the site will inherit that value. But a separate value can be also be set on the site. So, for example, an administrator could allow access to desktop sharing on a site, even if it is disabled on the system.
An administrator can use the -force option of the rtcctl utility to force property settings on an entire system. Refer to "Using Oracle Real-Time Collaboration Properties" in Chapter 3 of Oracle Real-Time Collaboration Administrator's Guide for more details about forcing property settings.
Hosts can create a conference key to protect unauthorized entry to both Web conferences and chat conferences. The host specifies a key when creating a chat or instant Web conference, or when scheduling a future Web conference. The host can then send the key string to invitees using whatever method desired. For scheduled conferences, an encoded string for the key is included in the link to join the conference.
Only attendees to whom the host gives the key may enter the conference. This prevents others from entering, even if the conference is published in the public listing.
If a conference included a key, then users must enter that key in order to view the conference archives. This protects the archive from unauthorized access as well.
Within Web conferences or Oracle Messenger chat conferences, the person who hosts the Web conference or starts the chat conference has more privileges than other users. For example, Web conference hosts can prevent any other attendees from interacting with the desktop. Chat conference mediators can expel members from a chat session. This ensures that the person who started the conference can control the information being exchanged. Only the conference host or mediator can choose to allow other users to expand their roles in the conference.
For complete details about the various roles within Web or chat conferences, refer to the Oracle Real-Time Collaboration online Help.
Only registered users can schedule Web conferences. During scheduling, a host can choose what type of user can access the conference and whether the conference is visible to others from the Oracle Real-Time Collaboration Web pages. Table 2-4 shows what settings can be applied to control access to and visibility of scheduled conferences. All of these settings can be applied when using the Schedule tab.
Table 2-4 assumes that nonregistered users (guest users) are allowed access to Oracle Real-Time Collaboration. If guest users are not allowed, then the "All Users" option is not available, and conferences listed on a public Web page can be seen only by registered users.
Table 2-4 Audience and Visibility Settings to Control Conference Access
| Audience Setting | Visibility Setting | Accessibility |
|---|---|---|
| All Users | List conference on public Web page | Both nonregistered and registered users may attend. Anyone can see the conference in the Scheduled Conferences table, without logging in. |
| All Users | Off (not listed) | Both nonregistered and registered users may attend, if they are given the conference ID and conference key. Only registered users who are invited can see the conference in their "My Conferences" list from the home page. |
| Registered Users | List conference on public Web page | Only registered users may attend. Only registered users can see the conference in the Scheduled Conferences table post login. |
| Registered Users | Off (not listed) | Only registered users may attend if they know the conference ID and conference key. Only registered users who are invited can see the conference in a listing. |
| Registered Users by Invitation Only | Off (not listed). This is the only possible setting for this audience. | Only registered users who have received an invitation from the host may attend, and only those users can see the conference in a listing. |
Note that if a registered user is invited to a conference, that user will see a list of conferences to which he or she is invited when logging in. If a user is not invited to a conference, then he or she cannot see information about an upcoming conference unless the host has chosen to list it publicly. This way, a host can keep a conference confidential by choosing not to list it.
If the person who schedules a conference is not going to lead the conference, then that user can create an acting host key that another user can enter when joining the conference. The user with the acting host key becomes the conference's effective host.
Only a registered user can use the acting host key. Nonregistered users cannot use it. In addition, the acting host key does not override any conference permissions. If a conference is restricted to registered users by invitation, then only such a user can join with the acting host key.
There can be only one host for a conference, so only the first person to enter the conference with the acting host key is the host. After the conference is started by an acting host, the original host and any other user who joins with the acting host key join as presenters. If a conference is started by an acting host, then the conference ends when the acting host leaves, unless the acting host assigns another host before leaving.
Finally, by default, the conference archive is visible only to the original host who scheduled the conference, not the acting host. The scheduling host can choose to publish the archive as discussed in Web Conference Archives.
The details of every Oracle Web Conferencing session and each one-to-one instant message conducted on the system can be archived and stored in the Oracle Real-Time Collaboration repository.
All Web conferences are archived and stored in the Oracle Real-Time Collaboration repository. A conference archive consists of the following information:
Conference title, conference ID, and conference keyword, if any
Host name
Conference start date, time, and duration
Voice start time and duration (if voice streaming was used)
Number of attendees, including anonymous attendees
Conference recording (if any)
Details about each attendee: name, e-mail address, company, postal address, telephone number, times each attendee entered and exited the conference and voice streaming, and any additional information gathered through customized properties
Documents uploaded for the conference
URLs visited during the conference
Transcripts of chat sessions held within the conference
Results of any polls held during the conference
Conference archives can be viewed under the Archive tab. By default, the security restrictions of the actual conference (as shown in Table 2-4, "Audience and Visibility Settings to Control Conference Access") are applied to the archive. For example, if only registered, invited users could attend the conference, then only those users can view the archive.
The default information published contains only the conference basics (the title, start date and time, and number of attendees). The host can control what other information is published, and whether additional users can view it. The playback of the recording can also be secured through SSL encryption.
By default, archives are not enabled for Oracle Messenger. However, archives can be saved both on the server side, and on each client's side. Message archives contain the text of each message exchanged with another user, stored by user and sorted by message date. Message archives can be enabled in either or both of the following ways:
Administrators can set an Oracle Real-Time Collaboration property, IMArchiveEnabled, to save message archives to the Oracle Real-Time Collaboration repository. Refer to "Controlling Archives" in Chapter 3 of Oracle Real-Time Collaboration Administrator's Guide for details about setting this property.
Users can choose to save their messages locally, by selecting Tools and then Options from the Oracle Messenger client window, then under Instant Messages selecting Save Messages. Users can also set the size of the archive.
If users choose to save their messages to the client computer, they can view archives by right-clicking a contact name and choosing View Message Archive.
If archives are enabled for Oracle Messenger, then the information stored includes the following:
Name of the contact
Date the message was exchanged
Entire text of the message
Message archives are available to only those users who participated in the message. That is, if an administrator chooses to save archives to the repository, each Oracle Real-Time Collaboration user will be able to view only the messages that he or she participated in, using the Archive tab in the Web application.
Note:
Text chat conferences (a chat window with three or more users) are not archived, and participants cannot view archives of those chat sessions.Administrators may want to create a privacy statement or statement of acceptable use to present to employees, informing them that details of instant messages and Web conferences are recorded and stored in archives. To do so, administrators set the following Oracle Real-Time Collaboration properties:
PrivacyLink sets the URL to the Web page with your privacy statement.
ShowPrivacyLink sets whether the link to the Web page appears on Oracle Real-Time Collaboration Web pages.
Refer to "Configuring the Oracle Real-Time Collaboration Web Client Pages" in Chapter 3 of Oracle Real-Time Collaboration Administrator's Guide for more details about how to set these properties.
The Security report is available to business monitor and business administrator users under the Reports tab of the Oracle Real-Time Collaboration Web application pages. Administrators can review this report to identify how many security features are being used to protect conferences on the system.
Refer to "Oracle Real-Time Collaboration Security Report" in Chapter 6 of Oracle Real-Time Collaboration Administrator's Guide for more details about this report.
Oracle Voicemail & Fax provides basic security features including authentication and securing connections to Oracle Collaboration Suite Database. This section covers the following topics:
Oracle Voicemail & Fax uses Oracle Internet Directory for authentication. You can set preferred credentials for yourself, for selected users, and for all users who connect to Oracle Internet Directory from Enterprise Manager.
See Also:
Oracle Voicemail & Fax Administrator's Guide for information about setting preferred credentialsYou can secure your Oracle Voicemail & Fax connections by encrypting connections to the Oracle Collaboration Suite Database and by using SSL connections. From the moment the Oracle Voicemail & Fax user starts interacting with Oracle Voicemail & Fax, any communication Oracle Voicemail & Fax performs with other Oracle Collaboration Suite components can be secured. There are two major connection points, Oracle Collaboration Suite Database connectivity and Oracle Internet Directory connectivity.
You can encrypt all communications with the Oracle Collaboration Suite Database by configuring the Oracle Net connection between Oracle Voicemail & Fax and the Oracle Collaboration Suite Database. This ensures that any communication between Oracle Voicemail & Fax and the Oracle Collaboration Suite Database is secure. However, this requires configuration of the Oracle Collaboration Suite Database to allow encrypted or secure connections from Oracle Database clients.
See Also:
Oracle Advanced Security Administrator's Guide for more information about encrypting your Oracle Net connectionsSSL connections are used in various places, including when Enterprise Manager connects to Oracle Internet Directory, when the Oracle Voicemail & Fax Applications connect to Oracle Internet Directory, and between the Oracle Collaboration Suite 10g WebMail client and Oracle Internet Directory when authenticating users and accessing a user's address book.
See Also:
"Configuring SSL Between Oracle Collaboration Suite 10g WebMail and Oracle Internet Directory" for more information
"Enabling SSL in Oracle Voicemail & Fax" for more information on how to use SSL when connecting to Oracle Internet Directory
When you install Oracle Voicemail & Fax, you are prompted to provide passwords for the um and ovfmetrics user names, which are used, respectively, to connect the Voicemail & Fax Application and the Message Delivery Service to the Oracle Collaboration Suite Database. If, for some reason, you need to change a password for these users in the database, then you must also update the client applications that connect to the database with the new password.
See Also:
Oracle Voicemail & Fax Administrator's Guide for information on how to change the passwords in Oracle Voicemail & Fax