PL/SQL Integration with CAS

[Stephen A. Cochran]

Dartmouth modified the yale client as well. It hasn't been released  
because I haven't gotten the DBA programmer to take out the Oracle  
wallet password code that's in there. Want it moved to a separate  
config file so the code is generic.

There are a few difficulties involved in using CAS with pl/sql. I've  
tried to outline them all below and our solutions:

1. Any URL that calls a pl/slq routine must have the right number of  
parameters or mod_plsql complains. Considering we had a very large  
deployed base of apps that weren't expecting a "ticket" parameter on  
the URL, this was a big problem.

Our solution was to strip off the ticket parameter before mod_plsql  
was invoked. There are two ways to do this. We happen to be using an  
F5 load balancer in front of the mod_plsql apps, and it was already  
offloading all the SSL stuff. We simply had it strip out any ticket  
parameter as well. (We're hoping no app happens to use that parameter  
name, might be nice if that's configurable somewhere, but it means  
configurable in every client too). The param is then passed in the ENV.

A second solution is a simple apache module I wrote that is called  
before mod_plsql. It strips off the ticket param and sets an ENV  
variable with the info. Works just as well.

2. Form submission via posts is still a problem. If a redirect  
happens on a POST, the submitted data is lost. To solve this in a  
central way for all pl/sql apps, we had our CAS procedure (called  
authenticate) create a "session" once the user is verified via cas.  
This session is maintained using a cookie with the username, IP,  
timestamp, and a secret password encrypted into the cookie.

The flow is as follows. A request comes into a pl/slq app. It calls  
the authenticate procedure. If the user has not been authenticated,  
it redirects them to the CAS server and returns a "NO_AUTH" code to  
the calling procedure.

When the user is redirected back to the same service with a ticket  
this time, the ticket would be put in the ENV, and the app would  
again call authenticate. Authenticate would see the ticket, verify  
the user, and then set the cookie. It would then return the username  
to the calling procedure.

Any future calls to authenticate (from ANY pl/sql app, remember, this  
is a central routine now) will be verified using the session cookie,  
assuming the timeout limit hasn't been reached. The username is  
pulled out of the cookie and returned to the calling app.

A presentation on the design and integration is available at the  
below link:

<http://dev.dartmouth.edu/files/softdev/webAuth/authenticate_v3/ 
index.html>

Some of the details in that are very Dartmouth specific, history of  
the previous authenticate functions etc, but there's a good overview  
in there as well.

Once we stop bleeding people I'm hoping to get the pl/sql and updated  
mod_cas apache modules back to the community.

Steve Cochran
Manager, Special Projects