[Shib-Users] ApplicationOverride posting to default application

22 views
Skip to first unread message

Coral Featherstone (Sr. Java Developer)

unread,
Jun 28, 2010, 1:39:02 AM6/28/10
to shibbole...@internet2.edu

I am trying to get my various paths  to hardcode the homeURL as a temporary workaround since the IDP is not returning to the starting url

 (as per the thread  Ca Siteminder Idp with Shib SP - homeUrl always used).

 

Yep, horrid, I know :~(

I’m stuck again. Am I doing something obvious wrong? I know it shouldn’t be necessary, but is it possible to do this?

 

 

I initially just tried overriding the homeurl on the path

<Host name="curasso-sp.schq.local"  >

      <Path name="cura"  authType="shibboleth" requireSession="true" exportAssertion="false" >

         <Path name="assessor" homeURL="https://curasso-sp.schq.local/cura/assessor" />

         <Path name="surveys" homeURL="https://curasso-sp.schq.local/cura/surveys

      </Path>                                                        

</Host>

 

But this is not working.

Trying an application override:-

 

<Host name="curasso-sp.schq.local"  >

     <Path name="cura"  authType="shibboleth" requireSession="true" exportAssertion="false" >

         <Path name="assessor" homeURL="https://curasso-sp.schq.local/cura/assessor" />

         <Path name="surveys" applicationId="surveysApp" homeURL="https://curasso-sp.schq.local/cura/surveys"  /><!--requireSessionWith="surveysTCCCInitiator"-->

      </Path>                                                        

</Host>

 

With either:-

<ApplicationOverride id="surveysApp" homeURL="https://curasso-sp.schq.local/cura/surveys">

      <Sessions lifetime="7200" timeout="3600" checkAddress="false" handlerURL="/surveys/Shibboleth.sso"  / >

</ApplicationOverride>

Or:-

<ApplicationOverride id="surveysApp" homeURL="https://curasso-sp.schq.local/cura/surveys">

      <Sessions lifetime="7200" timeout="3600" checkAddress="false" handlerURL="/surveys/Shibboleth.sso"   >

            <SessionInitiator id="surveysTCCCInitiator" type="SAML2" Location="/surveys/Login"  acsIndex="1"  relayState="cookie" entityID="ko.idp" template="bindingTemplate.html"/>

            <md:AssertionConsumerService Location="/surveys/SAML2/POST" index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>                

    </Sessions>

</ApplicationOverride>

 

  the application override is being picked up, but the return post always goes back to the default application.

I thought the correct handlerURL would handle this.

 

Relevant Native.log as follows:-

 

2010-06-26 14:24:39 DEBUG Shibboleth.ISAPI [904] isapi_shib: mapped https://curasso-sp.schq.local/cura/surveys to surveysApp

2010-06-26 14:24:39 DEBUG Shibboleth.SessionInitiator.SAML2 [904] isapi_shib: attempting to initiate session using SAML 2.0 with provider (ko.idp)

2010-06-26 14:24:39 DEBUG Shibboleth.Listener [904] isapi_shib: sending message (surveysApp/surveys/Login::run::SAML2SI)

2010-06-26 14:24:39 DEBUG Shibboleth.Listener [904] isapi_shib: send completed, reading response message

2010-06-26 14:24:42 DEBUG Shibboleth.ISAPI [904] isapi_shib: mapped https://curasso-sp.schq.local/Shibboleth.sso/SAML2/POST to default

 



Confidentiality Note: The information contained in this e-mail and documents attached are for the exclusive use of the addressee and contain confidential and privileged information that may not be disclosed. If the recipient of this e-mail is not the addressee, or intended addressee such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this email or its contents in any way.

Scott Cantor

unread,
Jun 28, 2010, 10:27:28 AM6/28/10
to shibbole...@internet2.edu
> the application override is being picked up, but the return post always
> goes back to the default application.
> I thought the correct handlerURL would handle this.

Only if the IdP is behaving properly, has the right metadata, etc. I can
basically guess that it's broken, because it's not honoring the response
location the SP is asking for, and that's probably because it isn't even
processing the request at all, pursuant to the other thread.

-- Scott


Reply all
Reply to author
Forward
0 new messages