IdP's Session Cookie

[Cantor, Scott]

>13:31:51.174 - DEBUG
>[edu.internet2.middleware.shibboleth.idp.authn.provider.ExternalAuthnSyste
>mLoginHandler:102] - Forwarding authentication request to /authn/external
>13:31:51.234 - DEBUG
>[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:144]
>- Returning control to authentication engine

This means whatever your /authn/external thing is doing is at fault, not
the IdP.

>I looks like it sends it to the External Auth, but I don't see anything
>happen on the CAS side.  CAS is logged out so it appears this would
>create a login screen if it really contacted CAS (either 302 redirect or
>as a result of the user not being signed
> in).

The timestamps are so close that it seems apparent to me that whatever's
at /authn/external is already aware of your identity and needs no help
from CAS.

>What is confusing above is that it says "No session associated with
>session ID..." then returns to "auth engine" not sure if this is Shib or
>CAS, then "Completing user authentication process" then it validates it
>as successful?

The session ID thing is just logging from the filter that extracts IdP
session stuff, and it's seeing a cookie with the session key in it, but no
session for that value.

The rest is clearly evidence that your code at /authn/external thinks it
knows the user's identity.

>I don't understand how
> this could happen unless it's checking with itself for authentication...
>How can I kill the Shib session and make it check with CAS everytime for
>a valid auth?

That's not the Shib session at fault, it's your code at /authn/external.

-- Scott