...
| Note |
|---|
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. |
| Table of Contents |
|---|
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 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.
...
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.
...
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
redirectToSSLcontent 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.
...
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.
...