Hi, Phil Ames wrote: > Hi, > Responses are in-line below. > > On Mon, Sep 28, 2009 at 9:28 AM, Nicolas Boullis <[email protected]> > wrote: > [...] >> 2) The CASScope option does not work if there is also a CASGateway (or a >> CASRenew) option. Reading the code, I think the login in the getCASScope >> function is wrong, and CASGateway (or CASRenew) should only be >> considered for the cookie's path if the requested path is below >> CASGateway (or CASRenew). > > This sounds like a legitimate issue, I will look into this.
Do you want me to send you my (trivial) patch? >> 3) The server where mod_auth_cas is used is hidden behind another server >> that serves as a reverse proxy. Then mod_auth_cas redirects to the real >> server, which is firewalled. I added a new "CASRootProxiedAs" option to >> mod_auth_cas, to make mod_auth_cas redirect to (and request tickets for) >> the frontend server. > > This seems to be a rather hot request as of late. I would like to get > some feedback from the user base on how typical deployment scenarios > are and how they would like this feature implemented. The manner in > which the service URL is constructed is critical in ensuring access to > mod_auth_cas protected resources. One method I can think of supports > a scenario like this: > > USER -> www.example.com:443 -> internal.example.com:8080 In my situation, this would be: USER -> http://www.example.com/foo/index.html -> http://internal.example.com:8001/index.html > I think there might need to be 3 directives to appropriately handle > this case: one to override the hostname (e.g. > CASOverrideServiceHostname www.example.com), one to define whether the > port should be printed(e.g. CASPrintServicePort Off/On/Default), and > one to define the scheme (CASServiceScheme "https"). Why so many options? With my patch, I set CASRootProxiedAs http://www.example.com/foo and when I have to construct the URL, I prepend the content of the CASRootProxiedAs option to the requested path, instead of constructing the URL with the scheme, hostname (and port). > This breaks down, however, if the paths are not identical between the > proxied hosts. For instance, say that you proxy > https://www.example.com/ to http://internal.example.com/app. > mod_auth_cas would append that /app/ to the service URL. A fourth > directive might be appropriate here (CASReverseProxyPrefix /app/) that > would strip /app/ from the URI so the proxying would be transparent. I thought about this one as well, but did not implement it as I didn't need it (lazy me!). > I would appreciate any feedback or suggestions on this, since these > are pretty off-the-cuff thoughts on how to go about implementing this > (which people have been clamoring about for some time -- sorry!). Do you want to see how I implemented this for my own use? Regards, -- Nicolas Boullis Ecole Centrale Paris -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
