CAS in IdP v3

[Marvin Addison]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160202/eb314051/attachment.html>