Shibboleth SP & Okta IdP Redirect Looping

[Cantor, Scott]

> Is that seem correct for the AssertionConsumerServiceURL?

The path is; I can't tell you if the URL as a whole is, particularly as it's been obfuscated. If that's the public access point to the system the client should be using, then it's probably correct.

>  Should it be the Destination?

That's a request to the IdP, not the response to the SP. What happens after is a form constructed by the IdP to post to the SP and there is virtually no possibility that there is not a POST request to that URL happening, whether it actually works or not (presumably not, or we wouldn't be talking about it).

Firefox + SAML Tracer. Tells you all you have to know about what it's attempting to do and what the responses and status codes are at every point.

The POST should produce a 302 to the resource and since it's not, figuring out what it is doing and what code is actually "doing it" is the necessary task, on top of the Session handler probes I already suggested trying.

There's also the /Status handler, though that's localhost only by default without config changes. But since the handlers aren't even working, /Shibboleth.sso/Anything is probably as good as any other test. All of them probably will fail and that means the SP is just broken and being interfered with.

-- Scott