Child pages
  • CASifying Oracle Calendar web client with mod_cas
Skip to end of metadata
Go to start of metadata

Installing mod_cas to work with the Oracle Calendar web client.

The intention of this work is to enable single sign on between CASified services. In our case we wanted to achieve integration of our uPortal instance and the Oracle Calendar web client. This will allow you to login to the portal and click on a link to the Oracle Calendar web client without having to login to the Calendar separately.

This document only concerns the CASification of the Oracle Web Client and does not explain how to access the Calendar Server content so that its data can be displayed inside another application (i.e. a portlet). Accessing the Oracle Calendar server content for use in other applications will be the subject of another document.

Based on the following documentation:

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

mod_cas documentation from ESUP

and the responses to an Oracle Metalink enquiry that was made.

We are working with a standalone instance of Oracle Calendar with an Apache front end. If you are using a full Oracle Collaboration Suite installation then the instructions may differ slightly. I am assuming you will have a fully functioning installation of Oracle Calendar and its web client and that mod_cas is installed appropriately in your web clients Apache configuration.

Note: the sections below highlight the parts of the configuration files where changes are needed, they are NOT intended to be replacement files!

SERVER SIDE configuration

unison.ini is a calendar server engine configuration file.

Add web:CAL to the supported parameter in the [AUTHENTICATION] section (I believe web:OTMT might also work but it didn't for us). Add a shared password so that server and client sides trust each other.

ORACLE_HOME/ocal/misc/unison.ini

CLIENT SIDE configuration

The following are web server side web client configuration files. I don't actually know if you need all the web_* settings in both files but it works!

ORACLE_HOME/ocas/conf/ocas.conf
ORACLE_HOME/ocas/conf/ocwc.conf

Configure the "ocas-bin" section as you would any other web server location using mod_cas. As ocal.conf is read directly by the Apache server. Make sure the section is being read by the web server (i.e. it is not inside <IfModule mod_osso.c> section).

ORACLE_HOME/ocas/conf/ocal.conf
  • No labels

5 Comments

  1. Does this solution use a shared password for everyone? This would seem to render the client SW useless.

    1. The shared password is there so that the Calendar server engine (running on port ~5730) can know if it can trust the Calendar web client installation (running on a web server port). I expect a large number of people will have both the Calendar engine and Calendar web client installed on the same machine and view them as the a single system (but this does not have to be the case).

      The particular calendar schedule for a specific user is identified by the REMOTE_USER web server environment variable after you have successfully authenticated through mod_cas (or any other suitable Apache authentication module for that matter). Therefore a user will only see their own calendar.

      1. OK, so, users passwords would have to match the shared password yes? If so, they could not use the desktop client because the password would be shared and therefore not handed out by the calendar admin.

        Is there a way to tell Ora Cal that the user is authenticted? It seems that this solution is still running through Oracle's authentiation process even though CAS has already authenticated the user.

        1. No. Users passwords would not match the shared passwords. The shared password is just an internal mechanism used to enable trust between two internal components of the Oracle Calendar architecture (calendar engine and calendar web client).

          When a user logs in via mod_cas the REMOTE_USER environment variable is set to their userid on the Oracle Calendar web client server. Oracle Calendar uses the REMOTE_USER variable to determine whose Calendar to display.

          In configuring it in the above fashion we have configured Oracle Calendar to trust CAS for authentication rather than the method it would use by default.

  2. Followed your guide to easily enable SSO on our instance, using mod_shib (shibboleth) instead of mod_cas.  Thanks!