ApplicationOverride with apache reverse proxy and different configurations per customer

[Micky Williamson]

Our issue about paths versus virtual hosts, In general this is going to be forward facing to many customers, under one product name, say :
myproduct.company.com  then each customer would be /cust1 /cust2 on the end of the URL.   (the reason for the /cust1 /cust2 urls is that the backend application is not multi tenant capable (bad design I know, I didn't write it).  To do virtual hosts, you would have to have cust1product.company.com cust2product.company.com (AFAIK) and the company has decided that from a branding perspective, they don't want to do that...so that leaves us with paths...or some other way to have the iDP identify to the Apache proxy which customer they logged in with, and have the reverse proxy forward the request from there....which is also possible.
I started down the Override path because it seemed like it fit with what I needed to do...but I would LOVE to keep it simple.


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

>> My configuration is below…in a nutshell:
>
>> When I access https://www.fakecompany.com/cust1 or https://www.fakecompany.com/cust2 I get
>> redirected to the IdP correctly…then the
>> IDP needs to redirect back to the proper Shibboleth.SSO/SAML/POST url and I’m not sure I  > have it correct…because it doesn’t seem to work.  I would like to not have to define an
>> application default, but Shibboleth doesn’t like that.  Can somebody please help?
>
> The best option is to stop using overrides. Shibboleth is not designed to silo everything. It wants you to load all the metadata globally, and if you must, you can tell it which IdP to use based on a path by specifying the entityID content setting in the Apache configuration based on the location/path.
>
> So you would tell it the entityID to use based on the /cust1 and /cust2 paths via "ShibRequestSetting entityID <idpname>"
>
> But that doesn't do authorization. Your application is expected to control which IdP(s) and user(s) can access resources without the SP doing that for you.
>
> That is the intended model in most cases.
>
> If you must compartmentalize this in the SP, then you should use virtual hosts instead, to segment customers, and in that scenario, your overrides can be fairly simple, pretty close to what you're doing now.
>
> What you're trying to do is the worst way to go, using paths. That is much more complex.
>
> To do that, your override's <Sessions> elements need to override the handlerURL setting and point it to /cust1/Shibboleth.sso and so forth, and then your metadata has to include complete endpoints for every set of paths.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to 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.