Hi Phil, One more related question/verification: This all may have partly stemmed from our client's request that our application provide a logout link that directs the user back to their CAS logout portal. The only way we could find that to work was to use the trunk version of mod_auth_cas.
Now that I have CASScope directive that fixes the POST error situation, the Single Sign Out functionality no longer works. Again reading your documentation, I see: "* CAS single sign out is currently not functional and disabled. It is only safe to use in the case where all requests are GET and not POST (the module inadvertently 'eats' some content of the POST request while determining if it should process it as a SAML logout request)." So...it seems like we can have one or the other? I'm watching the cookie directory as I test sessions, and now only see one cookie per session (I noticed before multiple cookies, related to the multiple paths that resulted in the POST errrors). I'm not sure if I fully understand the single sign out cannot work, but is it safe to say that we can design our application to delete that session cookie from /var/cache/cas when a user selects our logout link, effectively closing the session until they sign in again via their CAS portal? (I've explained to our client that I believe that if a user signs out of their CAS via their own portal and not via our application logout, they will still have an open session with our application since we have no way of knowing that they signed out.) Does this all sound correct? Thanks again, DW On Tue, Mar 8, 2011 at 4:49 PM, Duane Winner <[email protected]> wrote: > Phil, > > Thanks for putting on the right trail -- I think I have it figured out > -- when exploring cookies in the browser, we discovered that our > application was generating more than one cookie, for each URL. > > Example: one cookie for foo.com/app/mydepartment/, another cookie for > foo.com/app/search/ another one for foo.com/app/wildcard/....etc. > > So I looked at your README again, and see that there is a CASScope > directive that can be used. > > I added CASScope /app/ in the <Files> section that requires CAS auth, > and initial tests show this to work. > > Thanks! > DW > > > > On Tue, Mar 8, 2011 at 4:14 PM, Phil Ames <[email protected]> wrote: > > The very first request in your logs doesn't have a MOD_AUTH_CAS_S cookie > > because the user has not made a round trip to the CAS server, received a > > ticket, and been issued a MOD_AUTH_CAS_S cookie by mod_auth_cas itself. > > Because there is no MOD_AUTH_CAS_S cookie, mod_auth_cas treats this as an > > unauthenticated request, and redirects the user to the CAS server for > > authentication. You can see that when it comes back from the CAS server, > > there is a "Set-Cookie: MOD_AUTH_CAS_S=[...]" header in the reply. > > Unfortunately, due to the way that mod_auth_cas and HTTP work, the way > this > > redirection to and back from the CAS server is accomplished uses HTTP > 302, > > which results in a GET request, thereby converting the HTTP verb from > POST > > to GET. > > > > If I had to venture a guess, it would be that whatever page you visit > which > > contains the <form> tag to POST to the authenticated URL is available > > without authentication. > > Does that help clarify why this is behaving this way? > > -Phil > > On Tue, Mar 8, 2011 at 4:05 PM, Duane Winner <[email protected]> > wrote: > >> > >> Hi Phil, > >> > >> I'm still not clear about this; Why isn't there a MOD_AUTH_CAS_S cookie? > >> > >> I do have CASCookiePath /tmp/cas/ directive and can see the cookies > >> being cached on the server, and there are no issues with GETS and > >> navigating the webapp after a user is logged on, it's just that first > >> POST that wants to validate again against the client's CAS server? I > >> should also note that after that first POST generates the application > >> error, the user can hit back page, submit again, and then it's fine. > >> > >> You state that "For this to work as you expect, your users will need > >> to log in via CAS before submitting POST requests to the > >> application.", but that is what we are doing -- I only submitted the > >> headers and logs for the POST action, not the entire session. The > >> entire application requires CAS authentication, and there are no > >> issues navigating the application or GETS, it's just the first POST. > >> > >> Am I still missing an apache directive? > >> > >> Thanks, > >> DW > >> > >> > >> > >> On Tue, Mar 8, 2011 at 3:19 PM, Phil Ames <[email protected]> wrote: > >> > In the first request, there is no MOD_AUTH_CAS_S cookie. This is what > >> > results in the user being redirected to the CAS server. The CAS > server > >> > redirects it back to the supplied service URL (this is a GET request), > >> > which > >> > is why the POST data is lost. This is essentially the same as > supplying > >> > an > >> > invalid (read: expired) MOD_AUTH_CAS_S cookie. > >> > For this to work as you expect, your users will need to log in via CAS > >> > before submitting POST requests to the application. Alternatively, > >> > since > >> > all the parameters are being passed in the query string anyway, you > >> > could > >> > modify the application to run the appropriate search (I'm guessing > >> > that's > >> > what it's doing) in the GET handler instead of POST. > >> > -Phil > >> > > >> > On Tue, Mar 8, 2011 at 3:10 PM, Duane Winner <[email protected]> > >> > wrote: > >> >> > >> >> Got it. > >> >> > >> >> Anything in particular I should be looking for in the logs specific > to > >> >> CAS? I'm not sure what I'm looking for at this point, but I have > >> >> captured the submit transactions that generates the application error > >> >> in the apache logs. I've also captured the http headers in the > >> >> browser. I can attach them if it something that would help. > >> >> > >> >> Thanks, > >> >> DW > >> >> > >> >> > >> >> On Tue, Mar 8, 2011 at 2:25 PM, Phil Ames <[email protected]> > wrote: > >> >> > Please make sure the VirtualHost has LogLevel debug. > >> >> > > >> >> > On Tue, Mar 8, 2011 at 2:24 PM, Duane Winner <[email protected] > > > >> >> > wrote: > >> >> >> > >> >> >> I just added the CASDebug On directive a few minutes ago > >> >> >> > >> >> >> -- where should I see debugging output? I'm looking in the apache > >> >> >> logs > >> >> >> and not seeing anything additional > >> >> >> > >> >> >> On Tue, Mar 8, 2011 at 2:20 PM, Phil Ames <[email protected]> > >> >> >> wrote: > >> >> >> > No, those are the timeouts I'm referring to. Do you have HTTP > >> >> >> > traces > >> >> >> > of > >> >> >> > when this problem occurs, as well as CASDebug On/LogLevel debug > >> >> >> > logs? > >> >> >> > -Phil > >> >> >> > > >> >> >> > On Tue, Mar 8, 2011 at 1:56 PM, Duane Winner > >> >> >> > <[email protected]> > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> Thanks for the reply. > >> >> >> >> > >> >> >> >> I'm not specifying either of these as an apache directive, but > >> >> >> >> according to the README, the defaults are way beyond the window > >> >> >> >> in > >> >> >> >> which I've tested this and replicated the error (under 5 > >> >> >> >> minutes). > >> >> >> >> > >> >> >> >> Directive: CASTimeout > >> >> >> >> Default: 7200 (2 hours) > >> >> >> >> Directive: CASIdleTimeout > >> >> >> >> Default: 3600 (1 hour) > >> >> >> >> > >> >> >> >> Or are you referring to something else I should be looking at? > >> >> >> >> > >> >> >> >> Thanks again, > >> >> >> >> -DW > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> On Tue, Mar 8, 2011 at 1:49 PM, Phil Ames < > [email protected]> > >> >> >> >> wrote: > >> >> >> >> > It's possible that the user's mod_auth_cas session has > expired, > >> >> >> >> > and > >> >> >> >> > they > >> >> >> >> > were redirected to the CAS server to obtain a new ticket. > This > >> >> >> >> > redirect > >> >> >> >> > causes the loss of the POST data, and results in an HTTP GET > >> >> >> >> > when > >> >> >> >> > the > >> >> >> >> > CAS > >> >> >> >> > server redirects the user to the service URL. > >> >> >> >> > -Phil > >> >> >> >> > > >> >> >> >> > On Tue, Mar 8, 2011 at 12:58 PM, DW <[email protected]> > >> >> >> >> > wrote: > >> >> >> >> >> > >> >> >> >> >> Hello, we host a web-based application, and a client of ours > >> >> >> >> >> has > >> >> >> >> >> a > >> >> >> >> >> CAS > >> >> >> >> >> server so we installed mod_auth_cas when the asked for > >> >> >> >> >> Single-Sign-On. > >> >> >> >> >> > >> >> >> >> >> I compiled and installed mod_auth_cas-1.0.8.1 on apache 2.2, > >> >> >> >> >> and > >> >> >> >> >> it > >> >> >> >> >> works > >> >> >> >> >> for the most part, but we are running into issues where we > >> >> >> >> >> have a > >> >> >> >> >> submission > >> >> >> >> >> form and when submitted our application generates an error. > A > >> >> >> >> >> trace > >> >> >> >> >> shows > >> >> >> >> >> that what should have been a POST was converted to a GET. If > >> >> >> >> >> we > >> >> >> >> >> turn > >> >> >> >> >> off > >> >> >> >> >> CAS/SSO, then everything works fine. > >> >> >> >> >> > >> >> >> >> >> Can any provide any insight? > >> >> >> >> >> > >> >> >> >> >> global: > >> >> >> >> >> LoadModule auth_cas_module > >> >> >> >> >> /usr/local/apache/modules/mod_auth_cas.so > >> >> >> >> >> CASCookiePath /tmp/cas/ > >> >> >> >> >> > >> >> >> >> >> In virtualhost section: > >> >> >> >> >> CASLoginURL https://foo.com/cas/login?view=showx > >> >> >> >> >> CASValidateURL https://foo.com/cas/serviceValidate > >> >> >> >> >> CASCertificatePath > >> >> >> >> >> /home/vhosts/bar/profile/ssl/gd_bundle.certificate > >> >> >> >> >> CASValidateServer Off > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> Thanks, > >> >> >> >> >> DW > >> >> >> >> >> -- > >> >> >> >> >> You are currently subscribed to [email protected]: > >> >> >> >> >> [email protected] > >> >> >> >> >> To unsubscribe, change settings or access archives, see > >> >> >> >> >> http://www.ja-sig.org/wiki/display/JSG/cas-user > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > > > -- 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
