SP looping next step?

Francesc Travesa francesc.travesa at oist.jp
Wed Nov 12 03:42:20 EST 2014


It might be of some help, maybe not.

It happened to me with Drupal and Symfony, it might be related.

Does wordpress have an .htaccess file by default?

Normally this .htaccess file includes a redirect option (to hide the index.php in the URL for example) that makes shibboleth fire again.

Try commenting this htaccess file if it's there.

(just for completeness, if its that, its enough to tell mod rewrite to leave the return URL from the IdP in peace:
RewriteCond %{REQUEST_URI} Shibboleth.sso/SAML2/POST
RewriteRule .? - [L]
for example)

Cesc
________________________________________
De: users-bounces at shibboleth.net [users-bounces at shibboleth.net] en nombre de Cantor, Scott [cantor.2 at osu.edu]
Enviado: miércoles, 12 de noviembre de 2014 10:41
Para: Shib Users
Asunto: Re: SP looping next step?

On 11/12/14, 1:23 AM, "David Bantz" <dabantz at alaska.edu> wrote:


>
>Well, er…, yes, it’s /Shibboleth.sso/Login target;  we’re not
>understanding why that’s incorrect or what it should be instead because
>that is the WP plugin default apparently and also what UA-Madison and
>Cambridge documentation indicate:

I don't know anything about WordPress, but any time you redirect to a
Shibboleth session initiator, you either get an error, end up at a
discovery page, or send a login request to an IdP. It is not a "resource"
to protect, and you cannot end up there after a SAML response is handled,
because that's just a loop. A protected resource has to be something else.

There has to be *something* in between in your trace. Presumably you're
missing it, and it's something in WordPress that's doing the eventual
redirect back to the session initiator. If not, you just have a totally
broken configuration of whatever application is involved.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list