2 Oracle Collaboration Suite Applications Security

2.3.1.1.1 Secure Connections to Clients

The Oracle Calendar server negotiates with a client as follows:

1. The client starts up and connects to the server.

2. The client queries the server for the supported and default authentication, compression, and encryption methods.

3. The server returns a list of the supported and default authentication, compression, and encryption methods.

4. If the client cannot support one of the default methods, the server and client negotiate using the list of supported methods sent to the client in Step 3 to agree on a method that both support. Note that one of the supported methods for both compression and encryption can be none, making both compression and encryption optional.

5. The server authenticates the user using the negotiated authentication method.

6. The client and server communicate using the agreed upon methods for the duration of the user session.

   
   

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

   
   

2.3.1.1.2 Secure Connections to Another Calendar Server

The server negotiates with another calendar server as follows:

1. Server A receives a request from Server B.

2. Server A sends Server B a list of the supported and default authentication, compression, and encryption methods.

3. If Server B cannot support one of the default methods, Server A and Server B negotiate using the lists of supported methods sent in Step 2 to agree on a method that both support. Note that one of the supported methods for both compression and encryption can be none, making both compression and encryption optional.

4. Server A authenticates Server B using the negotiated authentication method.

5. Servers A and B communicate using the agreed upon methods for the duration of the connection.

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

   
   

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

   
   

2.3.1.4.1 Extending the Set of Plug-Ins

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.

Plug-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:

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 (%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 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 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 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 

2.3.1.5.1 Requirements

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

2.3.1.5.2 Configuring the Oracle Calendar Server

To configure the Oracle Calendar server:

1. Edit the $ORACLE_HOME/ocal/misc/unison.ini (for Microsoft Windows: %ORACLE_HOME\ocal\misc\unison.ini) file.

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

3. Add and configure the following parameters in the [ACE_PLUGINS_SERVER] section:

   [ACE_PLUGINS_SERVER]
   cs-standard_coexistence = TRUE
   web_CAL_sharedkey=123456789
   
   

   
   

   Note: The web_CAL_sharedkey parameter is a string composed of ASCII characters.

   
   

4. Save the unison.ini file.

5. Restart Oracle Calendar server.

2.3.1.5.3 Configuring the Oracle Calendar Web Client

To configure the Oracle Calendar Web client:

1. Open the $ORACLE_HOME/ocas/conf/ocwc.conf (for Microsoft Windows: %ORACLE_HOME\ocas\conf\ocwc.conf) file for editing.

2. Enable the Web authentication plug-in by changing the value of the [ACE] Authentication parameter to web: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.

   
   

3. Open the $ORACLE_HOME/ocas/conf/ocas.conf (for Microsoft Windows: %ORACLE_HOME\ocas\conf\ocas.conf) file for editing.

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

2.3.1.5.4 Configuring the Apache Distributed Configuration Files Architecture

To configure the Apache distributed configuration files architecture, perform the following steps:

1. For UNIX-based platforms, 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>
   
   

   On Microsoft Windows, 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>
   
   

2. Set up your users and the login password they will need to use when accessing the protected directory, as follows:

   1. Change to the Apache/bin (for Microsoft Windows: Apache\bin) directory.

   2. On UNIX-based platforms, type the following command to encode the user ID and password:

      ./htpasswd -c $ANY_DIRECTORY/htpasswd $ANY_USERID
      
      

      The equivalent command on Microsoft Windows is:

      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. For Microsoft Windows, htpasswd must be included in the PATH variable or should be in the current directory

      
      

      Note: The $ANY_USERID must be the same as the Calendar user ID for this example to work.

      
      

   3. You will be prompted to enter a password for $ANY_USERID. Type any password. This password does not need to be your calendar password.

3. On UNIX-based platforms, 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
   
   

   On Microsoft Windows, 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 the AuthUserFile parameter points to the location where you created your htpasswd file.

   
   

4. Restart Apache and the Oracle Calendar Web client.

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

2.3.1.5.5 Working of the Components Involved

Figure 2-2 illustrates the components involved while integrating the Oracle Calendar Web client with a third-party authentication framework.

Figure 2-2 Working of the Components Involved

Description of the illustration custom_auth.gif

The working of the components is described, as follows:

1. Initially, Apache sets the REMOTE_USER environment variable in the FastCgi request environment.

2. The Oracle Calendar Web client uses the configuration file and identifies the REMOTE_USER environment variable (web_attribute_name=REMOTE_USER).

3. The Oracle Calendar Web client retrieves the REMOTE_USER environment variable and passes it to the Oracle Calendar server through the secure link.

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

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

  For Microsoft Windows platform: the script should set the environment variables, 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=Drive_Letter\home\custom\script.bat
  
  

  Where script.sh|bat 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.

2.3.1.5.6 Troubleshooting Tips

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 (for MIcrosoft Windows: %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.

2.3.2.2.1 Preparing for Kerberos 5 Authentication

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:

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

   
   

2. Define a principal instance:

   The principal instance must be defined using the fully qualified domain name of the machine hosting Oracle Calendar server.

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

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

2.3.2.2.2 Configuring the Oracle Calendar Server

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:

1. Associate the plug-in with the principal name:

   1. Open the $ORACLE_HOME/ocal/misc/unison.ini (for Microsoft Windows: %ORACLE_HOME%\ocal\misc\unison.ini) configuration file.

   2. 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]
      
      

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

      
      

   4. Save the file.

2. Add Kerberos as a supported authentication mechanism:

   1. Open the unison.ini configuration file.

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

      
      

   3. Save the file

3. 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 (for Microsoft Windows: C:\winnt\krb5.ini).

     
     

     Note: These environment variables must always be set prior to starting the Oracle Calendar server.

     
     

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

   1. Open the $ORACLE_HOME/opmn/conf/opmn.xml (for Microsft Windows: %ORACLE_HOME%\opmn\conf\opmn.xml) file.

   2. Locate the <ias-component id="CalendarServer"> section of the file.

   3. 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 (for Microsoft Windows: C:\winnt\) directory, the <environment> subsection should have the following entry:

      <variable id="KRB5_CONFIG" value="/etc/krb5.conf/">
      
      

      For Microsoft Windows:

      <variable id="KRB5_CONFIG" value="C:\winnt\krb5.ini\">
      

      
      

      Note: krb5.conf is the Kerberos configuration file on Unix operating systems. On Microsoft Windows, the Kerberos configuration file is krb5.ini.

      
      

   4. Save the opmn.xml file.

   5. Force a reload of the opmn.xml file by running the following command from the $ORACLE_HOME/opmn/bin (for Microsoft Windows: %ORACLE_HOME%\opmn\bin) directory:

      % opmnctl reload
      
      

   6. Register the changes to Distributed Configuration Management using the following command:

      dcmctl updateconfig -ct opmn
      
      

5. Restart the Oracle Calendar server. For information on restarting the Oracle Calendar server, refer to Chapter 4 of the Oracle Calendar Administrator's Guide.