[cas-dev] PL/SQL Integration with CAS

[Scott Battaglia]

Steve and Marvin,

I'm moving this discussion to the developers list.  What do you guys think
of the possibilities of merging the Dartmouth and VT code bases for the
PL/SQL CAS clients and releasing them under the JA-SIG banner?

-Scott

On 1/30/07, Stephen A. Cochran <stephen.a.cochran at dartmouth.edu> wrote:
>
> 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
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20070131/7ad249c7/attachment.html