Shibboleth SP & Okta IdP Redirect Looping

[Paul Carroll]

I see a POST after I login to the IdP.  The URL is the public access point.

POST https://myserver.mycompany.com/ HTTP/1.1
Host: myserver.mycompany.com

A 302 response is produced but it redirects back to the IdP.  No redirect to Shibboleth.sso/SAML/POST occurs.

I always receive a "A valid session was not found." when I browse to Shibboleth.sso/Session.  I have tried it before login and after login when I click stop on the browser to halt the redirects.

I went on the server that is hosting Shibboleth and Apache and accessed the protected resource using https://localhost.  It redirected back to https://myserver.mycompany.com/ once I logged into the IdP.

I checked https://localhost/Shibboleth.sso/Status and received some XML.  Is there anything I should be looking for in the XML?  The only thing I noticed were in the <ds:KeyName> and <ds:X509SubjectName> values.  The name ended with .admin and not .com.  Is that possibly an issue?

<ds:KeyName>myserver.mycompany.admin</ds:KeyName>
<ds:X509SubjectName>CN=myserver.mycompany.admin</ds:X509SubjectName>

Thanks,
Paul

--- cantor.2 at osu.edu wrote:

From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: Shibboleth SP & Okta IdP Redirect Looping
Date: Wed, 5 Aug 2020 22:54:58 +0000

> 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


-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net