[Ted Fisher]

I don't believe that the CAS client keeps any sense of a session; but that's a question for the CAS forum which I'll take up there.
The CAS client is nothing like a SP in the sense of managing a session.  I believe it is merely a  very basic means to structure a message to the CAS server which is managing the SSO session.  
The point in terms of the IDP though is that your saying that the IDP is not maintaining a session still.  If I have the PreviousSession handler commented I shouldn't see the IDP attempting to keep any sense of an SSO session.  If that is correct then I just have to figure out who or what is doing so.

Thanks.

Ted F. Fisher
Information Technology Services


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, August 07, 2014 11:02 AM
To: Shib Users
Subject: Re: 

On 8/7/14, 10:26 AM, "Ted Fisher" <tffishe at bgsu.edu> wrote:

>Right - the CAS means of maintaining the session uses the Ticket 
>Granting cookie; but each auth request to CAS does generate a new Service Ticket.

Each *auth* request, not every application request. The IdP is an application.

>Since the IDP is another SSO which is using CAS as its auth source then 
>it should be that each IDP auth request should generate a new CAS ST.

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.

>  The IDp has no other way of knowing if the CAS SSO session is still 
>valid.  That's what I want is for the IDP to check with CAS at each 
>auth to see if the CAS SSO session is still active.

Then tell CAS not to maintain a local session, or reduce its timeout. But that is *not* the normal way of integrating them.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net