SSO Redirect Loop

Tim Owens tim at reclaimhosting.com
Tue Aug 23 13:31:58 EDT 2016


Took a look at the PHP handler wondering if perhaps that had anything to do
with it and switched it to suPHP (this is a cPanel server and seems they're
defaulting to cgi now for new servers) and that worked! I appreciate the
help today debugging this and the input from everyone.

Tim Owens
Co-Founder • tim at reclaimhosting.com


On Tue, Aug 23, 2016 at 1:08 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 8/23/16 12:59 PM, Tim Owens wrote:
> > Totally understood. I had been using the SAML Chrome Panel in the
> > developer toolbar to watch the request, though I'll be the first to
> > admit I don't have enough of an understanding to parse the returned
> > requests and see if there's anything amiss there. I'll take a look at
> > Fiddler and SAML Tracer as well to see if they offer more insight. The
> > logs thus far haven't shown anything of note since the requests are
> > processing successfully so I do believe as Scott said it's an issue with
> > the cookie but haven't figured out why the app can't accept it when the
> > session is valid. I'll keep digging and appreciate the responses from
> > you all!
>
> It's the cookie internally to the SP, nothing to do with SAML. If you
> turn off active protection of content, it won't redirect automatically,
> and you would break the loop at least, which might help in debugging.
> It's the final resource access, and 99% of the time the answer is
> sitting right in native.log or the cookie's not even being submitted
> back. Usually the latter, which leads to no log of any kind and so no
> clues to follow.
>
> -- Scott
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160823/0232a225/attachment-0001.html>


More information about the users mailing list