IIS 7.5 web application, SP and shibboleth2.xml - ApplicationOverride not taking precedence over ApplicationDefaults

[Haer, Neelam]

Hi All,

I'm trying to get a client setup on IIS7.5, Windows 8 server with the latest 64-bit version of Shibboleth SP.

The trouble I'm having is very strange and I have not seen this before. For some reason, the SP (?) is only sending over the

ApplicationDefaults settings (which we typically leave as the defaults and do not use) instead of the ApplicationOverride.

What I mean by that is:

<ApplicationDefaults id="default" policyId="default"
entityID="https://server.com/do-not-use"
homeURL="https://server/cp,/"
REMOTE_USER="eppn persistent-id targeted-id"
signing="true" encryption="false"
>
Is used instead of:
<ApplicationOverride id="rename--my-application-name"
entityID="https://client-id/shibboleth"
homeURL="https://client-url/ebusiness"
REMOTE_USER="somerandomstring" >
<Sessions handlerURL="/locked/Shibboleth.sso"
handlerSSL="true"
cookieProps="; path=/locked; secure"
checkAddress="false"
lifetime="7200" timeout="3600" />
</ApplicationOverride>

Does anyone know why this is the case?

Thanks.

[Haer, Neelam]

Just a small correction, as I masked out parts of the urls: see below, question is still the same:

I'm trying to get a client setup on IIS7.5, Windows 8 server with the latest 64-bit version of Shibboleth SP.

The trouble I'm having is very strange and I have not seen this before. For some reason, the SP (?) is only sending over the

ApplicationDefaults settings (which we typically leave as the defaults and do not use) instead of the ApplicationOverride.

What I mean by that is:

<ApplicationDefaults id="default" policyId="default"
entityID="https://server.com/do-not-use"
homeURL="https://server.com/"
REMOTE_USER="eppn persistent-id targeted-id"
signing="true" encryption="false"
>
Is used instead of:
<ApplicationOverride id="rename--my-application-name"
entityID="https://client-id/shibboleth"
homeURL="https://client-url/locked"
REMOTE_USER="somerandomstring" >
<Sessions handlerURL="/locked/Shibboleth.sso"
handlerSSL="true"
cookieProps="; path=/locked; secure"
checkAddress="false"
lifetime="7200" timeout="3600" />
</ApplicationOverride>

Does anyone know why this is the case?

Thanks.

[Cantor, Scott]

