ApplicationOverride with apache reverse proxy and different configurations per customer

[Micky Williamson]

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...

On Jul 11, 2016, at 3:56 PM, Micky Williamson <mwilliamson at silasg.com> wrote:

> Thanks Scott…I think I’m gonna have to get some onsite help for this.  We were able to spin it up fairly quickly for one customer, but it appears that the knowledge to do this for multiple will require more brainpower than I posses.
>
> I appreciate your feedback.
>
>
>> On Jul 11, 2016, at 3:50 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>>
>> On 7/11/16, 5:40 PM, "users on behalf of Micky Williamson" <users-bounces at shibboleth.net on behalf of mwilliamson at silasg.com> wrote:
>>
>>> this sounds like the right configuration….I am not an Identity person, just one who has
>>> been asked to swap out Wso2 for Okta/Shibboleth.  since we have Okta as an Idp, and Okta
>>> will have a serrate entity id per “pool of customers”….where do you tie the different
>>> entity ids (one per customer) to shibboleth if you don’t use overrides?
>>
>> You do it in the application (if at all) using policy, or you do it with attributes and appropriate enforcement of the "scope" of identifiers that identify users, and don't worry about the IdP at all.
>>
>> For example, if you enforce in software that only OSU's IdP can assert cantor.2 at osu.edu, then it doesn't matter what IdP is used. Access from any trusted IdP can only achieve what access you grant to that IdP's users, so you have naming constraints built-in to the model.
>>
>> Consider that your application is breaking federation outright if it assumes that a resource can only be accessed by one IdP at a time. That itself may make no sense, but I don't know anything about your service, so I can't say. Even if it makes sense to limit it to *some* IdPs, it's likely that in the general case, you need to allow for >1 at a time, not just one. That's another reason trying to tie things to a single IdP at a time is a bad idea.
>>
>> -- 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.
> --
> 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.