I think we've all already told you this, but once the application validates the CAS ticket it has no more contact with CAS. Its on its own to manage the user session.
Cheers, Scott On Thu, May 14, 2009 at 12:55 PM, rrakesh <[email protected]> wrote: > > > Thanks for the comments. > > I got a basic questions to ask. I am using spring cas client 2.0.4. And CAS > server 3.3.1. > > After initial authentication of the user trying to accessing the secure > page, what happens on the subsequent access of the secure page. Does the > cas > client (fitlers) contact CAS server every time the user accessing the > secure > pages (assuming the user logged in to the app successfully at the first > time). > > The reason for asking this question is: > 1. How would the cas client application knows about the ticket expiration, > if the client does not double check with the cas server on every secure > page > request. > 2. Every one talks about intial flow/sequence of steps happening between > CAS > Server and the Cassified application but what happens after that. > > I was trying to debug the code, but as per the code it seems like based the > Authentication token stored in the security context if it is a instance of > casauthenticationtoken then secured page is served. > > Is this right? > > Thanks > RR > > > scott_battaglia wrote: > > > > CAS sessions work as follows: > > > > When you first authenticate to an application, CAS creates a single sign > > on > > session for you. This allows you to seamlessly authenticate to other > > applications without re-entering credentials. > > > > These sessions have an expiration policy, generally something like 6 > > hours. > > At the end of the 6 hours, you would need to re-enter your credentials. > > > > We also offer SLO, when you explicitly log out of the CAS server (so > going > > to /logout). Our recommendation has always been to have your > applications > > logout page let the user know they have logged out the application and > how > > they can log out of all applications. > > > > We do not send logout requests if the SSO session expires. There's a few > > technical reasons why we haven't done it yet but there's also the issue > of > > application independence from SSO session. If your SSO session is only 6 > > hours but you've been using an application for six hours and one minute, > > there is no reason you should have to reauthenticate to that application. > > > > Cheers, > > Scott > > > > > > On Tue, May 12, 2009 at 10:21 AM, Lucas Rockwell <[email protected]> > wrote: > > > >> On May 12, 2009, at 12:33 PM, rrakesh wrote: > >> > >>> > >>> Thanks for posting your thoughts and answers to the questions. > >>> > >>> Isn't the ticket expiration should work the same way as Single Sing > Out, > >>> meaning cas-server sends message back to the services with > >>> "logoutrequest", > >>> right. > >>> > >>> But I am not seeing it on the CAS-SERVER side logs. > >>> > >>> > >>> Or May be I misunderstood the way the ticket expiration works. > >>> > >> > >> From what I understand, the single sign out part has nothing to do with > >> the > >> time limit on the TGT. In order to invoke single sign out, you actually > >> have > >> to go to the /logout URL using the browser that has the CASTGC (or > >> present > >> the TGT via the web service). > >> > >> The time limit of the TGT just keeps new STs from being granted using > >> that > >> TGT if the time limit is expired. > >> > >> -lucas > >> > >> Johan Reinalda wrote: > >>> > >>>> > >>>> If I understand what you're saying, then this is not a CAS problem, > but > >>>> the > >>>> behaviour of your APP1. > >>>> It has it's own 'session', probably a browser cookie, that needs to > >>>> time > >>>> out > >>>> before it will ask you to login again (and than direct you to the cas > >>>> login > >>>> page.) > >>>> > >>>> Simply leaving the APP1 page and coming back doesn't seem to do that > >>>> (unless > >>>> you add some mechanism to force logout upon leaving the site.) > >>>> > >>>> Johan > >>>> > >>>> ----- Original Message ----- > >>>> From: "rrakesh" <[email protected]> > >>>> To: <[email protected]> > >>>> Sent: Tuesday, May 12, 2009 10:29 AM > >>>> Subject: [cas-user] Setting grantingTicketExpirationPolicy, does not > >>>> expire > >>>> the session > >>>> > >>>> > >>>> > >>>>> > >>>>> I got two applications App1 and App2 which are casified. Login in one > >>>>> application does sso into other application and the same thing with > >>>>> the > >>>>> sign > >>>>> out functionality, logging out of APP1 or APP2 logs me out from the > >>>>> other > >>>>> application APP2 or APP1 respectively. > >>>>> > >>>>> Now I am trying to configure the "grantingTicketExpirationPolicy" the > >>>>> bean > >>>>> declared in "ticketExpirationPolicies.xml" to 5 seconds. And after > >>>>> log-in > >>>>> in > >>>>> APP1 and sitting on a secured page for a while and trying to > accessing > >>>>> the > >>>>> APP2 secured page shows me log-in page. But at the same if I can > >>>>> travel > >>>>> back > >>>>> tot my APP1 secured page which does not show me log-in page instead > it > >>>>> gives > >>>>> me access to the secured page. > >>>>> > >>>>> Am I missing some thing here form the configuration point while > >>>>> setting > >>>>> the > >>>>> expiration, the reason becase Single Sign out works file between two > >>>>> applications and CAS server. > >>>>> > >>>>> Thanks > >>>>> RR > >>>>> -- > >>>>> View this message in context: > >>>>> > >>>>> > http://www.nabble.com/Setting-grantingTicketExpirationPolicy%2C-does-not-expire-the-session-tp23506700p23506700.html > >>>>> Sent from the CAS Users mailing list archive at Nabble.com. > >>>>> > >>>>> > >>>>> -- > >>>>> 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 > >>>> > >>>> > >>>> > >>> -- > >>> View this message in context: > >>> > http://www.nabble.com/Setting-grantingTicketExpirationPolicy%2C-does-not-expire-the-session-tp23506700p23508914.html > >>> Sent from the CAS Users mailing list archive at Nabble.com. > >>> > >>> > >>> -- > >>> 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 > > > > -- > View this message in context: > http://www.nabble.com/Setting-grantingTicketExpirationPolicy%2C-does-not-expire-the-session-tp23506700p23544651.html > Sent from the CAS Users mailing list archive at Nabble.com. > > > -- > 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