On 9/9/14, 12:56 PM, "Haer, Neelam" <nklhaer-cZbHFfHSJIksA/***@public.gmane.org> wrote:
>
>The trouble I'm having is very strange and I have not seen this before.
>For some reason, the SP (?) is only sending over the ApplicationDefaults
>settings (which we typically leave as the defaults and do not use)
>instead of the ApplicationOverride.

I don't know what you mean by "sending over". If the SP isn't mapping
requests to the intended applicationId, then your RequestMap is off or
your Site mappings are.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Haer, Neelam]

Hi Scott,

Thanks for your reply.

I used the term "sending over" because somehow, the idP logs are showing that settings from the ApplicationDefaults section (which don't contain any relevant information) as opposed to the actual settings, which are in the <ApplicationOverride> section. I hope that makes better sense?

I double-checked that the applicationIds are matching, we typically don't change them and it looks like in this instance they have not been changed from the defaults, but why is the idP not using the ApplicationOverride settings?

<RequestMapper type="Native">
<RequestMap applicationId="default">
<Host name="clientSiteNameInIIS">
<Path name="locked" applicationId="rename--my-application-name"
authType="shibboleth" requireSession="false" exportAssertion="false">
</Path>
</Host>
</RequestMap>
</RequestMapper>

<ApplicationDefaults id="default" policyId="default"
entityID="https://something_here/do-not-use"
homeURL="https://someURL/"
REMOTE_USER="eppn persistent-id targeted-id"
signing="true" encryption="false"
>

<ApplicationOverride id="rename--my-application-name"
entityID="https://clientDomain/shibboleth"
homeURL="https://clientDomain/locked"
REMOTE_USER="somerandomstring" >
<Sessions handlerURL="/locked/Shibboleth.sso"
handlerSSL="true"
cookieProps="; path=/locked; secure"
checkAddress="false"
lifetime="7200" timeout="3600" />
</ApplicationOverride>

[Cantor, Scott]

On 9/9/14, 2:00 PM, "Haer, Neelam" <nklhaer-cZbHFfHSJIksA/***@public.gmane.org> wrote:

>I used the term "sending over" because somehow, the idP logs are showing
>that settings from the ApplicationDefaults section (which don't contain
>any relevant information) as opposed to the actual settings, which are in
>the <ApplicationOverride> section. I hope
> that makes better sense?

Sort of, but my answer is the same.

>I double-checked that the applicationIds are matching, we typically don't
>change them and it looks like in this instance they have not been changed
>from the defaults, but why is the idP not using the ApplicationOverride
>settings?

The IdP doesn't "use" anything. The SP uses them when it does things. If
it's using the wrong settings, then the requests aren't mapped the way you
think they are.

><RequestMapper type="Native">
><RequestMap applicationId="default">
><Host name="clientSiteNameInIIS">
><Path name="locked" applicationId="rename--my-application-name"
>authType="shibboleth" requireSession="false" exportAssertion="false">

In that situation, it's possible the content involved with the problem
doesn't live under that path.

Or the Site mapping is not associating the expected hostname with the
requests.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Haer, Neelam]

Thanks again Scott,

>>><RequestMapper type="Native">
>>><RequestMap applicationId="default">
>>><Host name="clientSiteNameInIIS">
>>><Path name="locked" applicationId="rename--my-application-name"
>>>authType="shibboleth" requireSession="false" exportAssertion="false">

>>In that situation, it's possible the content involved with the problem doesn't live under that path.

>>the Site mapping is not associating the expected hostname with the requests.


Do you mean that I should verify that the hostname specified in the shibboleth2.xml matches the site name defined in IIS?

-- just making sure I understand correctly.

Thanks
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Cantor, Scott]

On 9/9/14, 2:20 PM, "Haer, Neelam" <nklhaer-cZbHFfHSJIksA/***@public.gmane.org> wrote:
>
>Do you mean that I should verify that the hostname specified in the
>shibboleth2.xml matches the site name defined in IIS?

There is no such thing in IIS. IIS doesn't understand hostnames or
virtualization properly. The site mapping machinery is in the SP config in
the ISAPI element.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Haer, Neelam]

Hi Again,

>There is no such thing in IIS. IIS doesn't understand hostnames or
>virtualization properly. The site mapping machinery is in the SP config in
>the ISAPI element.

I checked the settings, the ISAPI element ID matches the site id in IIS (in this case they are simply using the default web site, which has ID="1"

<InProcess logger="c:/opt/shibboleth-sp/etc/shibboleth/native.logger">
<ISAPI normalizeRequest="true">
<Site id="1" name="clientSiteName"/>
</ISAPI>
</InProcess>

And the name matches that specified in the <Host>
<Host name="clientSiteName">
<Path name="locked"
applicationId="rename--my-application-name"
authType="shibboleth"
requireSession="false"
exportAssertion="false">
</Path>
</Host>


I'm not sure what else I could try? This - should be fairly straight forward, but for some reason, it's just not....

Thanks,
Neelam
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Cantor, Scott]

On 9/9/14, 2:40 PM, "Haer, Neelam" <nklhaer-cZbHFfHSJIksA/***@public.gmane.org> wrote:
>
>I checked the settings, the ISAPI element ID matches the site id in IIS
>(in this case they are simply using the default web site, which has ID="1"

You can check all you like, it doesn't change my answer.

>I'm not sure what else I could try? This - should be fairly straight
>forward, but for some reason, it's just not....

Turn native.logger up to DEBUG and look at the RequestMap log entries.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Haer, Neelam]

>> Turn native.logger up to DEBUG and look at the RequestMap log entries.

Thanks Scott. I will post my findings once I get them. The client seems to be having another issue now where after updating the native.logger level to DEBUG, there is nothing logging.

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org