ApplicationOverride with apache reverse proxy and different configurations per customer

[Micky Williamson]

What am I missing ? :

shibsp::ConfigurationException

The system encountered an error at Tue Jul 12 18:37:36 2016

To report this problem, please contact the site administrator at root at localhost.

Please include the following message in any email:

shibsp::ConfigurationException at (https://id-jio-web.jeppesen.com/cust2/jiops/)

Invalid handlerURL property (c2/Shibboleth.sso) in <Sessions> element for Application (c2)

My config is:


 <ApplicationOverride id="c2" entityID="https://id-jio-web.jeppesen.com/c2">
      <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" checkAddress="false" handlerURL="/c2/Shibboleth.sso" handler
SSL="true" cookieProps="https">
        <SSO entityID="http://www.okta.com/exk6l60qelcbBCOaT0h7">SAML2 SAML1</SSO>
        <Logout>SAML2 Local</Logout>
        <Handler type="MetadataGenerator" Location="Metadata" signing="false"/>
        <Handler type="Status" Location="Status"/>
        <Handler type="Session" Location="Session" showAttributeValues="true"/>
        <Handler type="DiscoveryFeed" Location="DiscoFeed"/>
      </Sessions>
    </ApplicationOverride>


On Jul 11, 2016, at 8:21 PM, Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:

On 7/11/16, 9:30 PM, "users on behalf of Micky Williamson" <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> on behalf of mwilliamson at silasg.com<mailto:mwilliamson at silasg.com>> wrote:

It did dawn on me that after I got home I left off a little information of why the
configuration is the way it is....the software at the SP is NOT multi tenant capable...so
there will be one deployment per customer (I didn't write it).  So the separation to the
different tomcat backends is going to take place within the ReverseProxy configuration.
As I considered your comments, it dawned on me what you were getting at....sadly, the
apps are always going to be siloed...

And sadly that means the SP configuration will be awful. I'm just trying to explain why. It's not the right approach and is at odds with the design of the software. I think you understand the general issues now. That's all I was trying to get at.

Per your other note, using paths plus all of the other constraints here means you basically are stuck with a lot of extra work. If you want to do this, then you need to override the handlerURL in the Sessions tag for each override, and your SAML metadata will have to contain a set of endpoints for every customer that are prefixed with the path segment that's mapped to the applicationId.

You didn't do all of that, and that's why it's not working. This is covered in the wiki under the topic on application overrides.

Once you override handlerURL, it will generate requests with a response location of (e.g.) /cust1/Shibboleth.sso/SAML2/POST and that will associate the session it creates with the right override.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>


This communication may contain proprietary or other confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160712/3b95d61d/attachment.html>