<div dir="ltr"><div><div><div><div><div><div><div>Scott,<br><br>We should have re-read this thread long ago.<br><br></div>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.<br>
<br></div>Given that the path HTTPD path structure looks like this:<br><br></div>wwwroot/customer1/login<br></div>wwwroot/customer2/login<br>wwwroot/customer3/login<br>[...]<br><br></div>would the custom handlerURLs be these:<br>
<br>handlerURL="/customer1/Shibboleth.sso"<br>handlerURL="/customer2/Shibboleth.sso"<br>handlerURL="/customer3/Shibboleth.sso"<br><br></div>I also like your summary of the single entityID and multiple endpoint versus multiple entityIDs with a single set of endpoints.."both kinda suck!"<br>
<br></div><div>But, since we have to use one or the other, uhm, which sucks less?<br><br>:-)<br></div><div><div><div class="im"></div><br></div></div><div class="gmail_extra"><br clear="all"><div>-- RGS<br><br>==================================<br>
Roy G. Specter<br><a href="mailto:roygspectech8@gmail.com" target="_blank">roygspectech8@gmail.com</a><br>========================================<br></div>
<br><br><div class="gmail_quote">On Mon, Aug 5, 2013 at 7:58 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">>The reason we are leaning towards Overrides is that each customer has<br>
>their own IdP service, some have required client-side CERTS, many have<br>
>custom attribute mappings, and some have different Session requirements.<br>
<br>
</div>All those paths are on one vhost, and in one cookie domain with the same<br>
shared security. A customer would be able to steal cookies from another if<br>
they were able to manipulate content or access in such a way as to do so,<br>
the browser won't stop it. You need vhosts if you want the separation to<br>
mean anything security-wise.<br>
<div class="im"><br>
>1) Since this override is really about a customer and not about us, do we<br>
>need a handlerURL (e.g. handlerURL="/customer1/Shibboleth.sso") for each<br>
>Override?<br>
<br>
</div>Yes. Otherwise the response will always come to the default application<br>
and you'll loop when it redirects to a different one.<br>
<div class="im"><br>
>2) In many examples we have seen, each overrides section has its own<br>
>entityID. Is that required here? The "Base" URL for each customer will be<br>
>the same.<br>
<br>
</div>No, it's not required, but I'm sure the examples tend to focus on that.<br>
Usually that is the major reason to do an override.<br>
<div class="im"><br>
>Do they each need an entityID in the Overrides section?<br>
<br>
</div>If your service is the same thing in every case, then one entityID is<br>
fine, but the consequence isn't any different. Having a hundred endpoints<br>
in an EntityDescriptor vs. a hundred EntityDescriptors with one set of<br>
endpoints in each one is about the same. Both kind of suck.<br>
<br>
Longer term the better model is probably to sign the SAML requests and get<br>
IdPs to upgrade and support the option to forgo endpoint checks.<br>
<div class="im"><br>
> Wouldn't that imply they each have to have their own Metadata on the SP<br>
>somewhere?<br>
<br>
</div>The content of the metadata you manage in some way via a federation or<br>
other trusted path depends on how you choose to configure things, yes.<br>
<div class="im"><br>
>3) Lastly, this configuration is SP only. We have no Discovery Service.<br>
>We do not even have an IdP server.<br>
>What should we use for <SessionInitiator> or SSO (default IdP). For us,<br>
>there really isn't one.<br>
<br>
</div>You can set it to anything you want as long as each requested URL is<br>
associated with a real entityID that it needs to use using some other<br>
configuration option. If it never has to fall into a default choice of<br>
IdP, it won't matter what the default is. One option would be to set a<br>
discoveryURL that just points to a page that is designed to catch it as a<br>
sanity check and report an error.<br>
<div class="im"><br>
>Can we just leave it out of the <ApplicationDefaults> altogether?<br>
<br>
</div>You cannot make the software work without a <SSO> element or the older<br>
options that it replaced, and I believe you probably need either an<br>
entityID or a discoveryURL in there, though I don't know offhand for sure.<br>
<span class=""><font color="#888888"><br>
-- Scott<br>
</font></span><div class=""><div class="h5"><br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div></div>