ApplicationOverride with apache reverse proxy and different configurations per customer

[Cantor, Scott]

On 7/11/16, 9:30 PM, "users on behalf of Micky Williamson" <users-bounces at shibboleth.net on behalf of 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