IdP's Session Cookie
Michael A Grady
mgrady at unicon.net
Thu Nov 1 19:55:02 EDT 2012
Since this problem isn't a problem with the Shib IdP itself, I just sent a reply to Richard directly about this problem, and that there are folks looking at it. If anyone else following the Shib Users list has a particular interest in my reply, let me know and I'll include you. And if you aren't already following the CAS Users list ( https://wiki.jasig.org/display/JSG/cas-user ), then subscribing would be a great idea -- I'll make sure there is a post there concerning this and a fix for it.
On Nov 1, 2012, at 4:56 PM, Caskey, Paul wrote:
> Sounds like the JSESSION thing Mike mentioned is remembering your identity when it shouldn't...
>> -----Original Message-----
>> From: users-bounces at shibboleth.net [mailto:users-
>> bounces at shibboleth.net] On Behalf Of Cantor, Scott
>> Sent: Thursday, November 01, 2012 4:51 PM
>> To: Shib Users
>> Subject: Re: IdP's Session Cookie
>>> 13:31:51.174 - DEBUG
>>> ste mLoginHandler:102] - Forwarding authentication request to
>>> 13:31:51.234 - DEBUG
>>> - Returning control to authentication engine
>> This means whatever your /authn/external thing is doing is at fault, not the
>>> 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
>>> 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
>> To unsubscribe from this list send an email to users-
>> unsubscribe at shibboleth.net
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.
More information about the users