[Shib-Users] Looping Problem

Paul Hethmon

unread,

Nov 30, 2008, 8:28:18 PM11/30/08

to Shibboleth Users

I¹ve been trying to set up a simple test case using Shibboleth 2 Idp and SP.
The Idp is running on Tomcat 5.5 while the SP is on IIS 6.0. In my last
test case, I¹m running both on the same Win2003 box, though I¹ve gotten the
same behavior running the Idp on my MacBook. I have tested both the Idp and
SP successfully against the TestShib site, so I feel the basic setup is ok.
When I run against my Idp and SP on the box though, I end up in the endless
redirect loop as the SP never recognizes the response from the Idp. Firefox
3 is the browser I¹m using (though Safari also did the same thing).

Here¹s the setup:

Tomcat listening on 192.168.0.4 (SSL) local hosts file name of
hethmon.gotdns.com
IIS 6 listening on 192.168.0.50 (SSL) local hosts file name of
w50.hethmon.net
Shib Daemon on port 1600

The Shib Daemon can retrieve the Idp metadata successfully.

Here¹s a relevant snippet of the shibd.log file:

-----
2008-11-30 19:12:53 INFO Shibboleth.Listener : listener service starting
2008-11-30 19:13:43 DEBUG Shibboleth.Listener [1]: dispatching message
(default::getHeaders::Application)
2008-11-30 19:13:43 DEBUG Shibboleth.Listener [1]: dispatching message
(default/Login::run::SAML2SI)
2008-11-30 19:13:43 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
validating input
2008-11-30 19:13:43 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
marshalling, deflating, base64-encoding the message
2008-11-30 19:13:43 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
marshalled message:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://w50.hethmon.net/Shibboleth.sso/SAML2/PO
ST" Destination="https://hethmon.gotdns.com/idp/profile/SAML2/Redirect/SSO"
ID="_8e4921c528f77061bee0318c8ac7437f" IssueInstant="2008-12-01T00:13:43Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"><saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://w50.hethmon.net/s
hibboleth-sp</saml:Issuer><samlp:NameIDPolicy
AllowCreate="1"/></samlp:AuthnRequest>
2008-11-30 19:13:43 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: message
encoded, sending redirect to client
2008-11-30 19:13:50 DEBUG Shibboleth.Listener [1]: dispatching message
(default/Login::run::SAML2SI)
2008-11-30 19:13:50 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
validating input
2008-11-30 19:13:50 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
marshalling, deflating, base64-encoding the message
2008-11-30 19:13:50 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
marshalled message:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://w50.hethmon.net/Shibboleth.sso/SAML2/PO
ST" Destination="https://hethmon.gotdns.com/idp/profile/SAML2/Redirect/SSO"
ID="_adee7d8cbdf57dca176d21885be3851a" IssueInstant="2008-12-01T00:13:50Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"><saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://w50.hethmon.net/s
hibboleth-sp</saml:Issuer><samlp:NameIDPolicy
AllowCreate="1"/></samlp:AuthnRequest>
2008-11-30 19:13:50 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: message
encoded, sending redirect to client
2008-11-30 19:13:50 DEBUG Shibboleth.Listener [1]: dispatching message
(default/Login::run::SAML2SI)
-----

On the Idp side, I get this:

-----
19:13:49.931 - INFO [Shibboleth-Access:72] -
20081201T001349Z|192.168.0.4|hethmon.gotdns.com:443|/profile/SAML2/Redirect/
SSO|
19:13:50.635 - INFO [Shibboleth-Audit:901] -
20081201T001350Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_8e4921c
528f77061bee0318c8ac7437f|https://w50.hethmon.net/shibboleth-sp|urn:mace:shi
bboleth:2.0:profiles:saml2:sso|https://hethmon.gotdns.com/idp/shibboleth|urn
:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_4b104bb20ed47ccbf21bdc7e44b2683
6|acme|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||_6
d6ea6f556bfade353610a569ef2baf6|_e279eea159520aee55b3e37b736e4961,|
19:13:50.681 - INFO [Shibboleth-Access:72] -
20081201T001350Z|192.168.0.4|hethmon.gotdns.com:443|/profile/SAML2/Redirect/
SSO|
19:13:50.697 - ERROR
[edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLogin
Handler:111] - Using existing IdP session for acme
19:13:50.697 - INFO [Shibboleth-Access:72] -
20081201T001350Z|192.168.0.4|hethmon.gotdns.com:443|/profile/SAML2/Redirect/
SSO|
19:13:50.806 - INFO [Shibboleth-Audit:901] -
20081201T001350Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_adee7d8
cbdf57dca176d21885be3851a|https://w50.hethmon.net/shibboleth-sp|urn:mace:shi
bboleth:2.0:profiles:saml2:sso|https://hethmon.gotdns.com/idp/shibboleth|urn
:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_5d28b3aa22ccae965be190007b1f68b
b|acme|urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession||_6d6ea6f556bf
ade353610a569ef2baf6|_91e5211e0f75e6ce3919d4092e34147a,|
-----

So it shows the Idp recognizing the existing session and reusing it (and
giving me my very nice endless redirect loop). At the risk of putting in too
little, here is what I think is the relevant section of the shibboleth2.xml
file on the SP side of things:

