I think the high-level cookie is our best option going forward since we
<br/>need to have those client-specific URL's to allow us to do the discovery
<br/>bit automatically. It does not present a security or performance issue
<br/>for us.
<br/><br/>I think the built-in discovery mechanisms in the Native SP are good, and
<br/>I'm not sure there's much more I would expect out of the box. We were
<br/>just looking to remove that discovery step from the authentication
<br/>process for our users if we could.
<br/><br/>Thanks for your help, Scott.
<br/><br/>On 2/25/2013 1:27 PM, Cantor, Scott E. [via Shibboleth] wrote:
<div class='shrinkable-quote'><br/>> > Thanks, Scott. It's important that the URL's be separate so that we can
<br/>> > automatically determine each user's tenant ID based on the URL. Given
<br/>> > that fact, what would be a better way to configure it?
<br/>>
<br/>> There isn't one, really. We need signed requests in place of URL
<br/>> registration, but getting that supported at scale will take years.
<br/>>
<br/>> I suppose one answer is to punt worrying about the security implications
<br/>> of a common domain. Given that a truly federated service shouldn't be
<br/>> doing discovery based on URL anyway, the trend would be to have unified
<br/>> domains. The segregated domain thing breaks down horribly as soon as you
<br/>> federate a resource to multiple clients. Google docs, Box, etc. have
<br/>> horrible user experiences because they're domain-based silos.
<br/>>
<br/>> But in terms of actually deploying across thousands of domains, this
<br/>> isn't a great software solution for that problem. It wasn't a goal.
<br/>>
<br/>> -- Scott
<br/>>
<br/>>
<br/>> --
<br/>> To unsubscribe from this list send an email to [hidden email]
<br/>> </user/SendEmail.jtp?type=node&node=7584796&i=0>
<br/>>
<br/>>
<br/>> ------------------------------------------------------------------------
<br/>> If you reply to this email, your message will be added to the discussion
<br/>> below:
<br/>> <a href="http://shibboleth.1660669.n2.nabble.com/Sub-domain-per-Entity-tp7584793p7584796.html" target="_top" rel="nofollow" link="external">http://shibboleth.1660669.n2.nabble.com/Sub-domain-per-Entity-tp7584793p7584796.html</a><br/>>
<br/>> To unsubscribe from Sub-domain per Entity, click here
<br/>> <<a href="" target="_top" rel="nofollow" link="external">
<br/>> NAML
<br/>> <<a href="http://shibboleth.1660669.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" target="_top" rel="nofollow" link="external">http://shibboleth.1660669.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml</a>>
<br/>>
</div><br/>
<br/><hr align="left" width="300" />
View this message in context: <a href="http://shibboleth.1660669.n2.nabble.com/Sub-domain-per-Entity-tp7584793p7584797.html">Re: Sub-domain per Entity</a><br/>
Sent from the <a href="http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html">Shibboleth - Users mailing list archive</a> at Nabble.com.<br/>