Closed ghost closed 6 years ago
Yes, there are two parts as described in #34.
The first is allowing an active Shibboleth session to be loaded by WordPress (usually in .htaccess):
AuthType shibboleth
Require shibboleth
The second is to make sure the webserver allows you to use commands like AuthType and Require (usually in the webserver configuration files, such as within the matching <VirtualHost>):
AllowOverride AuthConfig
Reference: https://httpd.apache.org/docs/2.4/howto/htaccess.html#auth
Seems to be good already.
I actually suspect the bad attemp of idp logout url (with multiple known sp logout using iframe technique) to be in cause. I have the impression that the session is not closed and there is a conflict there (I have seen a fail in chrome network log for my sp, I need to double check that).
It's likely very specific to our setup and I really need to talk about the issue with my coworker that is a bit more knowledgeable of our setup, I will check that with him maybe next week.
I will close and reopen if I find something worth to share.
If it can help someone else.
It was really my error and seems to be a well known issue : http://shibboleth.1660669.n2.nabble.com/SSO-Redirect-Loop-td7627756.html
I didn't notice my return url was still using http instead of https (?return=http://).
The problem was occuring after the second login, which was done from http site.
I had changed cookieProps="http" to https in shibboleth2.xml without reading the comments ("You should also set cookieProps to "https" for SSL-only sites").
Sorry for the false error.
I just had this problem, I can reproduce it but I suspect it could be the fault of my own plugin but in the other hand I cannot reproduce it with the production server that is still using the previous version.
It seems to loop on Redirect and I can see the SAMLRequest changing.
I noticed the thread on WordPress https://wordpress.org/support/topic/login-loop-wp-4-9-5-apache-2-4/ so I'll check that first and also investigate logs.