Multiple IDP Entity IDs with 1 IDP

[Roy Spectech]

Scott,

We should have re-read this thread long ago.

We have been getting exactly what you said; everything is coming to the
default application. OK, so we need a custom handlerURL for each customer.

Given that the path HTTPD path structure looks like this:

wwwroot/customer1/login
wwwroot/customer2/login
wwwroot/customer3/login
[...]

would the custom handlerURLs be these:

handlerURL="/customer1/Shibboleth.sso"
handlerURL="/customer2/Shibboleth.sso"
handlerURL="/customer3/Shibboleth.sso"

I also like your summary of the single entityID and multiple endpoint
versus multiple entityIDs with a single set of endpoints.."both kinda suck!"

But, since we have to use one or the other, uhm, which sucks less?

:-)


-- RGS

==================================
Roy G. Specter
roygspectech8 at gmail.com
========================================


On Mon, Aug 5, 2013 at 7:58 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> >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
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130908/d5f95093/attachment.html