CAS in IdP v3

[Brian Biggs]

Thank you. I will examine the other side.

Most of our internal CAS clients do not use sessions and (I think) rely 
on the Ticket Granting Ticket (with an expire time of 30 minutes) to 
keep issuing new Service Tickets each time they are hit.

I take it this is not normal.

I'm really attempting to upgrade our setup from CAS v3.4.10 + Shib 
v2.2.1 to just Shib 3.2.1.

Thanks again for your help.
-Brian

All of our existing CAS clients don't use sessions afaik. We're 
currently using

On 02/02/2016 12:24 PM, Marvin Addison wrote:
>
>     However, when I go back to the same page that I got into, it sends
>     me back to authenticate again and I see:
>
>     2016-02-02 11:14:44,670 - DEBUG
>     [net.shibboleth.idp.cas.flow.impl.ValidateTicket Action:92] -
>     Attempting to validate ST-1454440484132NQj5toJoKOBk3ZSRFlAd3cQxm
>
> ...
>
>     2016-02-02 11:14:44,671 - INFO
>     [net.shibboleth.idp.cas.flow.impl.ValidateTicketAction:117] -
>     Successfully validated ST-1454440484132-NQj5toJoKOBk3ZSRFlAd3cQxm
>     for https://ldap-cgi2.dev.sonoma.edu/portal/index.cgi
>
>
> At this point the CAS protocol work is effectively done and a 
> successful service validation response ought to be returned to your 
> application that allows you access.
>
>     2016-02-02 11:14:45,212 - INFO [Shibboleth-Audit.SSO:241] -
>     20160202T191445Z||3bc14bcbe2cddd2a5d11079ec2cb352c0fd774e2f5e46729bbf03ba0faef7af0|https://ldap-cgi2.dev.sonoma.edu/portal/index.cgi|https://www.apereo.org/cas/protocol/serviceValidate||||biggsb|||biggsb|ST-1454440484132-NQj5toJoKOBk3ZSRFlAd3cQxm|
>
>
> Further evidence that all is well from the perspective of the IdP.
>
>     (BTW, it's a bit weird seeing
>     "https://www.apereo.org/cas/protocol/serviceValidate"
>     <https://www.apereo.org/cas/protocol/serviceValidate> in the logs
>     since i have no references to it...)
>
>
> That's just a protocol URI. It's not a URL to anything anywhere.
>
> At this point you ought to look more closely at your target 
> application's logs. It sounds like it's (a) not establishing an 
> application session and (b) may be configured for forced 
> authentication (renew=true), which would cause you to log in 
> regardless of an existing IdP session.
>
> M
>
>
>

-- 

Brian Biggs
Sonoma State University

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160202/2f543612/attachment.html>