CAS in IdP v3

[Brian Biggs]

To follow up:

I created a new test CAS client that uses 
/idp/profile/cas/(login|serviceValidate) and everything works fine.

With any of my old CAS clients using /cas-server/(login|serviceValidate) 
I have jetty doing rewrites properly to /idp/profile/cas/ and I get the 
same re-auth behavior.

While examining the cookies that Shib is setting I see it setting 
"path=/idp" ... could this be why I'm getting the re-auth behavior?

Is there a way to change or remove the path in the shib cookie?

Thanks in advance
-Brian

On 02/02/2016 01:50 PM, Brian Biggs wrote:
> I think I may have isolated the problem down to rewrites in jetty.
> My apologies for not looking at this aspect of things sooner.
>
> Our old CAS urls are /cas-server/ and the new ones are 
> /idp/profile/cas/ (and I'm new to jetty too, so this one bit me) - 
> I'll follow up as soon as I've finished testing.
>
> Thank you again.
> -Brian
>
> On 02/02/2016 01:40 PM, Cantor, Scott wrote:
>>> That is unusual but it ought to work. If you're getting prompted for
>>> credentials each time you reach the IdP, then there's something 
>>> wrong with
>>> your IdP session. Since you appear to be operating in something like 
>>> stateless
>>> mode, I wonder if you have session cookies disabled in your browser. 
>>> That
>>> could cause what you're seeing.
>> No, stateful:
>> idp.session.StorageService = shibboleth.StorageService
>>
>> That's the in-memory variant. But there's still a session cookie of 
>> course, with the session ID in it.
>>
>> I guess there are the timeout and lifetime settings of various sorts, 
>> but you'd have to really do something weird to them to lose the 
>> session (or at least the authentication result in the session) after 
>> 5 minutes.
>>
>> -- Scott
>>
>

-- 

Brian Biggs
Sonoma State University