Looping

Owned by Rod Widdowson
Last updated: Nov 24, 2021
5 min read

"Looping" refers to a situation in which an attempt to login to the SP results in a rapid cycle of redirections between the IdP and the SP with a new session created every time around. Typically the browser will appear to hang or flash, and in some cases the cycle will end with an error page indicating a connectivity problem, exceeding a limit on redirections, or some other message. The relevant log files will show clear evidence of looping when you see sessions being created in rapid sequence.

Of course, looping depends on the use of SSO (session reuse) on the part of the IdP, so if SSO is disabled on that end, the SP will simply send the browser back to the IdP and another prompt to authenticate will appear. In the case of the POST binding/profile, it also assumes JavaScript is enabled, since disabling that will cause the browser to hold waiting for a manual form submission step.

Looping is a fairly common problem when initially configuring an SP, particularly in a virtually hosted environment involving unusual ports, SSL offloading, or other web hosting complications.

The underlying cause of any looping scenario is a mismatch between the properties of the session cookie created by an Assertion Consumer Service and the URL(s) of the resources the session is supposed to secure. Sometimes the properties have to do with the URLs involved, and sometimes they pertain to rules governing the use of the cookie, such as the browser's address.

Before Debugging

To understand the cause of looping, you need to know a little about cookies, which you can learn about all over the web, but in a nutshell, the cookie issued by the SP is bound to the exact domain name the client sees when it accesses the ACS (the URL that ends in /POST), and this must match the domain name the client sees when it accesses the resource. In addition, some configurations may add the "secure" property that limits cookies to SSL access only, in which case the resource must also be SSL protected. In newer versions, using the cookieProps setting "https" automatically adds that property.

In addition, with Shibboleth the cookies are by default address-bound, meaning that once issued to a client with a specific IP address, the client has to continue operating with that IP address or the session will be invalidated.

To diagnose looping problems, you need to review the FlowsAndConfig topic that outlines the general sequence of events in a standard Shibboleth interaction, including what cookies are generally created and when they have to be read back in. The green tip boxes in the page will help you spot these points in the process.

It will also usually be very helpful to utilize browser settings that cause you to be prompted to accept cookies, and may be useful to have a browser with a plugin like Firefox's Live Headers extension or the Fiddler proxy tool that can show you detailed traces of the requests and headers (including cookies) that are flowing in each direction.

URLs to Capture

In debugging this problem, there are three primary URLs accessed by the browser that you will want to obtain:

  • the initial resource URL being accessed (the "target")

  • the Assertion Consumer Service to which the response to the SP is delivered (the "ACS", also called the "shire" in the legacy protocol, it usually ends in /POST)

  • the actual resource URL to which the ACS response redirects the browser (the "resource")

Often the "target" and "resource" will be the same when looping occurs, but not always.

The difficulty is that in some cases, some browsers will "lie" to you about what URL is actually being accessed because they fail to properly update the location bar in the course of all the redirects and scripted form submissions that take place in the course of a login. It usually helps to enable prompting for cookie acceptance in order to pause the flow in the right places.

In the usual mode of operation, accessing the "target" will result in a cookie, allowing you to see that URL before accepting the cookie. Another cookie will be set after the "ACS" is done with its work, allowing that location to be noted. And finally, when looping, the final redirection to the "resource" should result in another cookie, because the resource is accessed without the expected session cookie and becomes the next "target" in the loop.

Debugging and Common Causes

In general terms, what you have to do to diagnose the problem is to compare the URLs noted above to identify a mismatch between them, in particular the "ACS" and the "resource". A loop is often caused by the fact that the cookie set by the "ACS" (and associated with its domain name by the browser) is not being returned to the SP when the "resource" is accessed, presumably because they don't match, or if it is returned, it isn't being accepted.

Requests Bouncing Between HTTP and HTTPS

One cause of looping is the use of the "secure" cookie attribute to limit cookie use to SSL-protected requests, which in the SP can be added with the cookieProps property in the <Sessions> element (either manually or by using the setting "https"). This is a common (and highly advisable) change for any site intended to be SSL protected.

The problem is that it only works if you also block any non-SSL access to the same site. If you fail to do this, then the cookie established for the SP session will never be returned during the non-SSL requests, and the cycle will simply repeat.

In the log, this condition manifests by showing a session created and then immediately followed by process to request a new session. The original session won't be mentioned, and in particular it won't show any sign of being removed.

Remedy

Block non-SSL access.

You can prevent improper access in a few different ways:

  • Shut off the non-SSL port and just let requests fail.

  • Use native web server functionality to require SSL. This generally causes the server to return an error page to the browser indicating SSL is required. Note that this will not work on IIS, because the detection of this condition occurs after the filter installed by the SP runs.

  • Use the redirectToSSL content setting via Apache command, <RequestMap>, etc. Typically this setting is applied at a host-wide level, to send all improper requests to the SSL port.

Only give up on the cookieProps change as a last resort. I'm not aware of any situations in which one of the above mechanisms won't work, and the additional protection of limiting the cookie to SSL is substantial. It's only omitted by default because so many people end up with loops and complain to the support list.

IP Address Mismatches

The previous problem manifests because the SP can't find a session for the client. This problem manifests when the session is found but is deemed invalid, so a new one is requested.

This manifests in two key ways:

  • The native log (in V3 this is routed to syslog or the Event Log by default) will include an explicit warning.

  • The shibd log and transaction log will illustrate a "create, remove" sequence for a single session, because the session is created, then accessed once, found to be invalid, and removed. The remove step is what distinguishes it from more fundamental cookie problems.

The correct for fix for this is to correct whatever network condition is causing the client to float between different addresses.

For testing, and really for no other scenario, you can temporarily disable the check that causes the loop by setting the consistentAddress property to false (see the <Sessions> element docs).