shibd, ApplicationOverride not being acted on ... ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

shibd, ApplicationOverride not being acted on ... ?

Steven Carmody
HI,

My shibd.log file shows shibd receiving a request for applicationId
risd. However, its constructing a response for applicationId default.
There's nothing in the shibd.log indicating an ERROR or WARN; it just
switches to using default. I'm stumped. Can anyone see anything wrong
with the ApplicationOverride element down below ?

An interesting clue is that on my test machine the first two log lines
look like this:

2018-04-13 14:18:31 DEBUG Shibboleth.Listener [93]: dispatching message
(risd::getHeaders::Application)
2018-04-13 14:18:31 DEBUG Shibboleth.Listener [93]: dispatching message
(risd/Login::run::SAML2SI)

note that it has risd on both the getHeaders line and the /Login line.

Here's the shibd.log lines from the PROD server (note that line 2 is now
default/Login)

2018-04-13 14:06:15 DEBUG Shibboleth.Listener [1]: dispatching message
(risd::getHeaders::Application)

2018-04-13 14:06:15 DEBUG Shibboleth.Listener [1]: dispatching message
(default/Login::run::SAML2SI)

2018-04-13 14:06:15 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
validating input

2018-04-13 14:06:15 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
marshalling, deflating, base64-encoding the message

2018-04-13 14:06:15 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
marshalled message:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://www.cis-qas.brown.edu/risd/Shibboleth.sso/SAML2/POST"
Destination="https://sso.brown.edu/idp/profile/SAML2/Redirect/SSO"
ID="_4e56c228b9fb66a9f078d6e3bb675faa"
IssueInstant="2018-04-13T18:06:15Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"><saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://www.cis-qas.brown.edu/shibboleth-sp</saml:Issuer><samlp:NameIDPolicy
AllowCreate="1"/></samlp:AuthnRequest>

2018-04-13 14:06:15 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
message encoded, sending redirect to client

-----------------------------------------------

Here's the ApplicationOverride element for applicationId risd:

<ApplicationOverride id="risd" >
    <Sessions lifetime="28800" timeout="3600" checkAddress="false"
    handlerURL="/cis/sta/dev/burke/RISD/Shibboleth.sso" handlerSSL="true"
    idpHistory="false" idpHistoryDays="7"
    cookieProps="; path=/cis/sta/dev/burke/RISD">

       <SessionInitiator type="Chaining" Location="/Login"
       isDefault="true" relayState="cookie"
       entityID="https://eis-sso-test.risd.edu:9443/samlsso">
          <SessionInitiator type="SAML2" defaultACSIndex="1"
          template="bindingTemplate.html" />
          </SessionInitiator>

    </Sessions>
</ApplicationOverride>

this file is on Brown's main PROD web server. And yes, you're looking at
SessionInitiator elements, NOT SSO elements. Let me apologize profusely
on behalf of the local unix team, which manages this server.

all thoughts and suggestions welcome !

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: shibd, ApplicationOverride not being acted on ... ?

Peter Schober
Just a quick obversation:

* Steven Carmody <[hidden email]> [2018-04-13 20:43]:
> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> AssertionConsumerServiceURL="https://www.cis-qas.brown.edu/risd/Shibboleth.sso/SAML2/POST"

The handler URL from the authentication request above does match the
one defined in your override:

> <ApplicationOverride id="risd" >
>    <Sessions lifetime="28800" timeout="3600" checkAddress="false"
>    handlerURL="/cis/sta/dev/burke/RISD/Shibboleth.sso" handlerSSL="true"

But I may have missed something in your post.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: shibd, ApplicationOverride not being acted on ... ?

Cantor, Scott E.
In reply to this post by Steven Carmody
> My shibd.log file shows shibd receiving a request for applicationId risd.
> However, its constructing a response for applicationId default.
> There's nothing in the shibd.log indicating an ERROR or WARN; it just switches
> to using default. I'm stumped. Can anyone see anything wrong with the
> ApplicationOverride element down below ?

Peter pointed out the issue, but for my own purposes I would like to understand why an override is needed since it almost certainly isn't except in one case that I'm hoping to address in 3.0. Just want to make sure I don't overlook a use case.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: shibd, ApplicationOverride not being acted on ... ?

Steven Carmody
I'm using an Override to force a redirect to a different IDP.

default forces a redirect to the Brown IDP; for this particular url I
want to force a redirect to the RISD IDP ....

is there a better way to do that than using an Override ?

On 4/14/18 10:51 AM, Cantor, Scott wrote:

>> My shibd.log file shows shibd receiving a request for applicationId risd.
>> However, its constructing a response for applicationId default.
>> There's nothing in the shibd.log indicating an ERROR or WARN; it just switches
>> to using default. I'm stumped. Can anyone see anything wrong with the
>> ApplicationOverride element down below ?
>
> Peter pointed out the issue, but for my own purposes I would like to understand why an override is needed since it almost certainly isn't except in one case that I'm hoping to address in 3.0. Just want to make sure I don't overlook a use case.
>
> -- Scott
>

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: shibd, ApplicationOverride not being acted on ... ?

Steven Carmody
In reply to this post by Peter Schober
now I'm very confused ... I use this url to access this protected page:

https://www.cis-qas.brown.edu/cis/sta/dev/burke/RISD/index.html

the only place I see a lower case risd appearing is in the applicationId
value that links to the ApplicationOverride ....

any thoughts on how risd ended up in the ACS url ?

On 4/14/18 8:04 AM, Peter Schober wrote:

> Just a quick obversation:
>
> * Steven Carmody <[hidden email]> [2018-04-13 20:43]:
>> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>> AssertionConsumerServiceURL="https://www.cis-qas.brown.edu/risd/Shibboleth.sso/SAML2/POST"
>
> The handler URL from the authentication request above does match the
> one defined in your override:
>
>> <ApplicationOverride id="risd" >
>>     <Sessions lifetime="28800" timeout="3600" checkAddress="false"
>>     handlerURL="/cis/sta/dev/burke/RISD/Shibboleth.sso" handlerSSL="true"
>
> But I may have missed something in your post.
>
> -peter
>

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: shibd, ApplicationOverride not being acted on ... ?

Cantor, Scott E.
In reply to this post by Steven Carmody
> I'm using an Override to force a redirect to a different IDP.

Entirely unnecessary.

> is there a better way to do that than using an Override ?

ShibRequestSetting entityID foo

So you have the answer, dump the override, don't waste your time trying to fix it.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: shibd, ApplicationOverride not being acted on ... ?

Steven Carmody
thanks -- that worked !

ApplicationOverride works just fine on my test servers. but, the local
PROD machines are using a combination of squid and httpd Alias
Directives, and I suspect that causes problems with the matching.

thanks again !

On 4/16/18 10:35 AM, Cantor, Scott wrote:

>> I'm using an Override to force a redirect to a different IDP.
>
> Entirely unnecessary.
>
>> is there a better way to do that than using an Override ?
>
> ShibRequestSetting entityID foo
>
> So you have the answer, dump the override, don't waste your time trying to fix it.
>
> -- Scott
>

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]