Thanks Tom. I expected the CAS server session and am depending on it to control SSO session life.
But, I'm watching (with SAML Tracer) when the IDP redirects to CAS for a new ST. If it does not go to CAS then the CAS server session is not referenced. The issue appears to be the CAS client in the IDP. If I remove the JSESSIONID cookie for /idp then it will redirect to CAS for a ST as expected. I dpon't believe an IDP session is coming into play since I have the IDP set to only use CAS and it's redirecting to CAS as expected even if I leave the idp_session cookie. So, if it is a session in the IDP CAS client, how do I set the timeout for the CAS client session? Ted F. Fisher Information Technology Services -----Original Message----- From: Tom Poage [mailto:[email protected]] Sent: Thursday, August 07, 2014 1:03 PM To: [email protected] Subject: Re: [cas-user] CAS integration with Shibboleth IDP Maybe responses on the Shibboleth users list did not entirely explain the situation. If you delegate authN to CAS, you effectively end up with three, maybe four, sessions: CAS server and its container (CASTGC, JSESSIONID). CAS client on the Shibboleth IdP (e.g. mod_auth_cas) Shibboleth container (e.g. Tomcat, JSESSIONID) Shibboleth IdP (in memory, I think). I think you'll find in Shibboleth users archives discussions on the topic of reducing the IdP session timeout. Depending which CAS client you use, you'll want to reduce its session time. The Shibboleth container may or may not be a factor; YMMV. Tom. On Aug 7, 2014, at 9:32 AM, Ted Fisher <[email protected]> wrote: > I'll ask this question here to see if those familiar with CAS and Shibboleth > itegration can shed some light. I asked this in the Shib forum which > resulted in less clarity. > > We have our Shibboleth IDP using CAS as the only login handler resulting in > CAS being the manager of the SSO session and Shibboleth being simply a > pasthrough for SAML. Since the Shibboleth IDP does not maintain an SSO > session it should redirect to CAS for each auth request to get a new Service > Ticket. > > But, our IDP is not. After an initial ST it does not redirect to CAS but > continues to send SAML responses to auth requests. This indicates that > something somewhere is keeping a sense of a session - I would think in the > IDP. > > When I asked the question in the Shibboloeth forum and I said that the IDP > should go to CAS for a new ST for each auth request I got this response: > No, it shouldn't. Unless you turn off the CAS client's use of a local > session, assuming that's possible. Or I guess set the timeout very low. > That session is most likely the container's business, in which case that's > where you need to adjust the timeout. > > So, first question is does the CAS client keep some sense of a session that > would cause the IDP to handle an auth request without redirecting to CAS for > a new ST? > > The other or alternate question is how do we cause the IDP to redirect to the > CAS server for a new ST for each auth? If we want CAS to be the maintainer > of the SSO session then there is no other way for the IDP to determine if the > user has a valid session other than to get a new ST. Am I right? Is there a > reason why it should not work this way? > > Thanks. > > Ted F. Fisher > Information Technology Services > <image001.gif> > > -- > 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 -- 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 -- 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
