...
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.
| 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 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.
...
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". The 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.Having confirmed a mismatch of some kind, you can try and match your problem against some common looping causes below, or if it is returned, it isn't being accepted.
Requests Bouncing Between HTTP and HTTPS
Another 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.
...
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.
Requests bouncing without scheme change
If Apache 2.4 is involved, check the Apache Virtual Host. If the protected <Directory> or <Location> has a
Require all granted
...
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).