Redirect loop after changing to name based virtual hosts

[Ferenc Wagner]

"Cantor, Scott" <cantor.2 at osu.edu> writes:

> On 3/5/13 3:11 PM, "Ferenc Wagner" <wferi at niif.hu> wrote:
>
>> Sorry for the probably lame question, but we've been staring at this
>> issue for hours without success.  We were using Shibboleth on a server
>> with IP based HTTPS virtual hosts.  Now we converted them to name based
>> virtual hosts with a common HTTPS certificate (with subjectAltName
>> extensions), and Shibboleth does not work anymore with the non-default
>> virtual hosts: the browser falls info a redirect loop after submitting
>> the username and password to the IdP:
>
> I think you're starting at the wrong end, all the interesting information
> is on the SP, mostly in native.log on DEBUG when it maps the requests and
> issues location pointers back to itself.

Thanks for the tip, this indeed proved useful, although I still don't
quite understand how the problem came around.  But it was fixed by
including the URI scheme (https://) into the ServerName directives in
the Apache virtual host configurations.  Before that the "DEBUG
Shibboleth.Apache [X] shib_check_user: mapped ..." logs always mentioned
nonexistent http:// URIs.  Actually, these virtual host configurations
do not contain SSL directives anymore, but use the SSL configuration of
the default virtual host (being name based and without SNI).  For us,
sticking https:// into ServerName is no problem, but I wonder if a more
general solution is possible.  UseCanonicalName also didn't change the
situation.

>> The non-default virtual hosts have unique applicationIds configured in
>> the RequestMapper, and their entityIDs are set in ApplicationOverrides.
>
> That's a red flag right there, loops often result from mismatched rules
> about application IDs. The session gets created with app ID A but the
> resource is app ID B so it loops back for another try.

The exact same Shibboleth configuration works with IP based virtual
hosts, so I don't expect a problem here.

> Or it's just a plain Apache problem reporting the hostname inaccurately.

Well, it was, sort of.
-- 
Thank you very much for your prompt and to the point remarks!

Regards,
Feri.