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