Multiple IDP Entity IDs with 1 IDP

[Cantor, Scott]

>The reason we are leaning towards Overrides is that each customer has
>their own IdP service, some have required client-side CERTS, many have
>custom attribute mappings, and some have different Session requirements.

All those paths are on one vhost, and in one cookie domain with the same
shared security. A customer would be able to steal cookies from another if
they were able to manipulate content or access in such a way as to do so,
the browser won't stop it. You need vhosts if you want the separation to
mean anything security-wise.

>1) Since this override is really about a customer and not about us, do we
>need a handlerURL (e.g. handlerURL="/customer1/Shibboleth.sso") for each
>Override?

Yes. Otherwise the response will always come to the default application
and you'll loop when it redirects to a different one.

>2) In many examples we have seen, each overrides section has its own
>entityID. Is that required here? The "Base" URL for each customer will be
>the same.

No, it's not required, but I'm sure the examples tend to focus on that.
Usually that is the major reason to do an override.

>Do they each need an entityID in the Overrides section?

If your service is the same thing in every case, then one entityID is
fine, but the consequence isn't any different. Having a hundred endpoints
in an EntityDescriptor vs. a hundred EntityDescriptors with one set of
endpoints in each one is about the same. Both kind of suck.

Longer term the better model is probably to sign the SAML requests and get
IdPs to upgrade and support the option to forgo endpoint checks.

> Wouldn't that imply they each have to have their own Metadata on the SP
>somewhere?

The content of the metadata you manage in some way via a federation or
other trusted path depends on how you choose to configure things, yes.

>3) Lastly, this configuration is SP only. We have no Discovery Service.
>We do not even have an IdP server.
>What should we use for <SessionInitiator> or SSO (default IdP). For us,
>there really isn't one.

You can set it to anything you want as long as each requested URL is
associated with a real entityID that it needs to use using some other
configuration option. If it never has to fall into a default choice of
IdP, it won't matter what the default is. One option would be to set a
discoveryURL that just points to a page that is designed to catch it as a
sanity check and report an error.

>Can we just leave it out of the <ApplicationDefaults> altogether?

You cannot make the software work without a <SSO> element or the older
options that it replaced, and I believe you probably need either an
entityID or a discoveryURL in there, though I don't know offhand for sure.

-- Scott