shibboleth2.xml configuration for www and non-www requests to same host (IIS)
chrisdell at gmail.com
Thu May 25 14:04:17 EDT 2017
Apologies for the HTML email. Below is the message again without html. To
clarify, the issue is that after authentication, when an https request is
made without www in the host, shibboleth redirects to
https://www.example.com, losing the path. Every other combination works
correctly and the path is maintained (http://www, https://www,
I've tried setting up an Alias but the documentation also specify that
"Using an alias requires that you duplicate any request map settings for
each host you want to allow.", but when I add <Alias>example.com</Alias> to
the <Site name=www.example.com>, and then duplicate the request map, I'm
getting a Shibboleth error.
Previous message without html:
We're using IIS 7.0.
We're having a problem in which the following request is authenticated, but
after successful login, is incorrectly redirected to https://www.example.com
But these requests all work correctly (after login, all are redirected to
https://www.example.com/site/aspx as expected):
Do you have any suggestions? Redirect rules configured in the redirect
module seem to happen after any shibboleth authentication, so that doesn't
seem to be a fix/problem.
Our requestmap is configured similar:
<Host name="www.example.com" applicationId="idhere" redirectToSSL="443">
<Path name="aspx" requireSession="true" authType="shibboleth">
And our ISAPI:
<Site id="####" name="www.example.com"/>
On Thu, May 25, 2017 at 12:12 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> > We're having a problem in which the following request is authenticated,
> > after successful login, is incorrectly redirected to
> I can't make sense of what specific sequence you're asking about, and the
use of HTML email (which I do not read) is a good way to really screw
things up with all the embedded links. So I'm not really getting it.
> That said...
> > Do you have any suggestions? Redirect rules configured in the redirect
> > module seem to happen after any shibboleth authentication, so that
> > seem to be a fix/problem.
> I am aware of that particular issue, it's why the SP includes a hook to
do port redirects, you can add redirectToSSL="443" in the RequestMap and it
will do the redirects before any other processing of a request. That's the
way to force user requests for an http vhost to get switched over and avoid
the need for SAML endpoints on http.
> I don't know if that's the problem or a fix but just in case.
> Hostname issues have *nothing* to do with the SP. You determine all that,
it has nothing to do with this software. That's why you have to map site
IDs in IIS into the appropriate hostnames you want to support if you're
going to assign settings based on them. All the software knows is what the
client tells it the name is, so the software routes through the site ID to
determine if that name is "appropriate" for the request.
> If the question is how to allow for multiple hostnames on a site ID at
once, there's an <Alias> element for that.
> You must of course have rules in the RequestMap for all possible
hostnames you want to support.
> -- Scott
> To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users