ApplicationOverride with apache reverse proxy and different configurations per customer

[Cantor, Scott]

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