IdP's Session Cookie

Thu Nov 1 17:08:25 EDT 2012

Hi -- sorry to piggyback off this thread, but I think my question is
related.

First, I'm using this setup:  CAS + Shib + shib-cas-authenticator.  CAS is
using ActiveDirectory to authenticate users.  I'm using IdP unsolicited
initialization to log in to Concur (which requires that login request begin
at the IdP).

I can login to Concur fine using this set up.  When I log out of Concur, it
logs me out there and forwards me to my cas/logout (per my instruction).
 Shibboleth seems to keep its session going (because it doesn't know
anything about the user being logged out at CAS).

I want Shibboleth to basically NOT keep a session and to ask CAS about the
user being logged in every time.  This way, CAS will control the login time
(as far as Shib and CAS are concerned).  In a nutshell, here's what I've
done to try to make that happen:

shib conf/handler.xml
<ph:LoginHandler xsi:type="ph:ExternalAuthn"
                     externalAuthnPath="/authn/external"
                     authenticationDuration="1"
                     supportsForcedAuthentication="true" >

<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>

(notice:  authenticationDuration)

Commented out the Previous Session:
    <!--
    <ph:LoginHandler xsi:type="ph:PreviousSession">

<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</ph:AuthenticationMethod>
    </ph:LoginHandler>
    -->

shib conf/internal.xml
Shortened the Session time (or at least that's what I thought I was doing).

    <bean id="shibboleth.SessionManager"
class="edu.internet2.middleware.shibboleth.idp.session.impl.SessionManagerImpl"
depends-on="shibboleth.LogbackLogging">
        <constructor-arg ref="shibboleth.StorageService"/>
        <constructor-arg value="60000" type="long"/>
        <!--
        <constructor-arg value="1800000" type="long"/>
        -->
    </bean>

When I look at the log on a reattempt to log in through IdP Unsolicited
SSO, I have these interesting lines:

13:31:51.139 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:224]
- Creating login context and transferring control to authentication engine
13:31:51.140 - DEBUG
[edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:167] -
Storing LoginContext to StorageService partition loginContexts, key
e1d7af0f-c57d-47f6-8156-aa55f227aa14
13:31:51.140 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:237]
- Redirecting user to authentication engine at
https://idp.HIDDEN.com:443/idp/AuthnEngine
13:31:51.172 - DEBUG
[edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:160] - No
session associated with session ID
ZGU1MjRmZTdiNWM4ZWZkNWQwYzY5MzI4YzRmY2MyMjQ3OWNiNDk3ZGNhZTQ2OWJkNDdmOTM0MjgzYzk5ZGZiNQ==
- session must have timed out
13:31:51.173 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:209] -
Processing incoming request
13:31:51.173 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:240] -
Beginning user authentication process.
13:31:51.173 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:283] -
Filtering configured LoginHandlers:
{urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.ExternalAuthnSystemLoginHandler at 75ad2db5
}
13:31:51.173 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:464] -
Selecting appropriate login handler from filtered set
{urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.ExternalAuthnSystemLoginHandler at 75ad2db5
}
13:31:51.174 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:497] -
Authenticating user with login handler of type
edu.internet2.middleware.shibboleth.idp.authn.provider.ExternalAuthnSystemLoginHandler
13:31:51.174 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.provider.ExternalAuthnSystemLoginHandler:102]
- Forwarding authentication request to /authn/external
13:31:51.234 - DEBUG
[edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:160] - No
session associated with session ID
ZGU1MjRmZTdiNWM4ZWZkNWQwYzY5MzI4YzRmY2MyMjQ3OWNiNDk3ZGNhZTQ2OWJkNDdmOTM0MjgzYzk5ZGZiNQ==
- session must have timed out
13:31:51.234 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:144] -
Returning control to authentication engine
13:31:51.234 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:209] -
Processing incoming request
13:31:51.235 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:514] -
Completing user authentication process
13:31:51.235 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:585] -
Validating authentication was performed successfully
13:31:51.235 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:696] -
Updating session information for principal Richard.Navarrete at HIDDEN.com
13:31:51.235 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:700] -
Creating shibboleth session for principal Richard.Navarrete at HIDDEN.com
13:31:51.236 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:806] -
Adding IdP session cookie to HTTP response

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).

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?  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?

Thanks in advance!
R

-----Original Message-----

From: users-bounces at shibboleth.net
[mailto:users-bounces at shibboleth.net<users-bounces at shibboleth.net>]
On

Behalf Of Michael A Grady

Sent: Thursday, November 01, 2012 10:26 AM

To: Shib Users

Subject: Re: IdP's Session Cookie

On Nov 1, 2012, at 9:02 AM, Cantor, Scott wrote:

On 11/1/12 9:14 AM, "Paul Hethmon" <paul.hethmon at clareitysecurity.com>

wrote:

I'm pretty sure that session cookie is set regardless of the

PreviousSession handler being there or not. Even if session time is

set to 0, I think it gets set. It's just immediately invalid.

Yes, the handler has nothing to do with the cookie being set.

Thanks.

Looks like the cookie causing problems (causing a user to be "remembered"

when such isn't desired) is a JSESSIONID cookie, scoped to the External

Authentication handler path. (The External Authn handler is what is being

used in this case.) I am correct in my reading of the documentation that the

authenticationDuration setting for a handler isn't supposed to matter if the

PreviousSession handler is not activated -- is that indeed correct?

https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthnSession

Which would presumably put the External Authn "trigger code"

(filter/servlet) at fault for this cookie and its use.

-- Scott

--

Michael A. Grady

Senior IAM Consultant, Unicon, Inc.

--

To unsubscribe from this list send an email to

users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20121101/aedc23dd/attachment.html 