Multiple SP Overrides sites, generate Metadata

[Cantor, Scott]

On 10/11/12 7:16 PM, "Roger Jagoda" <rberryj3 at gmail.com> wrote:
>
>Good question. We just provide SPs. The people we serve are very
>distinct. They are geographically separate, they all have separate
>user-bases with different needs and focuses. Some will deal with plain
>"valid user." others have defined group entities. There just isn't a
>way to segregate the need other than multiple Override sites. Unless I
>ma missing something very basic. There just really isn't anything much
>in common (no pun intended) amongst the entities.

So you're acting as a front end to some other set of systems? Ok, then in
that scenario, you're not really even the entity in a policy sense, they
are. So indeed, the entityID probably shouldn't even be in your domain at
all, but yes, it's probably sensible to be using that feature.

>Fine. Then we'll leave the Default almost blank since there will
>really be no default. There is not much in common to leave in the
>default.
>There are even very different lifetimes among the various customer sites.

That's fair, but chances are you want any handlers declared up there and
inherited. They're all different by vhost once you actually get down to
using them.

>Yes, we are mapping the overrides to vhosts. Is there a better way?

No, that's the preferred model.

>Excellent. Thanks so much. We were really wringing our hands about that.
>That makes the Override much easier. However there is a really great
>example of  doing it in the Overrides in the docs:

Yes, but that example is to set *your* entityID, not specify an IdP to
use. Those are separate things. I'm saying you don't need to use the
override to specify the IdP to use for a given set of URLs.

>See above. I do not know another way when all of the SPs are using
>very different vhosts (different domains, different geographies, etc)
>in wildly different user space environments.
>Apologies, but we really do have the need.
>
>Scott, you know best, but if there is a better way to serve multiple
>IdPs with distinct user sets we're going to listen to you, of course.

I'm still a bit unsure. You're using the term IdP but I'm not sure if you
mean SP or IdP here. You're the SP, they're the IdP. If you're offering
one application service, you're one entity. Just because you offer it to a
thousand IdPs, that doesn't make you a thousand SPs.

-- Scott