<InProcess logger="c:/opt/shibboleth-sp/etc/shibboleth/native.logger">
<ISAPI normalizeRequest="true">

<Site id="1" name="w50.hethmon.net"/>
</ISAPI>
</InProcess>

<TCPListener address="127.0.0.1" port="1600" acl="127.0.0.1"/>


<StorageService type="Memory" id="mem" cleanupInterval="900"/>
<SessionCache type="StorageService" StorageService="mem"
cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
<ReplayCache StorageService="mem"/>
<ArtifactMap artifactTTL="180"/>

<RequestMapper type="Native">
<RequestMap applicationId="default">
<Host name="w50.hethmon.net">
<Path name="Customers"
authType="shibboleth"
requireSession="true"/>
</Host>
</RequestMap>
</RequestMapper>

I¹ve removed all the comments, etc to keep the size down. In my googling,
I¹ve found several different ways of setting up the shibboleth2.xml file.
This basic form was taken from the switch.ch web app and then modified to
use my Idp. I have also tried a generated version from the usc.edu website
which leaves the ApplicationDefaults alone and adds an ApplicationOverride
section instead. Do I need the cookieProps attribute here in the config? I
had it with the ApplicationOverride section, though my fiddling with its
value did not help.

If anyone can point me in a direction to look. My next step is to completely
turn off all SSL and run the session through tcpmon and/or wireshark so I
can get hopefully see what the cookies are doing.

Thanks,

Paul

-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

Give a man a fire and he's warm for the day. But set fire to him and he's
warm for the rest of his life.

-- Terry Pratchett, Discworld

Scott Cantor

unread,

Nov 30, 2008, 8:42:37 PM11/30/08

to shibbole...@internet2.edu

> When I run against my Idp and SP on the box though, I end up in the
endless
> redirect loop as the SP never recognizes the response from the Idp.
Firefox
> 3 is the browser I¹m using (though Safari also did the same thing).

If it wasn't recognizing it, you couldn't be looping, it would have stopped
with an error.

> Here¹s a relevant snippet of the shibd.log file:

Frankly, I can't imagine any scenario like that. It doesn't show a session
being created, as though the POST never even ends up at the SP, so I can't
understand how it can possibly loop.

> If anyone can point me in a direction to look. My next step is to
completely
> turn off all SSL and run the session through tcpmon and/or wireshark so I
> can get hopefully see what the cookies are doing.

That is always step 1 with looping. There's no point even doing the work you
already did, it's a waste of effort. Loops are cookie problems by
definition, resulting from misconfiguration of server names or cookie
properties.

But it can't result in the SP log you posted. Just isn't possible. A loop
can only occur if the SP accepts the response, creates a session, sends you
to the original URL, and then starts it all over again because the cookie
isn't correctly sent. Without the parts in the middle, there can't a loop.

-- Scott

Paul Hethmon

unread,

Nov 30, 2008, 10:39:50 PM11/30/08

to Shibboleth Users

Ok. Weird as hell time here.

I moved the Idp to my Macbook, left the SP on the Win2003 box. Ran Wireshark on both, no SSL involved.

I see the SP issue two 302 redirects to the client browser (in this case running on the Mac Idp) about 10 seconds apart. The browser uses the first one with its cookie value in the response from the Idp.

I did try using tcpmon as a proxy on both boxes with flakey results also. Instead of the redirect loop, I would end up with it stopping cold, like the final response from the SP was never received by the browser through tcpmon.

I’ll have to try this more tomorrow, but any clues welcome.

Paul

Peter Williams

unread,

Dec 1, 2008, 1:17:14 AM12/1/08

to shibbole...@internet2.edu

I looped too at the outset, on the iis isapi filter - until I got the iis specific config right. Because of the role of cookies in shibsp, I half remember tracking the issue down to failing to use the domain name registered with testshib (ie don't use locahost in the iis config elements, which teaches shib how to talk to the iis metabase).

Have to remember that shib is not only an set of saml endoints, but is aslo a enforcing mechanism for iis applications based on the shib cookie that the filter/extension writes. Since metadata controls apps remotely (in shib), metadata in testshib seems to drive the cookie, which only approrpate iis config for the isapi filter can recognise (else loop to the idp, where an idp local session already exists, which...).

________________________________
From: Paul Hethmon <paul.h...@clareitysecurity.com>
Sent: Sunday, November 30, 2008 7:40 PM
To: Shibboleth Users <shibbole...@internet2.edu>
Subject: Re: [Shib-Users] Looping Problem

Paul Hethmon

unread,

Dec 1, 2008, 6:36:59 AM12/1/08

to shibbole...@internet2.edu

Peter,

Are you referring to the shibboleth2.xml or to the IIS config?

I'm working against testshib.org for both SP and IDP, just not against each other on my machines.

Thanks

Paul

Peter Williams

unread,

Dec 1, 2008, 8:27:38 AM12/1/08

to shibbole...@internet2.edu

shibboleth2.xml has a config section for iis, early on, binding the shib isapi to the "website" that the iis protocol engine is operating.

Shib (on iis) is a filtering/agent design - an interceptor.

________________________________
From: Paul Hethmon <paul.h...@clareitysecurity.com>

Sent: Monday, December 01, 2008 3:37 AM
To: shibbole...@internet2.edu <shibbole...@internet2.edu>

Reply all

Reply to author

Forward