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 _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
